On Wed, Jan 15, 2014 at 9:24 AM, Jim Biard <jbiard at cicsnc.org> wrote:
> 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.
>
but we aren't talking about assigning meaning, or telling anyone what names
they can use.
There is an existing rule about what charactors can be used for variable
names, that's it -- and we've given a couple not-all-that compelling
reasons why that rule is good, and no reason other than maybe taste, why
that rule would be extended.
(and it certainly shouldn't be removed completely -- variable names with
arbitrary bytes in them would really be a mess). Is it ascii-only now? it
probably should stay that way.
Perhaps there are some reasons to want less-restrictive variable names --
I'm not always that imaginative, but if so, then present them.
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.)
>
yup, but you couldn't name them: "vNNN-NNN" -- and why do you need to?
Given your point about the real meaning being encoded in the attributes,
then a prime reason to choose a given variable name is that it matches a
name you are using elsewhere in your process -- which is why I like them
being restricted to names that are valid variable names in programming
languages. Bu tit also may be a reason to be more flexible -- if you call
something "this+that" elsewhere in your process, you may want to use it in
your netcdf files, too.
-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.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140115/45c28e6d/attachment-0001.html>
Received on Wed Jan 15 2014 - 13:37:10 GMT
