[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Just what is a Core Component? Or, when is stealing wrong?
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"
Powered by eList eXpress LLC