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