EML

Changing QA contact to the list for all current EML bugs so that people can
track what is happening.

targeting for 2.1.0, although may drop back to unspecified.

schema bugs targeted for 2.1.0 set to P1

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.

Here is an example in which StandardUnitDictionary is a simpleType which is a union of other simpleTypes. This way, altitudeUnit would be of type=LengthUnitDictionary (in 2.1.0), and attributes are type=StandardUnitDitionary (as they are in 2.0.1). The big list of units can be broken up into various Types as necessary, and then grouped together with xs:union. The Types used in the spatial schemas could be kept here as well. These definitions should not affect unit-elements that are already typed.

<xs:simpleType name="LengthUnitDictionary">
<xs:restriction base="xs:string">
<xs:enumeration value="meter"/>
<xs:enumeration value="nanometer"/>
...etc
</xs:restriction>
</xs:simpleType>

<xs:simpleType name="MassUnitDictionary">
<xs:restriction base="xs:string">
<xs:enumeration value="gram"/>
<xs:enumeration value="milligram"/>
... etc
</xs:restriction>
</xs:simpleType>

<xs:simpleType name="StandardUnitDictionary">
<xs:union memberTypes="unit:MassUnitDictionary unit:LengthUnitDictionary"/>
</xs:simpleType>

The altitudeUnits documentation stated that the element content should include the vertical datum. We are now restricting this element's content to length units. However, this is a descriptive element, and the spatialReference schema has detailed elements for altitude system descriptions. We can still suggest that authors include a datum for altitude (such as "mean sea level") but this text now should be included in the geographicDescription field, which is text Type.

In addition to retyping altitudeUnits from xs:string to unit:LengthUnitType, I retyped altitudeMinimum and altitudeMaximum to from xs:string to xs:decimal

documentation is done per comment #6, and examples are consistent with retyping.

Original Bugzilla ID was 1019