> @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 [email protected], 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 [email protected].
