With respect to netcdf (at least the C version),
it is the case that these characters can appear
unescaped: _. at +-
It should be noted however that dot in particular
causes problems for accessing remote datasets
through DAP because the dot character is used
in DAP constraints to specify fields inside
DAP Sequences or Structures or Grids.
The problem you have is that no matter what
choice of character(s) you make, someone may
use the characters in a different way.
This means that whatever choice you make, you need
to enshrine it in a standard somewhere so that at
least there is a chance that people will avoid it.
Personally, I would think that a two character sequence
is least likely to be used by others, but two underscores
is probably not a good choice. I would think something
like _at_@ ++ might be a better choice.
=Dennis Heimbigner
Unidata
Bentley, Philip wrote:
> Roy et al.,
>
>> Martin's comments on namespace highlight a concern I
>> identified whilst doing the research for the SeaDataNet
>> specification. Several communities have added large numbers
>> of both global and variable attributes with no indication of
>> namespace. Not only does this make it difficult to tease out
>> what is CF and what is a community extension, but it creates
>> an accident in waiting. What happens if CF creates a new
>> attribute with a name already in community usage? In my view
>> it's too late to introduce a CF namespace and prefer the idea
>> that for a CF-compliant file CF should be the default
>> namespace, with communities taking responsibility for their
>> extensions. This is what I've done for SeaDataNet.
>
> In working up a local metadata profile of CF for use here at the Met
> Office, we also spent much time thinking about the 'namespace problem'.
> In an early draft of our metadata profile, and after having reviewed
> previous discussions (e.g. https://cf-pcmdi.llnl.gov/trac/ticket/27), we
> elected to use the double underscore character sequence ('__') as a
> namespace separator. Our namespace prefixes were then mnemonics like
> 'ukmo' for the Met Office, 'dc' for Dublin Core, 'cim' for the Common
> Information Model, and so on. And we devised additional (fairly simple)
> machinery to associate the prefixes with target namespaces, just as in
> the XML world.
>
> Thus, we envisaged using netcdf attributes along the lines of:
>
> variables:
> float myvar(t, y, x) ;
> myvar:ukmo__stashcode = "m01s01i123" ;
> myvar:ukmo__runid = "abcde" ;
>
> // global attributes
> :dc__rights = "Copyright (c) 2013, Acme Wind and Rain Corp." ;
> :dc__created = "2013-01-01 ..." ;
>
> In the end, driven by a practical need to release a simpler, more
> digestible release 1.0 of our metadata specification, we dropped all the
> aforementioned namespace stuff.
>
> As part of some subsequent low-level netcdf work, however, I chanced
> upon the fact that the '.' character is not treated in any special way
> within netcdf names (or rather, it is one of netcdf's original special
> characters, but not one that needs to be escaped in the way that, say,
> the ':' character does).
>
> This got me to thinking that the '.' character might be the ideal
> namespace separator for use in CF/netCDF attribute names. Since '.' is
> not in the set of characters currently permitted in CF attribute names,
> we can be reasonably sure that it is not being used in existing
> CF-compliant netcdf files.
>
> The '.' character also has collateral appeal for python/java developers
> in that it is the familiar namespace separator used by those languages.
>
> Applied to the previous example, then, we'd now have netcdf attributes
> such as ukmo.stashcode, ukmo.runid, dc.rights, dc.created, and so on.
> Which looks considerably more elegant, IMO.
>
> While in your context, Roy, you might elect to use namespace'd
> attributes called sdn.conventions, sdn.foo, sdn.bar, etc. Or bodc.foo,
> bodc.bar, etc. for BODC stuff.
>
> Clearly there are several technical issues that would need to be
> addressed (e.g. how/when to use the 'cf.' prefix, what would the default
> namespace be, how would prefixes and their namespaces be associated, how
> should software interpret namespaces, and so on).
>
> But, assuming these could be resolved, what do people think about use of
> '.' as a namespace separator? Good idea? Bad idea?
>
> Some recent postings to this list have suggested using a 'cf_' prefix,
> with the implied suggestion of a '_' namespace separator. IMHO, this
> approach has the limitation that client software would not be able to
> disambiguate existing names which include the '_' character. For
> example, would the name 'cell_methods' refer to a property called
> 'cell_methods' in some default namespace, or a property called 'methods'
> in the 'cell' namespace? Likewise for some possible new attribute
> called, e.g. 'cf_my_new_thing', what namespace would that be in? cf?
> cf_my? cf_my_new?
>
> Regards,
> Phil
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Mon Jan 28 2013 - 11:17:55 GMT
