>Do we want to add things to the standard to
>make common, but not compliant, use cases compliant?
I would argue yes (although I'm relatively new to this discussion, too). If a
use case is common, it's because there are a lot of people who want the data in
that form. And if the standard can't accommodate that, what happens is the
data gets provided that way anyway, all the providers end up cobbling together
slightly different ad-hoc approximations of what they think the standard ought
to look like, and it's an unstandardized mess.
Case in point, consider precipitation. MKS flux units (kg/m^2/sec) are the
natural units for precipitation, but nobody in impacts wants the data in that
form. Impacts people (and many others) universally want precip data in units
of mm of accumulation. And thus there's an entire family of lwe_* (liquid
water equivalent) standard names that allow you to store your precip data in
mm/day instead.
I agree that a single canonical representation is ideal, and if it's just a
couple outliers, they should be encouraged to change to match everybody else.
But if it's a significant subcommunity that's differing, I think usability has
to trump structural purity. The value of a standard lies in its widespread
adoption. If it's not used because it can't do what people need it to do, it's
not a standard.
Cheers,
--Seth
----
Seth McGinnis
mcginnis at ucar.edu
NARCCAP Data Manager
Associate Scientist
RISC / IMAGe / NCAR
----
Received on Mon Jan 03 2011 - 11:53:26 GMT
