Re: [CF-metadata] [cf-convention/cf-conventions] Remove restrictions on netCDF object names (#237)
Yes, that might be a good way to encode the information. What I wanted to say is this: I find it very plausible that in a national weather service a group sits together and decides to code their station data using variable names `tas_station-name` with a number of non ascii letters in the station names. Furthermore, that would appear to be perfectly valid CF. So I think being more explicit about what is meant by "letter" would be good, even if that means saying that only ascii letters are allowed. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/237#issuecomment-732258060 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Remove restrictions on netCDF object names (#237)
HI @zklaus : good point about the existing rules. Regarding your use case; wouldn't that use case be covered by setting the `long_name` to "Temperature time-series from the Umeå station"? The current convention appears to permit "Umeå_station", but not "Umeå station" (blanks not allowed). The cfchecker (4.0) takes a narrower view of what is allowed, restricting variable names to string matching the python regex: `'^[a-zA-Z][a-zA-Z0-9_]*$'`. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/237#issuecomment-732238536 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Remove restrictions on netCDF object names (#237)
One potential use-case that always came to my mind without an actual example at hand Is the native names of weather stations, say a temperature time-series from the Umeå station, where the variable name contains the station name. What makes this particularly interesting is that it seems to be permitted already under current CF conventions, since under [CF-1.8, Section 2.3 Naming Conventions](http://cfconventions.org/Data/cf-conventions/cf-conventions-1.8/cf-conventions.html#_naming_conventions) it says: > Variable, dimension, attribute and group names should begin with a letter and > be composed of letters, digits, and underscores. [...] Languages other than > English are permitted for variables, dimensions, and non-standardized > attributes. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/237#issuecomment-732154175 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Remove restrictions on netCDF object names (#237)
I agree that some use cases would be helpful. I'm not sure about the specific proposal that initiated the discussion, but I do agree with the thought behind it that we should have a considered and reasoned policy on this, rather than just having a frozen-in rule based on past library constraints. One reason that we might want to depart from the full freedom allowed in NetCDF is that we have, in CF, a range of different attributes to describe a variable. The `long_name` is designed to hold human readable text, the `standard_name` and `units` which both have strongly constrained values. Some application libraries need, in places, identifiers with a restricted character set. For example, I can construct a `collections.namedtuple` with name `tas`, but not with name `tas.Amon` because, in python "Type names and field names can only contain alphanumeric characters and underscores" (cited from an error message generated by `collections.namedtuple`). Could this be considered as a use case for having place in the convention to specify, for CF objects, an identifier which is composed of "alphanumeric characters and underscores"? The variable name is the de facto place which many people use for this kind of identifier (perhaps because of legacy packages). Note that the `standard_name` fits the character restriction, but does not fit the use case because different variables may have the same `standard_name`. Another potential use case is for identifiers of concepts described in [RDF Turtle](https://www.w3.org/TR/turtle/) which has a character restriction on object names, broader, I think, than "alphanumeric characters and underscores", but definitely narrower than 137 thousand available of UTF-8. The desire to have a simple identifier is linked, in my mind at least, to the concept of a namespace, which is being discussed in the context of NetCDF (see [NetCDF-ld](https://github.com/opengeospatial/netcdf-ld) and discussion on [namespace delimiters](https://github.com/opengeospatial/netcdf-ld/issues/50)). I don't this is simply a matter of upgrading software to make it accept generic strings: there is a wide range of applications that exploit identifiers constructed from a limited character set in order to enable the use of identifiers within an text string. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/237#issuecomment-728814702 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Remove restrictions on netCDF object names (#237)
I had the same thoughts as @zklaus when thinking about the security implications of what I could only imagine was an `eval(var_name)`. I've even seen some of the matlab code which does exactly this to load all the variable into a matlab namespace. I'd even go so far as to recommend that the CF document itself warn against doing this... -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/237#issuecomment-580397605 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Remove restrictions on netCDF object names (#237)
I agree that it would be good to have use cases.
@ngalbraith is also right that not everyone is writing their CF code based on
naked netCDF access. Indeed, I consider such an approach foolish, since CF is
far too rich by now to stand a series chance of getting it right.
However, while using the netCDF variable name as a program variable name might
be excused in small, not reused code that only ever will deal with, say `tas`,
it is inexcusable in general-purpose library code. How would such a variable
enter the namespace without the program knowing its name beforehand?
Ultimately, the only way is via the equivalent of `eval(var_name)`. Such code
is prone to breakage no matter what restrictions we put on the character set
since it would always leave open the possibility of having reserved words of
the particular programming language as variable names. Another serious problem
is that it opens the possibility to maliciously crafted variable names: How
about `var_name='system("rm -rf .")'`?
Hence, I don't think the argument that all netCDF variable names should be
permissible program variable names in all programming languages should guide
the design of CF.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/237#issuecomment-580147380
This list forwards relevant notifications from Github. It is distinct from
cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the
UCAR list will result in a subscription to this list.
To unsubscribe from this list only, send a message to
cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Remove restrictions on netCDF object names (#237)
> @taylor13 Your code would have to parse the variable name into code. Until > you did something like that, it is just a string. Not everyone writes their own netCDF translators, and some packages no doubt take the variable and attribute names from the netCDF variable and attribute names. Those who use these packages are least likely to be in a position to accommodate this change. When I have a minute I'll give it a try with the Matlab netCDF interface. I'd be much happier to spend the time on it if there was more than 'creative purposes' for a reason. The [trac ticket](https://cf-trac.llnl.gov/trac/ticket/157) has an example of isotopes with names that begin with a number, which has some weight, but the work around for that seems simple compared to what would be needed by someone using code that auto-assigns variable names. On the other hand, most folks probably work with multiple standards; OceanSITES would no doubt maintain the variable name restriction, if CF doesn't. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/237#issuecomment-579879329 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Remove restrictions on netCDF object names (#237)
Well, thank you for all yout thoughtful responses. I see that we are rehashing [the 2014 discussion](http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2014/006929.html), and probably others. Thanks @ethanrd for finding that. There are good arguments pro and con there, and it is worth reading. The difference is that only 4 extra characters were proposed in 2014. I simply want to legalize all the other 137 thousand! > Is there a user asking for this extension, a particular use case that needs > addressing? CF has generally tried to avoid extensions that seem like a good > idea but don’t have a current use case. No, I do not have a current use case. This is a recurring issue, so I thought this comprehensive approach would be beneficial. Past use cases were mentioned or implied in the 2014 discussion, and in [trac 157](https://cf-trac.llnl.gov/trac/ticket/157). NetCDF developers put some care into expanded name capability, 12 years ago. However, CF restrictions are copied virtually unchanged from 25 year old COARDS rules, which were probably based on ASCII only. CF is overdue to allow the full naming range for creative purposes by all scientific users. Name quoting is generally easy and well supported in most modern programming languages. This takes care of UTF-8, math symbols, and other active characters. IMO, naming freedom should outweigh exactly matching names of program variables. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/237#issuecomment-579516163 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Remove restrictions on netCDF object names (#237)
As a user of data, I usually like the names of my variables (in my codes) to be the same as their names in the netCDF file. With the current naming convention for CF, this is always possible, I think. If, however certain restrictions were removed, as suggested above, this would no longer be true. I would echo others and ask what particular use cases are driving this? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/237#issuecomment-579407723 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Remove restrictions on netCDF object names (#237)
@taylor13 Your code would have to parse the variable name into code. Until you did something like that, it is just a string. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/237#issuecomment-579397758 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Remove restrictions on netCDF object names (#237)
I must be missing something, but if a variable is named, for example, "a-b", and one uses that in a computer code, how is it interpreted? How is that variable distinguished from the operation: subtract variable "b" from variable "a"? Don't "+", "-", "/", "*", " " all have this problem? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/237#issuecomment-579390849 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Remove restrictions on netCDF object names (#237)
Having blank spaces in names would break other CF conventions like use of the ancillary variables attribute. "The attribute ancillary_variables is used to express these types of relationships. It is a string attribute whose value is a blank separated list of variable names. " How to parse this? float q_error_limit(time) q_error_limit:standard_name = "specific humidity standard error" ; q_error_limit:units = "g/g" ; -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/237#issuecomment-579373394 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Remove restrictions on netCDF object names (#237)
@WardF and @lesserwhirls - Could you address the question of whether whitespace characters are allowed in netCDF variable names? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/237#issuecomment-579363997 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Remove restrictions on netCDF object names (#237)
Is there a user asking for this extension, a particular use case that needs addressing? CF has generally tried to avoid extensions that seem like a good idea but don’t have a current use case. Having said that, if we do move forward, I think we should be very cautious. Not only is Unicode very complicated as @zklaus points out, so are the rules around reserved character sets in URLs (and in which part of the URL) and file systems. Extending the set of characters allowed to include those reserved characters means they will need to be properly encoded when used in URLs (e.g., OPeNDAP and OGC WCS). Which, it turns out, isn’t as easy as it might seem. Also, this or similar proposals/discussions have come up before, I think several times but so far I've only found these two: - A 2014 discussion on the email list (the initial email is [here](http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2014/006929.html)) focused mainly on expanding the set of characters allowed to include ‘@’, ‘+’, ‘-’, and ‘.’ with some mention of Unicode coming fairly late in the discussion. - Trac Ticket #[157](https://cf-trac.llnl.gov/trac/ticket/157) suggested moving from “should” to “must” on the current set of allowed characters. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/237#issuecomment-579355842 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Remove restrictions on netCDF object names (#237)
I'm afraid I'm the odd man out here - I don't think the list of benefits in the original issue stacks up against the costs; in fact some of them don't seem to BE benefits. Maybe some use cases would be helpful ... Could you elaborate on how this change would support international usage? Is improved compliance for some existing data sets really a goal? What's in these data sets that needs to be described with a name that begins with a number or contains spaces or special characters? Maybe this is a selfish concern - we use Matlab's built-in netCDF library, and I'm not sure how that would deal with this change. If it's really needed for some specific reason, we'll deal with it, but absent that explanation, this is just a headache for a lot of CF users. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/237#issuecomment-579353147 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Remove restrictions on netCDF object names (#237)
I have zero Unidata authority, but I'd like to state the obvious: Unicode is complicated. This may already account for the somewhat vague formulation in the NUG if one takes a look at [the list of whitespace characters in unicode](https://en.wikipedia.org/wiki/Unicode_character_property#Whitespace). Indeed, whether one wants to go with a blacklist or a whitelist approach, it may be a good idea to think and write in terms of Unicode character categories (cf [here](https://en.wikipedia.org/wiki/Unicode_character_property#General_Category) or [here](https://unicodebook.readthedocs.io/unicode.html#categories)). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/237#issuecomment-579297317 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Remove restrictions on netCDF object names (#237)
> @marqh I like the overall suggestion of RFC3986. I think we should not adopt > the "% encoding" concept of RFC3986. And, again, I think we should reserve > leading "_" characters (per NUG) and multiple sequential "_" characters (per > netCDF-LD). Are there any other special character sequences in the wild that > anyone is aware of — in UGRID or Radial perhaps? I agree, @JimBiardCics, that adoption of %encoding is not a path I would want to walk. it's perhaps a useful cross reference, but points like this suggest against including some specific use of RFC3986 within CF > I notice that the NUG section you referenced implies that space characters > are allowed as long as they are not at the end of a variable name. Do we want > to allow internal spaces? internal spaces!?!? really if we can stop that, then that is a good thing. Why would the NUG allow variable names with spaces in them?? my reading of > The names of dimensions, variables and attributes (and, in netCDF-4 files, > groups, user-defined types, compound member names, and enumeration symbols) > consist of arbitrary sequences of alphanumeric characters, underscore '_', > period '.', plus '+', hyphen '-', or at sign '@', but beginning with an > alphanumeric character or underscore. However names commencing with > underscore are reserved for system use. lead me to view space as not allowed. However the following: > Beginning with versions 3.6.3 and 4.0, names may also include UTF-8 encoded > Unicode characters as well as other special characters, except for the > character '/', which may not appear in a name. > Names that have trailing space characters are also not permitted. Could someone from a Unidata background confirm or deny that in netCDF4, a space may be used within a variable name? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/237#issuecomment-579278290 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Remove restrictions on netCDF object names (#237)
@marqh I like the overall suggestion of RFC3986. I think we should not adopt the "% encoding" concept of RFC3986. And, again, I think we should reserve leading "_" characters (per NUG) and multiple sequential "_" characters (per netCDF-LD). Are there any other special character sequences in the wild that anyone is aware of — in UGRID or Radial perhaps? I notice that the NUG section you referenced implies that space characters are allowed as long as they are not at the end of a variable name. Do we want to allow internal spaces? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/237#issuecomment-579258744 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Remove restrictions on netCDF object names (#237)
We may get some benefit form considering other standardisation activity in this domain? RFC3986 defines the generic syntax for the Universal Resource Identifier (URI) https://tools.ietf.org/html/rfc3986 As netCDF variables are resources that are being identified within the domain of a netCDF file, could we benefit from just adopting RFC3986? This has a reserved character section: https://tools.ietf.org/html/rfc3986#section-2.2 Disclaimer: I have not cross referenced this in detail with the NUG to examine consistency or problem areas (potential for contribution if useful) First glance, these look pretty similar. If these are consistent, then adopting the NUG definition unchanged looks sensible to me. It already mandates against the use of a '/' character, which is the most problematic one for me, given groups and variable identity within groups. I'd like to see an explicit reference to the relevant NUG section in the text or linked, as I had to search a bit and I know what I'm looking for I think: https://www.unidata.ucar.edu/software/netcdf/docs/netcdf_data_set_components.html#Permitted is stable enough for a standards document (@ethanrd do you agree this is a stable URI for the resource please?) mark -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/237#issuecomment-579200697 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
Re: [CF-metadata] [cf-convention/cf-conventions] Remove restrictions on netCDF object names (#237)
I support the constraint indicated above. Especially allowing slashes and backslashes in names will be confusing. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/237#issuecomment-578668378 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
[CF-metadata] [cf-convention/cf-conventions] Remove restrictions on netCDF object names (#237)
**Title:** Remove restrictions on netCDF object names **Moderator:** **Moderator Status Review:** New issue, 2020 January 23 **Requirement Summary:** None. **Technical Proposal Summary:** Remove [CF 1.7 section 2.3](http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/cf-conventions.html#_naming_conventions) restrictions on characters in names of variables, attributes, etc. Resolve ambiguous use of such restrictions. **Benefits** * Support international usage. * Allow special characters in names. * Remove ambiguity over requirement versus preference. * Simplify CF rules. * Simplify conformance checking. * Improve compliance for some existing data sets. **Caveats** * Breaks compliance with COARDS name rules, but is a superset of them. * Some existing softwares can not handle non-traditional characters. They would need upgrades, but only when presented with new files using expanded character set. **Status Quo:** Object names are now restricted to a traditional yet limited character set which does not accommodate many non-western languages, nor other desired naming patterns. **Detailed Proposal:** Change the first paragraph of [2.3 Naming Conventions](http://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/cf-conventions.html#_naming_conventions) as follows. The remainder of **2.3** is left unchanged. **Current version (1.8 draft):** * Variable, dimension, attribute and group 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. **Proposed:** * Variable, dimension, attribute, and group names are not generally restricted by this convention. Any names that are acceptable to the netCDF library may be used. The most notable rules from netCDF are ASCII or UTF-8 character set, and names should not begin with underscore or certain other special characters. Refer to file format specs in the NUG for more details. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/237 This list forwards relevant notifications from Github. It is distinct from cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
