Re: Just what is a Core Component? Or, when is stealing wrong?

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

Last Friday I examined the "means of transport.details" aggregate in the
Core Component catalog, Initial CC Structure v1-03.xls, sent out in
http://lists.ebxml.org/archives/ebxml-core/200104/msg00125.html by James
Whittle on 12 Apr 2001.   I noted the aggregate's similarity to the
UN/EDIFACT composite C222 Transport Identification, and was pleading
that the CC catalog refer to the EDIFACT composite on which an aggregate
is based.  This isn't a matter of accusing anyone of plagiarism - after
all, copying what already works is a healthy  phenomenon - but it's hard
to discern patterns and notice omissions if the original source is not
referenced.

I mistakenly noted that C222's 1131/3055 pair (for describing the
authority responsible for identifying the truck or vessel) was not
propagated to the "means of transport.details" aggregate.  I was
confused by "means of transport.identification.code" which was
identified as a "Basic" component - I didn't realize that "code.type,"
whence it was derived, was a complex component in its own right (i.e.,
an "aggregate").  The "code.type" component indeed simulates all aspects
of an identifier qualified by the 1131/3055 pair - i.e., it includes the
agency (code list.agency.identifier) and the coded list (code
list.identifier).  So, now,  it's perfectly clear C222 was used to
"discover" the "means of transport.details" aggregate.

Likewise, the "amount.type" aggregate at Line 26 looks like a subset of
UN/EDIFACT composite C516 MONETARY AMOUNT, used in the MOA segment, at
http://www.unece.org/trade/untdid/d01a/trsd/trsdmoa.htm, lacking the
(infrequently used) Currency type code qualifier and Status description
code.  It's also missing an analog to the EDIFACT D.E. 5025 Monetary
amount type code qualifier which would describe what the amount is all
about: e.g., Tax, Charge or Instalment amount.  If that was done on
purpose, was it because it was felt that the type or purpose would be
able to be divined from some "context"?  In UN/EDIFACT, the MOA segment
is commonly used to augment a TAX Duty/tax/fee details segment - the
latter describes the tax, the tax rate and the basis (e.g., weight or
quantity), with the MOA giving the actual tax amount.  In this case, the
"context" would be clear - it's the tax amount since the MOA was further
describing the TAX.  Or it could be the amount subject to the tax
described in the TAX segment, requiring calculations based on the tax
rate - an altogether different notion (requiring explicit qualification
using D.E. 5025 in EDIFACT).

So, if "context" really will say what kind of monetary amount is being
described with the "amount.type" aggregate, then why not rely on context
to say what kind of location is being described in the
"location.details" aggregate? The "location.identification.code" is
derived from "code.type," and hence has enough, in combination with
"location.description.text,"  to simulate everything in UN/EDIFACT
composite C517 LOCATION IDENTIFICATION, at
http://www.unece.org/trade/untdid/d01a/trcd/trcdc517.htm.  But there's
also a "location.type.code," which makes the aggregate behave more like
the LOC segment - which contains the C517 -  where D.E. 3227 Location
function code qualifier serves the purpose of the location type.  In any
event, we should explicitly acknowledge the LOC/C517 heritage in the
definition of the "location.details" aggregate so I don't have to go
hunting it down.

Similar borrowings from UN/EDIFACT are seen at Line 30 with the
"quantity.type" aggregate, which is just a rehash of composite C186 -
without any acknowledgement in the CC spreadsheet, at
http://www.unece.org/trade/untdid/d01a/trcd/trcdc186.htm.  UN/EDIFACT
all but mandates use of UN/ECE Rec. 20, at
http://www.unece.org/cefact/rec/rec20en.htm, for the Measurement unit
code, where both X12's D.E. 355 or the preferred recommended codes can
be used.   These seem to be adequate for all or most cases, so the
superfluous quantity unit code list.identifier and the quantity unit
code list agency. identifier can be discarded from the definition of
"quantity.type."  As an aside, why are these 1131/3055 look-alikes
defined as "string" data types, while in other cases derivations are
made from "code.type"?  By the way, don't ask me why the UN/EDIFACT D.E.
6060  Quantity is defined as an alphanumeric character string as opposed
to a numeric (which can accommodate "real" or "decimal" numbers).

I could go on and on about wholesale theft from UN/EDIFACT.  And say,
doesn't Line 102's "account.details" aggregate look suspiciously like
the FII  (Financial institution information) segment, or even the CPT
(Account identification) segment? The CPT seems to only be used in
accounting type messages -  the bane of Todd Boyle!

My point isn't that there's anything wrong with stealing.   But the
catalog at a minimum should acknowledge the source for each entry.  And
if all we're going to do is steal EDIFACT composites and segments for
building core components, why not dispense with the (manually built)
catalog altogether, and just build general rules for going from EDIFACT
to an automatically generated CC catalog?  If this is what we agree
should go into core components, then perhaps - since even the UN/CEFACT
EWG has its shorts in a bunch over modeling - we should model UN/EDIFACT
and build both the EDI syntax and the ebXML XML syntax from the
intermediate UML.  This would save valuable time and effort.

Keep in mind, though, the resulting core components would be just as
difficult to piece together and use as the EDIFACT equivalents.  But
since everything will be couched in terms of data models, XML and
schema, it will be billed as a great success warranting press coverage
the world over.  It will be our little secret that the CC catalog is
nothing but the EDI wolf in sheep's clothing.

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"