RE: Units of Measure

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

John,

So I converted the values to the well known 'meters', built and shipped the
widget per the (presumed) PO.  But it didn't fit, because the 'guess' at the
conversion was incorrect - it wasn't the correct conversion.  Who pays for
the mistake?  

The '<unknown/>' clues me that I ought to be wary of just building and
shipping the widget.  If this could be the start of a new client
relationship, I'd want to get rid of the 'unknown' before I built and
shipped that widget.  Don't want to make a bad impression by shipping the
wrong size widget.  If the 'unknown' were not there, I would just build and
ship, and let my lawyer go after the payment if the widget was the wrong
size, since the I performed in conformance with the 'contract'.  By the way,
if my plant manager ignores the red flag, builds and ships anyway, my lawyer
will still go after the payment, with the argument that the conversion
information is definitive.  He'll probably win.  He's very proficient (and a
tad expensive, but hey you get what you pay for).

So let's see where we stand.
 1) If <unknown/> is present, we maybe talk.  I get some written evidence
(e.g., a new message with <unknown/> removed) that the lengths in meters are
correct, and then I proceed to build and ship.  Or we maybe just build,
ship, invoice, and collect.  If the guess is wrong, the originator likely
pays for his mistake.
 2) If <unknown/> is not present, and the guess is wrong, the originator
pays for his mistake.  

Bottom line I read from this is that there is little good, and much harm
that may accrue to the originator from sending bad data.  So why is it you
want to facilitate such behavior?  Is my lawyer your cousin, perhaps?

Cheers,
        Bob 


-----Original Message-----
From: John Bobbitt [mailto:bobbitt@posc.org]
Sent: Tuesday, May 22, 2001 11:05 AM
To: Miller, Robert (GXS)
Subject: Re: Units of Measure


Bob,

Perhaps a simple example. (BTW, I cannot send to the general ebxml-core
list, because I am not subscribed to it. So this message goes only to
you).

A person has data, and the data is given in "ft". I would like to exchange
the data, but have not idea what kind of a foot this is (I am assuming it
is a foot). So I will make a best guess, but I also need to let the person
know it is a best guess:

<listOfValues uom="#ft">
  <values>.....</values>
</listOfValues>
 . . . .
<UnitOfMeasure id="ft">
  <unknown/>
  <conversionToBaseUnit baseUnit="#m">
    <numerator>12.</numerator>
    <denominator>39.37</denominator>
  </conversionToBaseUnit>
</UnitOfMeasure>

In writing the above, I make the statement that I really don't know what a
"ft" is. but I will still give you a conversion (in this case, for a US
Survey foot). However, it may be a clark foot, or an international foot,
or an indian foot. I really don't know.

This is an example of where this need might arise. It also gives a way for
the sender to say, "I am giving you this information, but I can't vow for
its correctness."

Is it better to make a best guess and fool the receiver? Or to tell him
this is a best guess?

John

"Miller, Robert (GXS)" wrote:
> 
> 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
> requirement.
> 
> 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
> above.
> 
> Cheers,
>          Bob
> 
> -----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
> 
> Robert,
> 
> > 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.
> 
> 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,
> 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
> >
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
> >

-- 
John I. Bobbitt
Energy eStandards          Web: http://www.energyestandards.org
Off:(713)267-5174          Web: http://www.posc.org
Fax:(713)784-9219          email: bobbitt@posc.org
Many ideas grow better when transplanted into another mind than
in the one where they sprung up.    --Oliver Wendell Holmes