Dear Richard and others, > If we tried to be prescriptive, it might either (a) prevent > people from using CF, or (b) using it incorrectly, because it > didn't quite fit their needs, but they didn't want to change > how they did things.
or (c) using it incorrectly because they didn't quite understand all the requirements to be compliant with the standard. Those are all fair arguments, indeed, and valid concerns. I observe that there is nevertheless a delicate balance to decide on which side of the "acceptance threshold" each such requested feature falls. For instance I noticed that you just "rejected" the idea of introducing an attribute for positive direction, due to concerns matching (b) or possibly (c). Good! However, my view is that multiple names for the same kind of data just falls into the very same category. As the names serve a certain semantic purpose within CF, defining several identifiers for the same opens up for another set of potential problems. What if some person at some point interprets this to mean that they should write _both_ variants, for instance? How should the reader interpret that situation, and would it imply that they should bother to actually check that the two sets are consistent? Or what about some reader software being (stupidly) hardcoded to look for "downward_foo", but the data provider decide d at some point that it was more convenient to use "upward_foo"? That would be a show-stopper for using CF for the poor user that is using those two pieces of software... or at least an annoyance for a while! I agree to the concern about people being prevented from using CF. However, if someone decides to go with -say- CF, they probably do so for the benefit they think they will get from that. If the "price" is high for them to adapt "how they did things", then surely they would consider something else. However, all of the features discussed in this thread are almost trivial to adapt to, so for most people these are not a cause for concern of type (a). > However, in practice most projects which generate CF data > (like CMIP) have their own further conventions, which usually > do prescribe more precisely what should be stored, in terms > of standard names. That might be so for many projects, but if they have prescribed CF and CF says "downward_foo" it is, would it stop them from using that even if they internally keep values with upward positive direction? > So for any particular project your preference above is met, > but it may differ from project to project. Does this assume that the "project" would incorporate both the data generator part, as well as the consumer of those data? In most of "my" projects, I never get to choose the variable names at all! They might have been produced long ago, or I don't have an influence on how they are produced. I am then faced with interpreting what the "user" decides to feed into my software in the best possible way, which also means I might have to cope with every possibility the "standard" allows (and then some for good measure). This is generally why I advocate keeping the standard as minimal and unambigious as possible given that it also must cater to everybody's needs (like Occam's Razor). -- Best regards, -+-Ben-+- _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
