Dear John
I agree with these principles. I think we might phrase 3 and 4 as balanced
alternatives:
> "CF may incorporate an outside convention into it when the following
> conditions hold:
>
> 1. The semantics of the convention are important to the CF community.
> 2. The convention is already in wide use by other communities, and the
> adoption by CF significantly helps other communities adopt CF.
> 3a. Either, the convention does not overlap existing CF conventions
> 3b. Or, if it does overlap existing CF conventions,
> software is provided to detect inconsistencies
> and provide feedback to the data producer.
and we could append "or data user" to that. The producer might not have
checked, and the user needs to be warned. I changed "should be developed"
to "is provided", since it's a condition for incorporating the convention.
It's important that your proposal says "may". We don't *have* to do this.
It depends on whether it's a good solution to a need.
CF doesn't currently have a statement of principles, though. Such a statement
could be put into the Goals section at the start, I suppose. Here is another
list, which comes from the CLIVAR article of some years ago, that's linked
from the CF home page
http://cf-pcmdi.llnl.gov/documents/other/cf_overview_article.pdf
I would propose these for inclusion as well:
The general principles in the design of CF are as follows. (1) Data should be
self-describing. No external tables are needed to interpret the file. For
instance, CF doesn't use numeric codes, like GRIB does. (2)
Conventions have been developed only for things we know we need. Instead of
trying to foresee the future, we have added features as required and will
continue to do this. (3) We wish to avoid being too onerous for data-writers
and users of data, as this will make the standard unattractive. (4) The
metadata should be readable by humans as well as easily parsed by
programs. (5) Redundancy is minimised---a good general principle because it
reduces the chance of inconsistency---and we try also to limit
possibilities for making mistakes when writing data.
Cheers
Jonathan
Received on Mon Nov 21 2011 - 10:49:09 GMT
