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.bar...@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
_______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
