Re: ebXML core components diagrammed,or Whassup with all that derivation???

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

Many thanks to Mike Conroy for the UML diagram of the Core Components
Catalog.  I'm certainly no fan of UML diagrams, but this one was useful
for picking out potential pitfalls in the catalog.  A lack of balance -
or busy-ness - in the diagram beckons us to investigate further.

My eye is drawn to the big empty box entitled "identification.details" -
like Rome, it has all roads leading to it.  For some reason, that sets
off warning bells.  First of all, the identification.details aggregate
depends on the code.details aggregate, which is extremely EDIFACT'ish
looking.  Of course, I love the 1131/3055 pair, but basing practically
everything on such a structure is overdoing too much of a good thing -
which I would say even if this were tired old EDI.

Too much freedom is sometimes a bad idea. I think deriving many of the
core components from identification.details gives leeway where none is
needed.  For example, the currency aggregate is derived from
identification.details, in turn derived from code.details, presumably to
allow the use of currency codes other than ISO 4217:1995 -  Codes for
the Representation of Currencies and Funds, at
http://www.bsi-global.com/iso4217currency.

Even if there were other code lists for currency, their use would be a
special exception which wouldn't justify making the basic entity for
currency carry so much baggage; a new currency object could be devised
in that case.  Even UN/EDIFACT makes do with ISO 4217 exclusively for
denoting currencies. And there's no need to distinguish between the
numeric and the alpha codes of ISO 4217 with a qualifier, as the
recipient can tell the difference. If the intent were to signify what
the currency is used for (e.g., Reference currency vs. Target currency),
then that is certainly not clear from the matrix.

The same thing attends the "country" aggregates, further complicated by
there being multiple "countries" - account.country within
account.details and country within postal address.details - both derived
from identification.details.  If they do the same thing, they should be
derived from a common simple core component restricted to codes from ISO
3166-1:1997 - Codes for the representation of names of countries and
their subdivisions -- Part 1: Country codes, at
http://www.din.de/gremien/nas/nabd/iso3166ma/index.html.  There's no
ambiguity between the 2 and 3 alpha country codes, or the numeric code
of ISO 3166-1, hence no need for the baggage of the code list.identifier
or the code list.agency.identifier.   The country core component should
just be a basic identifier, whose values are understood to be enumerated
by ISO 3166-1.

Assuming that party.nationality within party.details is also supposed to
be an ISO 3166-1 country code, why not use a common base core component
intended to designate countries? Then you wouldn't need three different
"countries" all derived from the more abstract identification.details.
Additionally, I realize that basing such components on
identification.details drags along text.details, which might be useful
for holding a natural language description of the ISO 3166-1 country
code; but in actuality, that would be little used - a readable
description is a crutch unneeded by "real" B2B interoperability.

Though we're talking about party nationality, which could always be
based ISO 3166-1, I think boats (you can tell I wasn't in the Navy) also
have "nationality" designated with yet some other type of code, like a
Lloyd's or Maritime Administration flag code.  Still other applications
might require the FIPS 10-4 country code, at
http://www.odci.gov/cia/publications/factbook/docs/app-f.html.  These
are much less used (i.e., industry or government specific), and don't
necessarily warrant support in the base core components, though
particular sectors could derive their own to support these lists.

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

Visit FORESIGHT Corp. at http://www.foresightcorp.com/
"accelerating time-to-trade"