Hi Jonathan, > 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.
Section "5.2 Guiding Principles" of the NASA ESDS Community Standard document for CF Metadata Conventions http://www.esdswg.org/spg/rfc/esds-rfc-021/ESDS-RFC-021-v0.01.pdf also lists those five principles (reworded) as well as a few more specific guidelines, including - Limited redundancy is tolerated if it supports the independence of variables from each other, so that extraction, copying, and merging of separate variables is more practical. --Russ _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
