And I wasn't going to say anything else, but this crystallized an issue or two from past mails. I promise to (try to) let it go after this.
On Jan 15, 2014, at 12:37, Chris Barker <chris.barker at noaa.gov> wrote:
> 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.
I don't think multiple use cases from different individuals and communities should be categorized as "no reason other than maybe taste". Just sayin'...
> (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.
This prompts me to observe that somehow, in this brave new age of computer programming, people are developing netCDF software that supports Unicode characters -- Unicode!! -- in variable (attribute etc) names. There will be netCDF files in the wild, used by scientists and normal people (especially normal people from non-English-speaking countries) that use all sorts of wild and crazy characters in their variable names. (Perhaps CF thinks these are "alphanumeric", in which case I've found a solution! The standard certainly is not explicitly ASCII-only.) By the way, I was amazed to learn that using Unicode in programming languages is starting to take hold.
At some point, we in the CF-supporting community are going to have to support the standard practices in this aspect that are going on everywhere else in the software world, or decide we want a permanent back-water for the 'scientists who are not interested in or capable of supporting these practices' (not my claim).
> Perhaps there are some reasons to want less-restrictive variable names -- I'm not always that imaginative, but if so, then present them.
Let's just make the list so far, to get everyone up to speed with the discussion:
* easier visual parsing (taste, yes, but practical also if you work with lots of data sets from different communities)
* embedding semantic meaning (taste)
* clearly isolating the context (namespace, hierarchy)
* matching attribute names that come from the source data
* consistency with netCDF usage/files -> easier onboarding of those files
* Unicode/internationalization support
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140115/4b54b5d0/attachment.html>
Received on Wed Jan 15 2014 - 14:14:28 GMT
