I'm confused by several comments on this thread. If netCDF has always been explicit about space-delimited convention identifiers, what explains the existence of a convention identifier with a space in it (Conventions = "OceanSITES 1.1, CF-1.1")? Does netCDF have a review process for netCDF convention identifiers, such that it can and will enforce proper convention naming (or really identifier naming)? If not, is there an explicit statement about the rule for not including certain characters in the identifier?
If there is a convention identifier with a space in it, how will space-delimited parsing produce the desired result? It will look like two conventions. This does not seem simple and machine-parseable to me. As use of netCDF gets more sophisticated and mature, it becomes likely that conventions will come in batches (with extensions and/or versions), so anticipating -- allowing -- the scenario of one convention identifier being a substring of another seems forward-looking and useful (and ruling it out would be unfortunate, not that anyone is arguing for that). Note that simply replacing the space delimiter with comma doesn't fix the problem unless the above principles are addressed. There has to be a rule that either precludes the delimiter in the identifier, or allows for it to be escaped. To become a true netCDF convention, the netCDF folks will need to ensure a few rules like that are followed. Maybe to become a "CF-compatible netCDF convention", the CF folks will need to vet the convention for conflicts. I do think a convention for managing multiple conventions is essential -- data will be passed around more every year, and software will become smarter about how to handle it. The applications and cyberinfrastructure systems being built now will use whatever information they can to provide a better user experience. Being such a strong part of the 'computable ecosystem', netCDF plays an important role in enabling these better user experiences. So my vote is to create a truly machine-friendly way of handling convention identifiers and clearly spell it out in the standard. John On Dec 22, 2011, at 08:56, Benno Blumenthal wrote: > Russ (and thus core netcdf) has always been explicit about space-delimited > conventions, so really there shouldn't be any conventions with spaces in the > names. > > On the other hand, we have adopted the technique of using the convention name > as a pattern to match against the convention attribute, so that we do not > care about delimiters. > > This, of course, will fail if someone has a convention name that is a > substring of another convention name, and that convention is not a subset of > the convention with the longer name. > > Benno > > > > On Thu, Dec 22, 2011 at 10:42 AM, Jim Biard <jim.bi...@noaa.gov> wrote: > 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.bi...@noaa.gov > 828-271-4900 > > > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > > -- > Dr. M. Benno Blumenthal be...@iri.columbia.edu > International Research Institute for climate and society > The Earth Institute at Columbia University > Lamont Campus, Palisades NY 10964-8000 (845) 680-4450 > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata John Graybeal <mailto:jgrayb...@ucsd.edu> phone: 858-534-2162 Product Manager Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org Marine Metadata Interoperability Project: http://marinemetadata.org _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
