Re: Units of Measure

["William J. Kammerer" <wkammerer@foresightcorp.com>]

John Motley, of Global Technology Services, Ltd., shared with us a
technique for equating XML tags with ISO BSR (Basic Semantics Register)
Semantic Components; see
http://forum.afnor.fr/afnor/WORK/AFNOR/GPN2/TC154WG1/.  I suppose
there's no harm in correlating (arbitrary English language labeled) data
with the BSR Semantic Component IDs.

Actually, it may help in understanding what the label <addressLine> is
to contain, as in

   <addressLine BSRID="226">123 EAST MAIN STREET</addressLine>.

Equated to BSR ID 226, I know that it is "A path or a way in a city,
town, village, etc. Note: The term street is considered generic and can
include other similar terms such as road, avenue, boulevard, etc. Street
Synonym(s): Road, avenue, boulevard, etc. Context: Postal address."
Ahhh...., that straightens out any possible confusion! Plus: the BSR
gives me handy tags in English, French and German that I can use as
legends or labels on human readable renderings; e.g., "Street," "Voie,"
and "Strasse." That's nice.  But, John, why would I want to send all
those BSRID attributes along with my data over the wire, again and
again?  Presumably my trading partner would need the BSR ID equates only
once, along with the DTD.    Instead of the attribute BSRID defined in
ELEMENT addressLine as

    BSRID CDATA #REQUIRED

you could specify the correspondence to the BSR directly in the DTD
element type declaration with

    BSRID CDATA #FIXED "226"

Then you wouldn't have all these redundant BSRIDs clogging up the
Internet;  they would have been picked up once when the DTD was
retrieved from the repository.

But in any case, John, I don't know what all this has to do with
standardized code lists, which I was talking about earlier in response
to Bob Miller.

I earlier tried to show that we shouldn't encourage the abandonment of
standardized code values in favor of open text, mostly to avoid
ambiguity and language issues.  Sending a UN/ECE Rec. 20 code value (or
ASC X12 D.E. 355 UOM code) for pound or meter or whatever is superior
than sending the word "pound" or "meter" because programs can handle
neutral codes better than text.   E.g., is it "meter", "meters",
"metre", or "metres"?? - "MTR" (Rec.20) is unambiguous.  If the
recipient wants to display "metre" or "m" or "meters" to accompany the
data on some web form, that's his business - he can do that with a
program or style sheet.  But what goes over the wire should be
unambiguous and leave little room for guesswork since I can't guess at
who's going to receive my data and what language they speak - that's
where standardized national, international or industry codes are
invaluable.

Some may think it's clever to send "Columbus" as the destination airport
in the XML rendition of an air waybill message because it's readable
(and, by golly, if XML is anything it should be *READABLE*). But which
Columbus airport? - the one in Ohio, Nebraska, Mississippi, Michigan,
Indiana or Georgia? Just because Columbus, Ohio is the biggest and best
Columbus doesn't mean that I can assume anything.  So you add Ohio to
the mix, coming up with "Columbus, Ohio". Which one - the big one, or
the Ohio State University airport?  One pilot of a commercial airliner
once confused the two - to the detriment of his career.   So how am I to
know that you meant "Port Columbus International Airport"? Why not
simply use the IATA or UN/LOCODE "CMH", which is completely unambiguous
and almost as recognizable as "LAX" by sophisticated world-travelers
regardless of their language?

Or what do I do with <Size>8</Size> or <Color>Lily White</Color> when I
get an XML order for clothing?  - wouldn't I be better off with the
unambiguous size code 30108 or color code 100, respectively?  If I need
an English rendition of these codes, I can go to the "recognized"
source - the NRF Size and Color Codes.

I suppose there's no problem providing some means of "babying" the
recipient and sending an English Text description to *augment* the code
which he can use for display purposes (in case the recipient doesn't
have easy access to the airport codes or the NRF Size and Color
Handbook), but only the code value can really be the semantic laden
nugget o' information which can be mechanically  processed for automated
B2B interoperability.

William J. Kammerer
FORESIGHT Corp.
4950 Blazer Memorial Pkwy.
Dublin, OH USA 43017-3305
+1 614 791-1600

Visit FORESIGHT Corp. at http://www.foresightcorp.com/
"Commerce for a New World"




=======================================================================
= This is ebxml-core, the general mailing list for the ebXML          =
= Core Components project team. The owner of this list is             =
= owner-ebxml-core@oasis-open.org                                     =
=                                                                     =
= To unsubscribe, send mail to majordomo@lists.oasis-open.org with    =
= the following in the body of the message:                           =
=      unsubscribe ebxml-core                                         =
= If you are subscribed using a different email address, put the      =
= address you subscribed with at the end of the line; e.g.            =
=      unsubscribe ebxml-core myname@company.com                      =
=======================================================================