Hi all, The use of "should" may, by many, be interpreted as a recommendation rather than as a requirement.
Though the terms "must", "should", and "may" are used throughout the CF spec, I am not finding any text that defines those terms. Perhaps a reference to the IETF RFC 2119 [1] (which defines these and a few other related terms) should be added to the CF spec. Though it seems that might require a fairly full review of the uses in CF of the terms defined in RFC 2119. Ethan [1] http://www.ietf.org/rfc/rfc2119.txt On 1/15/2014 10:46 AM, Karl Taylor wrote: > All, > > Yes, that statement seems quite definitive and unambiguous, and for the > reasons stated in other emails, I support retaining it. > > regards, > Karl > > On 1/15/14 9:37 AM, Steve Hankin wrote: >> >> 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 > > > > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > -- Ethan Davis UCAR Unidata Program eda...@unidata.ucar.edu http://www.unidata.ucar.edu _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
