[eml-dev] [Bug 1019] - altitudeUnits in geographicCoverage should use eml-unitDictionary definitions

[bugzilla-daemon at ecoinformatics.org]

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=1019





------- Comment #4 from mob at icess.ucsb.edu  2008-10-09 17:08 -------
The consensus on the fix for this bug was to retype <altitudeUnits> from its
current "xs:string" to the named type "UnitDictionary".  Comments in this bug
also suggest that other areas of EML should be examined for their use of unit
declarations.  This comment addresses two issues: 1) retyping altitudeUnits,
and 2) other uses of units in datasets. An aside: in spatialReference and
spatialRaster the use of units is also somewhat inconsistent. But since these 2
schemas have been put on the back burner for now, those comments are in a new
bug (#3523). The proposed fix for 1019 here should also help clean up those two
schemas as well.

The current situation in EML 2.0.1 datasets:
Element declarations which employ some sort of physical unit occur in 4 places:
1. (attribute.xsd) standardUnit element under
dataTable/attributeList/attribute/...
There is of the type "UnitDictionary", which is defined in eml-attribute.xsd,
and includes a list of ~200 units which are described separately in a stmml xml
unitList.

2. (coverage.xsd) /boundingCooridinates/boundingAltitudes/altitudeUnits
the declaration under discussion. Currently simple type, xs:string

3. (physical.xsd) the optional //physical/size/ has an optional attribute
"unit" whose default value is "byte"
        <xs:element name="size" minOccurs="0">
          <xs:complexType>
            <xs:simpleContent>
              <xs:extension base="xs:string">
                <xs:attribute name="unit" use="optional" default="byte">
...

4.(resource.xsd) the optional element
//physical/distribution/offline/mediumDensityUnits/ It appears to be paired
with mediumDensity value, a sibling element which also optional, and could
contain a numerical value.
<xs:element name="mediumDensityUnits" type="xs:string" minOccurs="0">
    ...
     <doc:description>if a density is given numerically, the units should be
given here.</doc:description>
     <doc:example>B/cm</doc:example>
    ...
</xs:element>


So the current solution to 1019, retyping altitudeUnits as StandardUnit, means
that eml-coverage.xsd will have to import eml-attribute.xsd. This is going to
look odd for 2 reasons: 1) there is no logical reason for the coverage schema
to import attribute.xsd, and 2) authors will have access to ~200 units, where
only 22 are even close to appropriate for altitude, ie those that are
unitType="length" or parentSI="meter". And if you look at bug #3523, you'll see
that the spatial schemas define other simpleTypes for units (including one for
LengthUnits, just like is we need here).

So here is a new proposed fix for 1019:
create another schema file, (maybe named eml-units.xsd), whose only content is
the definition of unit types. At first these could include two types:
 <xs:simpleType name="LengthUnitDictionary"> 
which contains the length units, and
<xs:simpleType name="StandardUnitDictionary"> 
This Type could be identical to the current type in attribute.xsd (ie,
enumerate all the units) or it could be an extension of lengthUnitsDictionary.
I'll havent thought about benefits of  the possible constructs yet.

Regarding cases 3 & 4 above (unit = byte)
A third Type might be necessary at some point, since "bit" is allowable under
SI, but not in our dictionary. For now, they could stay as is.
<xs:simpleType name="InformationUnitDictionary"> 

Concentrating the units in one place keeps them from being scattered about in
the schemas, at the very least. Secondly, the spatial schemas could be cleaned
up somewhat by moving their Types to the new unit Type schema. Eventually, when
it comes time to decouple the units from EML, the needs of a new system will be
clearer if our current practices have coalesced.