Seems a bit extreme to say that a convention is not compatible with CF
just because it has a name with spaces in it. Apart from the
Conventions attribute, a file can be completely conformant with both CF
and one or more other conventions. I feel like our goal should be to
maximize the ability of people to indicate what conventions are in use
in their files. If we don't allow this attribute to somehow contain the
names of all of the conventions, it will mean that other attributes will
be used to contain the names of the other conventions. We will then
have a hodgepodge of attributes that need to be checked in order to find
out what conventions are applicable. In the spirit of encouraging
cooperation, let's allow this attribute definition to be flexible enough
to accommodate non-CF approaches to doing things. Doesn't mean we have
to do it everywhere.
Grace and peace,
Jim
On 12/22/2011 4:03 PM, Jonathan Gregory wrote:
> Dear all
>
> This is certainly a lively thread! :-)
>
> An array of strings would be nice but I don't think we should do that because
> it's not compatible with the Unidata convention and it depends on the non-
> classic netCDF model. In this case we can probably get by without it. While
> we can't control the names of netCDF conventions in general, and it appears
> that Unidata have not done so, CF could impose such a rule, as John suggests.
> That is, we could state that if a convention is to be regarded as compatible
> with CF, it must have a name with no spaces it. Then we can make the
> Conventions attribute a blank-separated list safely. Would that be acceptable?
>
> Cheers
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
Jim Biard
Government Contractor, STG Inc.
Remote Sensing and Applications Division (RSAD)
National Climatic Data Center
151 Patton Ave.
Asheville, NC 28801-5001
jim.biard at noaa.gov
828-271-4900
Received on Thu Dec 22 2011 - 15:01:25 GMT
