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


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


[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