>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 [email protected] NARCCAP Data Manager Associate Scientist RISC / IMAGe / NCAR ---- _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
