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 _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
