QRT's comments, DIN 16557-5, xCBL and EDIFACT

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

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://www.mail-archive.com/edi-l@listserv.ucop.edu/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"