OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: Units of Measure

Good People,

I'll stick to my guns - it is not a good requirement.  When I read "it
should be up to an application or user intervention to determine the corect
unit", I think 'faulty requirement'.  If my application gets something it
doesn't understand, it can ignore it, issue a warning, or reject it - it
cannot "determine the correct unit".  When human intervention is carried
out, the effect is either transient (I'll manually fix this one, but the uom
given was and is 'erroneous') or permanent (I'll add it to the set of uom's
my program understands.)  The first solution is of no help if the uom was
not erroneous, as the error will recur until the application is made to
understand it.  The second solution says there is a specified list.  In a
production environment, pre-specification wins over post-specification in my
manual of best practices.  Ergo, the requirement (as written) is not a good

I've no disagreement with others that lists of valid uom's may expand over
time, and that lists of valid uom's may differ by industry, location, etc.
I agree it is a requirement to be able to make timely extensions to lists,
and that such extensions might have less than global visibility.  But I very
strongly believe that 'pre-specified' lists (including sufficient semantic
information to interpret each such list item) are a valid business
requirement.  And that is in contradiction to the stated requirement.  

I know that the submitter(s) of the requirement express a business need to
exercise timely local control over the list.  But as written, the
requirement seems to go beyond what is reasonable and good, as I've argued


-----Original Message-----
From: David Lyon [mailto:djlyon@one.net.au]
Sent: Monday, May 21, 2001 5:17 PM
To: Miller, Robert (GXS)
Subject: Re: Units of Measure


> 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
> up to an application or user intervention to determine the correct unit.
> Units of measure may be further delineated by the type of uom.

It's a good requirement that they mention. It's unpractical and unrealistic
to define every single unit of measure for every single industry. What if
somebody invents/patents a new type of product with a new type of measure
(as happens every week), they won't be able to sell it.

From a practical perspective, ebXML needs to go the way that the paragraph
reads otherwise using the applications in the real world will be too hard.
The guys that wrote the paper got this bit right.

----- Original Message -----
From: Miller, Robert (GXS) <Robert.Miller@gxs.ge.com>
To: <bobbitt@posc.org>
Cc: <ebxml-core@lists.ebxml.org>
Sent: Tuesday, May 22, 2001 2:02 AM
Subject: Units of Measure

> 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,
> 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
> give, its meaning is not precisely known, but the example does in fact
> 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
> 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
> 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
> 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
> 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
> 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
> to my definition, as a means to restrict and reduce the number of
> values for 'uom'.  For most types of measure, 'uom' would be restricted to
> 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.
> 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
> elements, I would argue that 'value' is of class 'quantity', and as a
> of said class included the defintion of the associated 'quantity'
> attributes.  Furthermore, to make that association very clear, I would
> 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
> volume or in a unit of energy.  But for a given gas source, the
> 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.
> 'linear rational transformation' is one very useful transformation, which
> can co-exist with other transformations, assuming the dictionary entries
> 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
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC