Re: Units of Measure

[jmotley@globaltechltd.com]

Why couldn't you use both?

For example;
(Please note the 3rd line of the XML and its attributes)

<?xml version="1.0"?>
<!DOCTYPE ebXML_ASN_Message SYSTEM "LOGNETASN.dtd">
<ebXML_Message MessageDate="2000-07-07" MessageTime="19:32:03.323" ID="32100212"
 Rendering="LOGNET_V4.00_USENGLISH">
    <sender BSRID="713">
        <tradingPartner BSRID="151">
            <partnerRole BSRID="876">SENDER</partnerRole>
            <partnerID BSRID="877">ACME002</partnerID>
            <partnerName BSRID="135">ACME EXPORTING</partnerName>
            <postalAddress BSRID="611">
                <addressLine BSRID="226">123 EAST MAIN STREET</addressLine>
...

A portion of the corresponding DTD would look;

<!--
 LOGNET Version 4.00 ebXML Object Based Advanced Ship Notice DTD
-->
<!ELEMENT ebXML_Message (sender,receiver,ASNtransaction+)>
<!ATTLIST ebXML_Message
 MessageDate CDATA #REQUIRED
 MessageTime CDATA #REQUIRED
 ID CDATA #REQUIRED
 Rendering CDATA #REQUIRED
>
<!ELEMENT sender (tradingPartner)>
<!ATTLIST sender
 BSRID CDATA #REQUIRED
>
<!ELEMENT receiver (tradingPartner)>
<!ATTLIST receiver
 BSRID CDATA #REQUIRED
>
<!ELEMENT tradingPartner
(partnerRole,partnerID,partnerName,postalAddress,contactParty)>
<!ATTLIST tradingPartner
 BSRID CDATA #REQUIRED
>
<!ELEMENT postalAddress (addressLine+,city,postalCode)>
<!ATTLIST postalAddress
 BSRID CDATA #REQUIRED
>
...

An X12 message would simply be another "RENDERING" with a different DTD.
It would be required to have the ebXML_Message and its attributes in english
and all elements must have the BSRID attribute.

One could then look up the BSR elements and select the appropriate
rendering (i.e. CHINESE) to swap an alternate rendering of the XML.
The repository could also contain the  appropriate XSLT to transform
RENDERINGA in to RENDERINGB.  XMI or raw DTDs could be
registered as well for reference and validation.

One could then easily translate between coded renderings in say a
rendering of ANSIX12_4010 codes to ANSIX12_3050 codes or to US English
text.  They could also transform from ANSIX12_4010 structure to ANSIX12_3050
structure if the appropriate XSLT is available.  The only dependencies
are that ebXML_Message and its attributes are english as would be
BSRID and the text ID when used as an attribute.

This is an approach we are taking for rendering and transformation
for X12, USENGLISH, GERMAN and CHINESE renderings.

As part of the project we plan to make a server available for
project participants to post DTDs, XML and XSLT and have the
message transformed or validated and returned in an XML stream
of in HTML after style sheet processing.

Regards,
John Motley





"William J. Kammerer" <wkammerer@foresightcorp.com> on 07/07/2000 03:06:32 PM

To:   ebxml-core@lists.oasis-open.org
cc:    (bcc: jmotley/Globaltechltd)

Subject:  Re: Units of Measure



Bob Miller brought up interesting aspects of codification, especially
those derived from X12, and means of representing aspects of coded
semantics in XML.

Bob says some code lists perform a 'text alias' service - e.g., X12 DE
1109 Race or Ethnicity Code has values 7 (Not Provided), C (Caucasian),
H (Hispanic), etc.  He says the same code could be represented in XML as
<Ethnicity>Hispanic</Ethnicity>.  I think there are a couple of problems
with this technique of spelling out the value (of what used to be a
simple code).  Though I'll admit it's easier for a human reader to
discern the ethnicity in Bob's example, it will be harder for programs
to process.  Especially considering all the attendant problems of
capitalization (is 'Hispanic' the same as 'hispanic'?) and misspellings.
Data categorized by D.E. 1109 will often be mechanically sorted and
collated by ethnic and racial categories - small discrepancies in the
element value will make this difficult.  This is unlike misspellings and
the like in street addresses, which are generally read by humans only
(it's usually only the 9 digit ZIP which has to be exact for data
processing needs).

It would have been easier if the OMB had devised a definitive code list
for racial and ethnic classifications in its directives, which could
then be used unchanged for data processing purposes.  Instead, the OMB
just rambles on and talks about various types of ethnicity and racial
classifications, leaving it up to X12 to come up with a code list and to
deal with the various ambiguities (maybe this isn't a problem in EDIFACT
since other countries aren't as obsessed with "classifying" their
subjects).

Besides the problems with capitalization and misspellings, you would
also have to deal with the complete redesignation of categories,
depending on political whim and correctness.  What was a "Caucasian"
yesterday may be a "White" today, and "Anglo" tomorrow (regardless how
absurd this sounds since almost all English-speaking Euro-Americans
aren't of English descent at all, and it's probably offensive to Irish
and German Americans).  How would a program deal with these renamings -
keep a table of all the text synonyms?  No, I think classification by
codes, effective in EDI, is needed just as much in XML based core
components.

Then there's the translatability problem with the so-called "Textual"
codes.  Certainly country and currency codes would fall into Bob's
category of 'text alias'.  Maybe <Country>Germany</Country> might be
more understandable by the casual reader, but <Country>DE</Country>
using the ISO country code is easier to process by programs, and is far
more standardized.  And <Country>Deutschland</Country> is just as
readable by English speakers. And is it "United States" or "United
States of America," or is it "Bundesrepublik Deutschland" instead of
"Germany"?  Are we going to expect our programs to do on-the-fly
translations, or to maintain complicated synonym tables?  - remember, I
have to know the country so I can prepare the proper customs papers,
calculate shipping, etc. etc.  Codes were invented to remove ambiguity -
they're just as necessary for unambiguous interpretation of XML data as
with EDI.

And for those codes which perform a 'reference' service, as unit of
measure in Bob's example <Weight Code='Pounds'>10</Weight>, I don't know
why there would be any doubt we would use the standard UN/ECE
recommendation 20 for UOM.  What kind of "Pounds" is Bob talking
about? - I'm sure there are different types, like dry pounds.  And
"Pounds" is plural - what if I have only 1 pound????  Does my program
have to account for the 's' somehow?

Are we trying to make "readable" XML for idiots, or are we trying to
find a better way to perform automated B2B interoperability?  Let's just
use the standardized codes which were invented for practical reasons
pre-dating even Traditional EDI.

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





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