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?

Grace and peace,

Jim

Visit us on
Facebook        Jim Biard
Research Scholar
Cooperative Institute for Climate and Satellites NC
North Carolina State University
NOAA's National Climatic Data Center
151 Patton Ave, Asheville, NC 28801
e: [email protected]
o: +1 828 271 4900




On Jan 15, 2014, at 12:00 PM, Chris Barker <[email protected]> wrote:

> On Wed, Jan 15, 2014 at 7:39 AM, jbiard <[email protected]> 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
> 
> [email protected]
> _______________________________________________
> CF-metadata mailing list
> [email protected]
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Reply via email to