Re: ebXML core components diagrammed,and more comments on the Initial Core Components Catalogue

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

Mike Conroy is looking for validation from the CC team for his UML data
model of the Initial Core Components Catalogue.  I guess I'm just a CC
wannabe, so my thanks probably don't count.  Yet it does seem to be a
faithful graphic representation of the core components that I've looked
at. And as I mentioned before, I found the model very useful in
discerning some of the problems already pointed out with respect to the
massive amount of (unnecessary) derivation from identification.details.

Looking at the UML data model, which is always handy at my side, another
problem pops up. Wow! - that's a lot of stuff in the poor postal
address.details aggregate!  Are we sure we haven't forgotten anything?
What about the Rural route number? Or the Sub-barrio? Carrier Route? The
point isn't that these are all that important - but they're probably
just as important as "Lot identifier," which is in the catalog.

X12 and UN/EDIFACT don't even attempt to provide pre-defined slots (or
elements) for these items - add one today, and you find you need another
tomorrow. This is where we should pay heed to John McClure and simply
normalize the structure and use a coded list.  Even the fast-track speed
of adding code values to X12 and EDIFACT doesn't suit some people - now
the Electronic Commerce Code Management Association (ECCMA), at
http://www.eccma.org/, has devised the International Address Elements
Code (IAEC) for describing "the components of a postal delivery address
for domestic and International and Domestic mail delivery."  You would
simply refer to the IAEC codes indirectly using a structure like
EDIFACT's 1131/3055 pair - or in ebXML with the identification.details
aggregate.

Now, most of us might be able to get by just using postal address lines
rather than breaking up each part of the street address, so something
like this should be kept in the postal address.details aggregate.  But
even UN/EDIFACT and X12 don't go to the trouble to name each possible
address line - they make do by simply repeating the same address data
element.  And EDI does this mostly because you can't split the lines up
with new-lines so the address appears as you would want it on the
envelope or screen.

Logically, the address lines are nothing but a collection of text, and
with XML there's nothing to keep us from simply delimiting them with
significant new-lines so the entire mess is ready for printing or
display. Even if you were to insist in keeping address lines separate,
there's no need to treat each line as an individually named entity
(e.g., postal address. line 1.text, postal address. line 2.text, and so
on) - why not define one entity with a cardinality  of 0..* (0, 1, or
more)?

Returning to the catalog spreadsheet -  I love the turgid definition of
state.identifier: An organised political community or area forming a
part of a federation.  Somebody obviously got that one out of the Oxford
English Dictionary. The U.S. couldn't even loosely be considered a
federation since the Civil War, and probably hasn't been one since the
Articles of Confederation.  Shades of Star Trek!  Would it be too much
to ask that we simply use terminology from ISO 3166 -  "Country
Subdivision Code" and then simply refer to that standard for a
definition and constraints?

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"