OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


William

> 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.]

One of the original requirements was that you should be able to take the
components of an existing EDI message and write an ebXML equivalent whose
contents could then be transformed back to the original EDI format as an
EDI-conformant instantiation of the ebXML message. This presumed that there
would be some sort of record in the registry of which EDI segment/data
element each CC message component was derived from. It is also presumed that
for a given existing EDI message there will be an ebXML equivalent. This
concept seems to have gone by the board in recent months.

Martin Bryan



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC