I have two use cases:
MBARI has data from an underwater vehicle that contains hundreds of engineering
variables that are automatically logged using the onboard software's names for
the variables. Those variables include the '.' character. We tried to use our
existing NetCDF TDS/Hyrax infrastructure to handle these data but ran into
several frustrating inconsistencies in how various packages handled the '.'.
Unfortunately, we are not using the infrastructure for these data.
The ESIP Federation documentation group discussed creating a flattened object
serialization convention for hierarchical metadata and wanted to use '.' as a
delineator but needed to abandon that consideration to stay CF compliant.
-Mike
--
Mike McCann
Software Engineer
Monterey Bay Aquarium Research Institute
7700 Sandholdt Road
Moss Landing, CA 95039-9644
Voice: 831.775.1769 Fax: 831.775.1736 http://www.mbari.org
On Jan 15, 2014, at 10:28 AM, John Graybeal wrote:
Perhaps a reference to the IETF RFC 2119 [1] (which defines these and a few
other related terms) should be added to the CF spec
Yes please, since discussion on this thread has already varied in its
understanding/application of those terms.
The ambiguity in the sentence No variable or dimension names are
standardized by this convention. is also relevant. It could mean This
convention defines no requirements about variable or dimension names. or
This convention does not specify any particular variable or dimension
names. The former meaning obviously reinforces the interpretation that
'should' is not a requirement.
While the arguments pushing for the restrictive naming convention (_ as the
only special character) are perhaps not strong, for my own use I don't have a
compelling use case on the need for more characters either. Mostly this is a
matter of personal taste -- I like being able to use . and - to help with
visual parsing and + and @ for semantic reasons, and they help reduce the
number of likely prefix collisions (which a single separator doesn't help
with at all).
There is also a social benefit from relaxing the CF almost-standard:
on-boarding. We want to encourage netCDF users to transition to CF.
Minimizing the number of inconsistencies seems practical and
forward-thinking. Forcing a netCDF user (which may include lots of HDF users
too, these days) to abandon established attribute names is a significant cost
for the affected users, now and going forward.
John
On Jan 15, 2014, at 10:00, Ethan Davis eda...@unidata.ucar.edu wrote:
Hi all,
The use of should may, by many, be interpreted as a recommendation
rather than as a requirement.
Though the terms must, should, and may are used throughout the CF
spec, I am not finding any text that defines those terms.
Perhaps a reference to the IETF RFC 2119 [1] (which defines these and a
few other related terms) should be added to the CF spec. Though it seems
that might require a fairly full review of the uses in CF of the terms
defined in RFC 2119.
Ethan
[1] http://www.ietf.org/rfc/rfc2119.txt
On 1/15/2014 10:46 AM, Karl Taylor wrote:
All,
Yes, that statement seems quite definitive and unambiguous, and for the
reasons stated in other emails, I support retaining it.
regards,
Karl
On 1/15/14 9:37 AM, Steve Hankin wrote:
On 1/15/2014 9:24 AM, Jim Biard wrote:
Chris,
The point is, the Conventions themselves state that there is *no
standard*. People are all the time trying to add meaning to variable
names, but the standard actually states that the meaning is to reside
in the attributes. The variable names are just keys for
differentiating the variables. (I could name all my variables
“vNN”, where N is a digit, and I would be completely valid
according to the standard.) The long_name and standard_name
attributes are the places where descriptors of the variable content
are to be found.
So I’m raising a question. _ Is there actually anything other than
sentiment (i.e., an actual rule) that anyone can point to that
prevents someone from using “new” characters in their variable names?_
How about the lines from the CF document that you cut-pasted (thank you):
/Variable, dimension and attribute names should begin with a
letter and be composed of letters, digits, and underscores. Note
that this is in conformance with the COARDS conventions, but is
more restrictive than the netCDF interface which allows use of the
hyphen character. The netCDF interface also allows leading
underscores in names, but the NUG states that this is reserved for
system use./
- Steve
Grace and peace,
Jim
CICS-NC http://www.cicsnc.org/Visit us on
Facebook http://www.facebook.com/cicsnc *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC http://cicsnc.org/
North Carolina State University http://ncsu.edu/
NOAA's National Climatic Data Center http
