Subject: QRT's comments, DIN 16557-5, xCBL and EDIFACT
Now that QR has thrown back the CC specifications, does that now inevitably mean xCBL is to be incorporated into ebXML? Or does CC have another shot at getting (some) specs before the public prior to Vienna? What about QRT's comments that the Document Assembly & Context Rules Version 1.02 "still fails to address the requirement for EDI instantiation." What does that mean? If you wanted to instantiate EDI, why not just stick an EDIFACT or X12 interchange in the message business payload? What's that got to do with Core Components? The QRT's Requirements Traceability Matrix goes on to reiterate this with requirements like "Provides for migration path from legacy EDI" and "Support the interoperability between existing EDI and ebXML solution." Though there are vague allusions to migration from EDI in the Requirements specification, this is a new one on me [that such a requirement exists.] There seemed to be resistance to, or benign neglect of, my gentle suggestion that the spreadsheet be augmented with annotations giving the EDIFACT segment and element contexts of components; see http://lists.ebxml.org/archives/ebxml-core/200101/msg00042.html. So I had just assumed that any kind of retention of EDIFACT knowledge - presumably necessary for migration - was a dead letter. On another note, my good friend, Frank Dreisch of GEFEG mbH, offered up DIN 16557-5 on EDI-L as a solution to preserve the semantics within EDIFACT MIGs as they're carried over to XML. Check out Frank's comments at http://firstname.lastname@example.org/msg03099.html. If CC desperately needs something for the general plenary to be forced to vote on, and if xCBL is not a given, then do XML wrappers warrant another look-see? 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