Re: core components analysis

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

More comments re: the CC Analysis Document; see
http://lists.ebxml.org/archives/ebxml-core/200012/msg00009.html.

On Wednesday, I misread the table for the Language Aggregate.  I can now
see that it has its own definition at line 107, which includes a base
component, Language Code (Identifier), which refers to ISO 639-1988.
Though Martin Bryan thinks ISO 639 is incomplete, and instead advocates
IETF RFC 1736, I think the deficiencies of the language code list have
been addressed by ISO 639-2 which is an extension of the ISO 639-1 code
set, and takes care of every oddball and obsolete language out there;
see http://lcweb.loc.gov/standards/iso639-2/englangn.html.  I think the
Library of Congress as the RA for ISO 639-2, and a language authority in
its own right, trumps the IANA. The Dublin Core makes allowance for
using either technique, though.

Line 20: Party Identity aggregate.  Is Identification Code an enumerated
list of values identifying the authority responsible for assigning the
Identifier?  If so, the discussions ongoing in TR&P under the thread
"PartyId and Context" re: identifier authorities (e.g., UN/EDIFACT D.E.
0007, ASC X12 D.E. I05 and  ISO 6523) are relevant here.  See
http://lists.ebxml.org/archives/ebxml-transport/200012/msg00131.html.

Line 31: Address aggregate.  Are Building/House Name, Building/House
number, Street name, Lot identifier, Apt number, Mailstop, Area name,
Sub area name, Floor number, Block number, Address number and P.O. Box
Number really all necessary for any business domain? Especially travel?
Except for specific applications like mortgage loan applications, and
real estate appraisal and taxation, why would all this stuff be needed
broken out for an address? I would think these fields would only be
carried along as readable data for the postman.   For most business
purposes, X12's N3  and EDIFACT's NAD are adequate by simply providing
repetitions of an Address line.

Breaking out street addresses into every conceivable constituent is a
bit like decomposing telephone numbers unnecessarily, considering that
they're probably going to be read by humans.  Which brings us to:

Line 55: Communication Point aggregate.  Is breaking out the telephone
number into Telephone Country Code, Telephone Area Code, Telephone Local
Code, and Telephone Ext really necessary, esp. when ITU-T Rec. E.123,
Notation for national and international telephone numbers, exists for
formatting them?  See some comments on telephone numbers at
http://lists.ebxml.org/archives/ebxml-architecture/200004/msg00044.html,
which also talks about dates and times and brings us to:

Line 79: the Date/time aggregate.  All of the base components Date, Time
(and their respective formats) and Time zone offset can be accommodated
in one field by conforming to the ISO 8601 Date and Time Format; see
http://www.iso.ch/markete/8601.pdf..  XML Schema Part 2: Datatypes
already support many ISO 8601 Date and Time Formats natively.

Line 48: The County name component in the Address aggregate is overkill
in U.S. addresses. And if needed, it's most certainly desired to be in a
format that's machine processable, as in mortgage loan processing  or
tax applications.  X12 readily accommodates passing the County name in
either readable or coded format, the latter for U.S. locations as a
FIPS-55 county code.

Line 119: What's the difference between Unit of measure component in the
Product/service aggregate, and Unit type code in the Quantity and
Dimensions/Measurements aggregate?  The latter should be named Unit of
Measure, and should be the kind of stuff (meters, feet, liters, etc.) in
X12 D.E. 355 or UN/ECE Recommendation No. 20 - Codes for Units of
Measure Used in International Trade, at
http://www.unece.org/cefact/rec/rec20en.htm.  Since the Brief
Description accompanying the Unit of measure component in the
Product/service aggregate reads "Same part number could be for a coil or
cut length of a product," and coils and cut lengths are not UOMs, this
component should be renamed. Just because X12 D.E. 355 (Unit or Basis
for Measurement Code) commingles measurement units and "coils" and
"bobbins"  and "Hogsheads," doesn't mean we should!

But one nice thing X12 provides, absent from UN/EDIFACT, is some means
to apply exponents to UOMs so you don't have to really invent a code for
Terabecquerel, when you can  use composite element C001 - Composite Unit
of Measure - to say Becquerel raised to the 12th power (R2:12).   Can we
make the ebXML CC Unit of Measure an aggregate to accommodate exponents?

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"