Units of Measure

["Miller, Robert (GXS)" <Robert.Miller@gxs.ge.com>]

John,

Your Email soliciting comments on this topic recently hit the ebXML-core
list, and has evoked some discussion.  But it appears you have not been
copied on this discussion thread.  If you are not a member of this list, let
us know so that those who intended that you see their comments can forward
their responses to you.

I have read the attachment you sent, and offer the following comments:

Usage needs:  

I take issue with need:
	"8. The method must allow for cases where a unit of measure is
given, but its meaning is unknown.  For example, a unit of pressure may be
given as pounds per square inch, but it is not known whether this is gauge
pressure of absolute pressure."

In my opinion, there is little use for meaningless data.  In the example you
give, its meaning is not precisely known, but the example does in fact limit
the meaning to one of two possibilities.  In my opinion, what is being
measured is as at least as much a part of the required information as is the
unit of measurement.  Therefore, the element that conveys a measurement
value must also convey both the unit of measurement for that value and the
semantic meaning of that value (to the fll extent that the semantic meaning
is known).  This may be accomplished either in the element instance or by
reference in the schema to other elements or default values.

I take issue with need:
	"9: The method should not restrict the unit of measure to a
pre-specified list. If an "erroneous" unit of measure is given, it should be
up to an application or user intervention to determine the correct unit.
Units of measure may be further delineated by the type of uom.  For some
such types, it may be appropriate and desirable to restrict the 'uom' to a
pre-specified list. I therefore support he option on this issue provided
later in this report.  Whether such restrictions on 'uom' value are enforced
by the Schema should be left to the designers, just as this paper leaves
open the method by which 'uom' is specified as an attribute or as an
element.


Quantity Data Type - Recommendation:

In my opinion, a representation of quantity must provide access to both the
unit of measure, and to the semantic meaning of the quantity value.  My
personal preference for representing the quantity primitive would be, by
example, <Quantity  measure="end-to-end"  uomtype="length" uom="feet"
scale='1' value='23.4' />  Note that I have also added 'uomtype' and 'scale'
to my definition, as a means to restrict and reduce the number of allowable
values for 'uom'.  For most types of measure, 'uom' would be restricted to a
known set of values.  

In this section, there is also discussion (Comments and Issues) of the
inheritance of a 'uom' from a 'higher level within the content'.  In my
opinion, inheritance rules should be explicitily defined in the Schema.  How
this is to be accomplished is an issue, as I've not seen it addressed
elsewhere.  In my opinion, it is not acceptable to rely on hierarchical
structure and some vague reference to inheritance 'from a higher level' to
effect the setting of default values.  Rather, the Schema should provide a
pointer to the element from which a default is to be assumed.

Extensions:

Representation of 'lists of values', 'array of values', and 'tuples of
values'  

In my opinion, the schema should be explicit in defining the source of
default attribute values.  In the examples you present with multiple 'value'
elements, I would argue that 'value' is of class 'quantity', and as a member
of said class included the defintion of the associated 'quantity'
attributes.  Furthermore, to make that association very clear, I would have
used an element 'quantity' in place of the element 'value'. in those
examples.  I would also suggest that this document provide references to
other sources which address the representation of lists, arrays and tuples
in XML syntax.

Options - Unit of Measure Conversions: (Equivalence Class linking)

Just have an interesting comment to add here. In the natural gas pipeline
industry, gas contracts may be specified and measured in either in a unit of
volume or in a unit of energy.  But for a given gas source, the relationship
between the two measurements is known, so conversions may be made between
the two.  

In my opinion, the details of a transformation method should be hidden
within some named procedure having a specified set of input parameters. The
'linear rational transformation' is one very useful transformation, which
can co-exist with other transformations, assuming the dictionary entries for
the 'uom's include not only the definitions of the parameters but also the
definition of the routine to which the parameters are supplied.  This
reference to the procedure appears to be missing in hte
'ConversionToBaseUnit'

With this in mind, I observe that conversion of currency is indeed like
conversion of unit of measure (given the appropriate parameters, an
algorithm can perform the converison).  Still, I would recommend that
currency be considered a different primitive data class than quantity.

Cheers,
               Bob Miller