RE: Comments to Version 0.8-Reqts Specs OR A Country by any other name....

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

Gentle people,

Excuse me Steve. And thank you Bill for making quite clear the complexity we
face in doing business in this complex world.  All of the Business Modeling
we can conjur up won't make our lives simple, though it might help us better
understand and deal with that complexity.  In an ideal world, there would be
no complexity - one solution for one problem.  But in the world we live in,
we cannot even cleanly separate the problems, and the solutions, such as
they are, are legion.  Practically speaking, there are many examples in
current business practice of the FIPS 10-4 / ISO 3166 'close, but no cigar'
syndrome.  In EDI, we may know for example that FIPS 10-4 and ISO 3166 are
almost the same, and we may allow either to be used, but we have no hope
within EDI syntax to go beyond that.  XML holds promise as a means to go
beyond passive syntax to invoke automatic procedures that can cope with
these semantic complexities.  I suggest that it is not a goal of ebXML to
clean up the world's semantics; rather it is a goal to provide an
environment in which we can address semantic complexity to whatever level of
detail we choose.

Cheers,
       Bob

-----Original Message-----
From: William J. Kammerer [mailto:wkammerer@foresightcorp.com]
Sent: Saturday, April 29, 2000 9:01 AM
To: ebXML-requirements@lists.oasis-open.org
Subject: Re: Comments to Version 0.8-Reqts Specs OR A Country by any
other name....


Steve Klynsma, representing the US Army, comments that the Version 0.8
Requirements Specs Paragraph 2.3 "requires ISO 3166 for country name
codes.  There is current debate within DoD over acceptance of ISO 3166.
DoD currently is standardized on FIPS 10-4 which is not compatible with
ISO 3166. Army recognizes, that in a document designed to implement
global commerce, ISO 3166 is appropriate, but conversion to ISO 3166 for
the Army is likely to be economically impractical at this time."

Whereupon, Bob Miller lights into Steve with all the new XML-talk about
"unique semantic identifiers," "RDF Specifications" and "metadata."
Well, that went over my head, but I think Bob might be saying it's okay
with him if ebXML allows you to specify a country using whatever coded
specification you desire - just be forewarned that the "application,
military or otherwise, [has to] then find the metadata of interest to
it."  I think I know what that means -ebXML will tell you that you've
received a FIPS 10-4 country code, but you gotta figure out what country
it represents on your own.  Or something like that.

Well, I certainly think that as long as a code is unambiguously
identified as one promulgated by recognized standards body (e.g., ISO,
IEC, ANSI, IETF, EAN), industry group (e.g., TCIF, NRF), or even a
proprietary standards setter (like D&B DUNS), ebXML should have some
means of using which ever code list you want.  Thus, Paragraph 2.3 might
be softened to encourage the use of certain ISO standards.   For
example, ISO 3166 Country Codes may be preferred, defaulted, and maybe
even required in ebXML packaging (as opposed to the business messages
themselves), but Steve should be able to use FIPS 10-4 country codes as
much as he likes.

Steve can certainly do that now with EDIFACT.  The 1131/3055 qualifier
pair were designed for this express purpose, to allow you to describe
the code list at hand by naming the Responsible Agency in D.E. 3055, and
optionally (if not clear from the context provided by other segment
qualifiers) the specific code list.  So, with never having seen a FIPS
10-4 country code used in EDI, I still would understand:

    LOC+25+UK::168'

The LOC (PLACE/LOCATION IDENTIFICATION) segment here is used to further
identify a place or a location specified in a parent NAD (NAME AND
ADDRESS) or ADR (ADDRESS) segment group, for example.  The
Place/location qualifier (LOC-01 D.E. 3227) says we have a Country code
("UK") here in LOC-02-01 D.E. 3225, which was defined by FIPS (LOC-02-03
D.E. 3055  responsible agency) - in this case the "168" means the "US,
FIPS (Federal Information Publishing Standard)".  Simply because ISO
3166 is the preferred code set in EDIFACT there is a more convenient way
to specify the ISO country code directly in the NAD or ADR segment.  But
the LOC segment can also identify the equivalent ISO country code for
the United Kingdom - "GB":

    LOC+25+GB::5'

here, the 5 qualifier in D.E. 3055 simply means "ISO (International
Organization for Standardization)."

I don't know too much about semantic entities, but I guess it would be
the application's problem to go figure that the FIPS 10-4 "UK" code is
semantically nearly identical to ISO 3166 code "GB".   I say "nearly
identical" because the ISO "GB" code includes Guernsey, Isle of Man, and
Jersey, where presumably the FIPS code doesn't.  See the CIA's
Cross-Reference List of FIPS 10-4 and ISO 3166 codes at
http://www.odci.gov/cia/publications/factbook/appf.html.  You can see
the EDIFACT definitions for the LOC and its constituent elements at
http://www.unece.org/trade/untdid/.  The same kind of building-block
approach is taken in X12, though not nearly as elegant as in EDIFACT
with its LOC segment.

If the EDIFACT specification of country codes scares any of you XML
hackers, just imagine:

    <Country Authority="FIPS 10-4">UK</Country>
or
    <Country>GB</Country>

where Authority="ISO" is the preferred, and the default, authority for
Country codes.

What with all this talk of ISO 3166 and FIPS 10-4 to define country
codes, are we just reinventing EDIFACT?  All this stuff was figured out
long ago with EDI.  Unless ebXML can come up with something
significantly better, are we just spinning our wheels in order to be
"hip" and "cool"?

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

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