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
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20120913/6f2265dd/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20120913/6f2265dd/attachment.ksh>
Received on Thu Sep 13 2012 - 03:21:13 BST
