Perhaps this problem can be resolved if we carefully distinguish between the convention *identifier* in the Conventions attribute, and the convention name (which can be in any other attribute, like Convention_Names or Metadata_Conventions). For the names we could specify either attribute, or both, or be silent.
I'd argue that good practices suggest that the identifier should be created to support automatic parsing of the netCDF Conventions attribute. Such a good practice would eliminate spaces from the identifier, given current guidance.
In this case I'd argue the value of supporting automated and deterministic detection of conventions, outweighs the cost of insisting the identifier can be free-form text. And although if I ran the world I'd standardize on the attribute for the full convention names and how to delimit them, it won't bother me too much if by our silence we force a human reader to scan through the rest of the attributes to find the full names of all the applicable conventions.
John
As in the example I tossed out earlier, OceanSITES 1.1" but that isn't the complete name of the convention I'm thinking.
On Dec 22, 2011, at 14:01, Jim Biard wrote:
> 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
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
John Graybeal <mailto:jgraybeal at ucsd.edu>
phone: 858-534-2162
Product Manager
Ocean Observatories Initiative Cyberinfrastructure Project:
http://ci.oceanobservatories.org
Marine Metadata Interoperability Project:
http://marinemetadata.org
Received on Thu Dec 22 2011 - 15:27:41 GMT
