RE: Units of Measure

[Rachel Foerster <rachelf@ix.netcom.com>]

William,

Very well put. This is where the rubber will meet the road with XML and its
human readable tag requirement. Actually, if I understand the XML
Recommendation correctly, it's only the tag that must be human readable,
correct?

Rachel

>
> 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
>         =
> ==============================================================
> =========