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

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

Mary Kay Blantz tells us that "EDIFACT is a good format, and has much to
offer.  However, like X12, [it] has some problems that we do not want to
move into the new environment.  We are not just taking composites and
simple data elements out of either traditional EDI format. We start with
a model of the business process and work our way down to the lowest
logical level of data requirements.  If those happen to mirror something
already present in EDIFACT or X12, so be it."

I certainly appreciate that there are some aspects of UN/EDIFACT that we
don't want to carry over into ebXML.   For example, we've talked at some
length on the constructs available in W3C schema which might provide a
gentle tug in the direction of standardized datatypes for Date, Time,
DateTime, Period,or duration, etc. etc., based on ISO 8601.  As I noted
in "Re: ISO 8601 anyone?? And more on Parties," at
http://lists.ebxml.org/archives/ebxml-core/200104/msg00148.html, EDIFACT
composite C507 DATE/TIME/PERIOD is guilty of "comingling data types,"
which are better "...handled with separate datatypes in XML Schema."
Thus, the DTM segment (comprised solely of C507) might be triaged during
EDIFACT/ebXML modeling.

But I don't think I'm alone in hoping that modeling UN/EDIFACT will
result in processes that generate both the EDIFACT directories and the
ebXML Core Components, killing two birds with one stone.  Yes, I've seen
some pretty ugly stuff in EDIFACT, and a disciplined approach to
modeling might eliminate those artifacts without carrying the baggage
into Core Components.

I doubt anyone has seriously considered modeling ANSI ASC X12 components
(transactions, segments, composite or elements) as a basis for ebXML's
core components.  Any such parts of X12 we wanted to preserve would be
something modeled for inclusion in EDIFACT - on its way to Core
Components.   But since we're designing global business components for
the ages, it should be assumed that we start with UN/EDIFACT-  if any
EDI standard is to be used at all.  Those of us who love and cherish X12
needn't be treated as children, gingerly holding out the prospect that
our slop and big, long segments will be reincarnated as core components.
After all, in a strange twist of fate, we Americans are usually the ones
among our ebXML and EWG colleagues equally facile in the two languages
of X12 and EDIFACT.

I am somewhat skeptical that deriving core components using a top-down
approach will be as productive as starting off by modeling the EDIFACT
segment, composite and element directories.  But I anxiously await
enhancements to the Core Components Discovery and Analysis Methodology
specification which will assuage my doubts.  It may not be mere
coincidence if - after laborious modeling of the process - we end up
with core components which mysteriously mimic UN/EDIFACT composites and
elements.

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"