Dear Martin, Roy et al.
I understand exactly what you want - or at least I thing I do. I think that
you would like to enter a URL representing the concept 'carbon monoxide' and
get back a document giving you all the Standard Names pertaining to carbon
monoxide. Am I right?
I appreciate
: Jonathan Gregory [j.m.greg...@reading.ac.uk]
Sent: 24 September 2012 17:53
To: Schultz, Martin
Cc: Lowry, Roy K.; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Another potentially useful extension to the
standard_name table
Dear Martin, Roy et al.
I understand exactly what you want - or at least
-metadata@cgd.ucar.edu; j.m.greg...@reading.ac.uk
Subject: RE: [CF-metadata] Another potentially useful extension to the
standard_name table
Sorry if this is an ignorant/newbie question, but can I ask if the grammar for
CF std_names implicitly provides a check on duplicates?
Simon
-Original
@csiro.au; jgrayb...@ucsd.edu; Cameron-smith, Philip
Cc: cf-metadata@cgd.ucar.edu; j.m.greg...@reading.ac.uk
Subject: RE: [CF-metadata] Another potentially useful extension to the
standard_name table
Hello Simon,
If you're referring to syntactic duplicates then providing the controlled
To: Cox, Simon (CESRE, Kensington); jgrayb...@ucsd.edu; cameronsmi...@llnl.gov
Cc: cf-metadata@cgd.ucar.edu; j.m.greg...@reading.ac.uk
Subject: RE: [CF-metadata] Another potentially useful extension to the
standard_name table
Hello Simon,
If you're referring to syntactic duplicates then providing
Of John Graybeal
[jgrayb...@ucsd.edu]
Sent: 22 September 2012 00:09
To: Cameron-smith, Philip
Cc: cf-metadata@cgd.ucar.edu; Jonathan Gregory
Subject: Re: [CF-metadata] Another potentially useful extension to the
standard_name table
I like this.
I may be a step behind, but given a grammar parser
Dear Philip, John and others,
I take the point that indeed a grammar approach would be the solution to
my problem. However, the grammar as it once stood based on Jonathan's python
program (which indeed works quite nicely) unfortunately doesn't help with
respect to the problem that I
: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Schultz,
Martin [m.schu...@fz-juelich.de]
Sent: 22 September 2012 16:26
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Another potentially useful extension to the
standard_name table
Dear Philip, John and others,
I take
.
From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Schultz,
Martin [m.schu...@fz-juelich.de]
Sent: 22 September 2012 16:26
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Another potentially useful extension to the
standard_name table
Dear
Dear Martin, Roy, John, Robert
Reading the last few days' emails all at once I have may have skipped
important details; if so, apologies for that. I too am in favour of a grammar,
such as my earlier attempt
http://climate.ncas.ac.uk/~jonathan/CF_metadata/14.1/
Robert subsequently coded this
@cgd.ucar.edu; Brown, Juan
Subject: Re: [CF-metadata] Another potentially useful extension to the
standard_name table
Hello Roy,
On 14/09/12 08:23, Lowry, Roy K. wrote:
Dear All,
I am becoming concerned that a 'design by committee' data modelling process
for Standard Names is unfolding
Dear all,
during the recent discussion on compound_name as additional tag in the
standard_names.xml file and in relation to track ticket #90 it occurred to me
that another useful addition could be to express the need of certain variable
attributes in this table as well. This refers to the
Hi Martin,
Is there some reason why the entry element must have a flat set of
sub-elements, as in your example below?It seems to me that from an
XML data-design point-of-view, a neater data model would be:
entry id=...
compound_name.../compound_name See note [1] below
13 matches
Mail list logo
