It is "easier" (not by much, code-wise) to not to allow commas as
delimiters, but if you want to allow for machine-recognition of
convention names, how are you going to handle conventions that have
spaces in their names? Telling everyone else to get rid of spaces isn't
a practical solution, and you have just created a thornier problem for
coders who have to figure out which way someone dealt with forbidden spaces.
On 12/22/2011 10:18 AM, Nan Galbraith wrote:
> Thanks Russ, Dave(s), Jonathan and Lorenzo -
>
> Thanks for the clarifications. I agree that it makes sense to
> require that convention names not contain spaces, and that
> it's easier (and more CF-like, hence better!) to parse space
> separated terms.
>
> Cheers - Nan
>
>> The recommendation on the Unidata site for multiple conventions
>>
>> http://www.unidata.ucar.edu/netcdf/conventions.html
>>
>> is to use spaces rather than commas:
>>
>> It is possible for a netCDF file to adhere to more than one set of
>> conventions, even when there is no inheritance relationship among the
>> conventions. In this case, the value of the `Conventions' attribute
>> may be a single text string containing a list of the convention names
>> separated by blank space (recommended) or commas (if a convention
>> name
>> contains blanks), for example
>>
>> :Conventions = "XXX YYY" ;
>
>
> On Dec/22/2011 6:01 AM, Lorenzo Bigagli wrote:
>> Hi all,
>>
>> my opinion is to keep with the current recommendation, which better
>> supports automatic parsing and the existing conforming datasets.
>> In particular, I would avoid any parsing rule for the conventions
>> attribute, keeping its syntax as simple as possible (as Jonathan
>> points out, blank-separated lists are more CF-like).
>>
>> I think it makes sense to require convention identifiers not to
>> contain spaces (as usual in identifiers).
>> Those conventions that have not followed Unidata recommendation may
>> be dealt with on a transitional basis (e.g. by means of specific
>> parsing exceptions), while they are aligned in a future revision.
>>
>> Best wishes,
>> LB
>>
>> Il giorno 22/dic/2011, alle ore 10:11, Jonathan Gregory ha scritto:
>>
>>> Dear all
>>>
>>> The existing Unidata recommendation is OK and we could incorporate
>>> it into
>>> CF but it would help to be more precise, for instance: If the
>>> Conventions att
>>> includes no commas, it is interpreted as a blank-separated list of
>>> conventions;
>>> if it contains at least one comma, it is interpreted as a
>>> comma-separated list.
>>> Blank-separated lists are more CF-like - many CF attributes use that
>>> syntax -
>>> but obviously we can't insist that other conventions don't have
>>> blanks in their
>>> names, and it would be simpler therefore to use a comma-separated
>>> list for
>>> this attribute, despite the Unidata recommendation.
>>>
>>
>
--
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 - 08:42:39 GMT
