Hi Robert,
very good points! I like this idea of hierarchical
<attribute>...</attribute> and <compound>...</compound> structures. I just
don't speak XML well enough myself yet ;-) Only for the canonical_units things
are set in stone already, all other things are just beginning to be defined.
Just one question/comment, though: if we plan on further extending this
concept beyond <compound>, wouldn't it then make sense to generalize this
further? Example:
<controlled_item id="compound">
<name>trimethylbenzene</name>
<codelist>...</codelist>
</controlled_item>
etc. ? Or would this make it again more difficult to parse?
Cheers,
Martin
Von: Robert Muetzelfeldt [mailto:[email protected]]
Gesendet: Donnerstag, 13. September 2012 21:50
An: Schultz, Martin
Betreff: Fwd: Re: [CF-metadata] Another potentially useful extension to the
standard_name table: OFFLINE RESPONSE
Hi Martin,
I sent the following response to your email to the list this morning, but it
has not yet appeared (being moderated? - but I've posted OK before). So I
thought I would send you the reply directly, so you can be thinking about it.
If it's wrong/irrelevant/unworkable (given existing constraints in the XML
Schema or tools for handling these documents), then do feel free to say so when
my email eventually appears on the list. I won't be upset.
Cheers,
Robert
-------- Original Message --------
Subject:
Re: [CF-metadata] Another potentially useful extension to the standard_name
table
Date:
Thu, 13 Sep 2012 10:21:13 +0100
From:
Robert Muetzelfeldt <[email protected]><mailto:[email protected]>
To:
[email protected]<mailto:[email protected]>
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
<compound_codelist>...</compound_codelist>
<canonical_units> ... see note [2] below ...</canonical_units>
<description>...</description>
<attribute_list>
<attribute status="recommended" name="emission_sector"/>
<attribute status="recommended" name="emission_sector_reference"/>
<attribute status="recommended" name="compound_group_members"/>
<attribute status="optional" name="comments"/>
</attribute_list>
</entry>
This design is:
- more in keeping with conventional XML designs;
- allows for additional forms of 'status' without changing the DTD/Schema;
- facilitates processing (you are parsing *only* XML; you don't need separate
code to parse
the text string for each of your 3 original elements).
It is a matter of taste as to whether you prefer the above design of the
<attribute> element (i.e. with two (XML) attributes), or whether you would
prefer to have 'status' and 'name' as two sub-elements of <attribute>.
The following notes are not directly relevant to your suggestion, but I might
as well make the points now:
Note [1]
A similar argument as the above applies to the two <compound_...> elements,
which would I think be better represented as:
<compound name="..." codelist="..."/>
or
<compound>
<name>...</name>
<codelist>...</codelist>
</compound>
But it may be that this decision is already fixed in stone.
Note [2]
A similar argument applies to <canonical_units>, except here I think the
principled approach would be to use the W3C Units in MathML (
http://www.w3.org/TR/mathml-units/) or UnitsML ( http://unitsml.nist.gov/),
since both represent a concerted effort to develop a standard for representing
units in a machine-processable format. I can think of several reasons why
people might object vigourously to either solution: the current design is also
already fixed in stone; it is harder to write my hand; it is harder for humans
to read; it is much more verbose; and possibly quite simply that <entry> may
have to have a flat list of sub-elements (as per the first sentence of this
email). However, these standards exist for a good reason, and we should have
a good reason for not adopting them.
Cheers,
Robert
On 13/09/12 08:09, Schultz, Martin wrote:
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 attempt of creating a
"CF-1.6-strict" standard which would have more things mandatory in order to
better support interoperable applications.
One example (related to the new emission standard_names) could be:
-<entry id="
tendency_of_atmosphere_mass_content_of_alcohols_due_to_emission_from_industrial_processes_and_combustion">
<compound_name>Alcohols</compound_name>
<compound_codelist>http://rdfdata.eionet.europa.eu/airquality/components/??</compound_codelist<http://rdfdata.eionet.europa.eu/airquality/components/??%3c/compound_codelist>>
# ??
<canonical_units>kg m-2 s-1</canonical_units>
<description>"..." </description>
<required_attributes>None</required_attributes>
<recommended_attributes>emission_sector, emission_sector_reference,
compound_group_members</recommended_attributes>
<optional_attributes>comments</optional_attributes>
</entry>
The idea is that "optional" refers to "could" in the description, "recommended"
to "should", and "required" to "shall".
Best regards,
Martin
PD Dr. Martin G. Schultz
IEK-8, Forschungszentrum Jülich
D-52425 Jülich
Ph: +49 2461 61 2831
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Kennen Sie schon unsere app? http://www.fz-juelich.de/app
_______________________________________________
CF-metadata mailing list
[email protected]<mailto:[email protected]>
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
-----
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
