Dear all - such as Roy, John (Graybeal) and Mark (Hedley)
Would someone have time to open a trac ticket to propose a change to the CF
convention, in order to clarify the Conventions attribute, following all this
useful email discussion? It seems to me that it would be good to make a
definite
I will be glad to open a trac ticket. Let me have a day or so draft
some amendment wording. My intention is to use Unidata's
recommendations in the NetCDF Users Guide as a starting point, and
include notes about conformance and avoiding conflicts.
--Dave
On Tue, Jan 3, 2012 at 11:49 AM,
I wasn't sure how to parse these, I'm a little slow today I guess. After
trying a few ways, I decided they mostly use spaces to separate convention
identifiers, and slashes to designate hierarchy. (Except the first two embed a
space within OceanSITES x.x, which I think should be a hyphen.)
January 2012 18:47
To: Lowry, Roy K.
Cc: CF Metadata List; sdn2-t...@seadatanet.org
Subject: Re: [CF-metadata] Convention attribute
I wasn't sure how to parse these, I'm a little slow today I guess. After
trying a few ways, I decided they mostly use spaces to separate convention
identifiers
] On
Behalf Of Hedley, Mark [mark.hed...@metoffice.gov.uk]
Sent: 29 December 2011 13:27
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Convention attribute
hello Roy
I wonder if this could be captured by the notation in the Unidata documentation:
'''
Later, if another group agrees upon some
: [CF-metadata] Convention attribute
Dear Mark and Dave
I agree with Dave's answers. If two conventions are used together, it is the
responsibility of the data-writer to guarantee that the metadata supplied is
consistent if there are any overlaps in meaning. A particular case of that is
if the two
...@metoffice.gov.uk]
Sent: 29 December 2011 13:27
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Convention attribute
hello Roy
I wonder if this could be captured by the notation in the Unidata documentation:
'''
Later, if another group agrees upon some additional conventions for a specific
subset of XXX
I think this represents a sensible approach. I think that the name_spacing is
implicit and will have to remain so.
I think a strong statement detailing the responsibility placed on the data
provider to have checked that the metadata is unambiguously consistent with all
standards stated in
-Original Message-
From: cf-metadata-boun...@cgd.ucar.edu on behalf of Lowry, Roy K.
Sent: Thu 29/12/2011 10:08
To: Jonathan Gregory; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Convention attribute
Dear All,
One thought that this debate has brought to mind is what should
Dear Mark and Dave
I agree with Dave's answers. If two conventions are used together, it is the
responsibility of the data-writer to guarantee that the metadata supplied is
consistent if there are any overlaps in meaning. A particular case of that is
if the two conventions define attributes with
Dear all
The existing Unidata recommendation is OK and we could incorporate it into
CF but it would help to be more precise, for instance: If the Conventions att
includes no commas, it is interpreted as a blank-separated list of conventions;
if it contains at least one comma, it is interpreted as
Hi all,
my opinion is to keep with the current recommendation, which better supports
automatic parsing and the existing conforming datasets.
In particular, I would avoid any parsing rule for the conventions attribute,
keeping its syntax as simple as possible (as Jonathan points out,
Thanks Russ, Dave(s), Jonathan and Lorenzo -
Thanks for the clarifications. I agree that it makes sense to
require that convention names not contain spaces, and that
it's easier (and more CF-like, hence better!) to parse space
separated terms.
Cheers - Nan
The recommendation on the Unidata
It is easier (not by much, code-wise) to not to allow commas as
delimiters, but if you want to allow for machine-recognition of
convention names, how are you going to handle conventions that have
spaces in their names? Telling everyone else to get rid of spaces isn't
a practical solution, and
On 12/22/2011 2:11 AM, Jonathan Gregory wrote:
Dear all
The existing Unidata recommendation is OK and we could incorporate it into
CF but it would help to be more precise, for instance: If the Conventions att
includes no commas, it is interpreted as a blank-separated list of conventions;
if it
Russ (and thus core netcdf) has always been explicit about space-delimited
conventions, so really there shouldn't be any conventions with spaces in
the names.
On the other hand, we have adopted the technique of using the convention
name as a pattern to match against the convention attribute, so
Dear all
This is certainly a lively thread! :-)
An array of strings would be nice but I don't think we should do that because
it's not compatible with the Unidata convention and it depends on the non-
classic netCDF model. In this case we can probably get by without it. While
we can't control
Hi all -
I'm certain that this has been discussed, but I can't
find it anywhere in the email archive, or on the trac site.
Don't we allow a compound (comma separated) string
in the global attribute 'Conventions'?
Because there are new, complimentary
Hi Nan,
Within ACDD the guidance is to use:
Metadata_Conventions = Unidata Dataset Discovery v1.0;
This is documented at the top of the Unidata page but not within the
listed HTML tables which I think makes it easy to overlook.
Ah, thanks, I guess that's another solution.
In OceanSITES, we have added ours to the main Conventions
attribute, so we have
Conventions = "OceanSITES 1.1, CF-1.1" ;
which might not be ideal... I was fairly sure we'd discussed it
on this list, but
Russ et al,
I suggest that the Unidata recommendation needs to be changed to
commas only. I recall seeing recent cases where a convention name
includes spaces, but I have never seen a comma in such name. Case in
point, from Nan's follow-up:
Conventions = OceanSITES 1.1, CF-1.1 ;
Also I
21 matches
Mail list logo
