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
"vNNNNNNNNNN", 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://ncdc.noaa.gov/>
151 Patton Ave, Asheville, NC 28801
e: jbi...@cicsnc.org <mailto:jbi...@cicsnc.org>
o: +1 828 271 4900
On Jan 15, 2014, at 12:00 PM, Chris Barker <chris.bar...@noaa.gov
<mailto:chris.bar...@noaa.gov>> wrote:
On Wed, Jan 15, 2014 at 7:39 AM, jbiard <jbi...@mail.cicsnc.org
<mailto:jbi...@mail.cicsnc.org>> wrote:
I don't think we should use ease of mapping variable names to a
programming language as a reason for allowing (or not allowing)
any particular character in variable names.
Why not? maybe not a compelling reason, but I can't imagine a
compelling reason to have more flexible naming conventions, either.
CF has, as I understood it, considered variable names as
completely up to the producer, relying on attributes to provide
meaning. So, I can name a temperature variable "fluffy_bunny" if
I want to, and it is completely valid.
valid yes, a good idea? probably not.
Section 1.3 of the Conventions states, "No variable or dimension
names are standardized by this convention."
so there are no standard variable names -- that's not the same as
standards for variable names....
Personally, I wish there were standards for variable names, it would
make it easier to code against -- but that cat's out of the bag. But
this cat isn't: the restiricitons have been there for a long time, so
the question now is:
what are the reasons for easing those restrictions?
and
what are the reasons for keeping those restrictions?
we've given a few reasons for keeping them (maybe not all that
compeling toyou, but reasons none the less) -- what are the reasons
for relaxing them, other than "I like this naming convention that is
currently not allowed" ?
I'm not convinced that "fluffy-bunny" is any more readable or
anything else than "fluffy_bunny"
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov <mailto:chris.bar...@noaa.gov>
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu <mailto:CF-metadata@cgd.ucar.edu>
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata