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


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

William,

> 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?

        Not sure I understand this.  Bosak's proposal was to use xCBL as the basis for tag names in a separate endeavor not associated with ebXML.

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

Actually, see section 3.5 of the requirements document, and I quote - "Provide methodology and examples for XML and EDI instantiation.  Further, the Requirements Traceability Matrix was developed by Requirements team for use by QRT and was based on the approved requirements document.  the phrase "provides for migration path from legacy EDI" is a general ebXML principal as stated in section 1.5 of the requirements document albeit the term "legacy" should be "accredited".  This concept is restated in section 2.5.4.2.  WRT the phrase "support the interoperability between existing EDI and ebXML solution" not sure I agree with that one.  Especially given the last sentence in section 2.5.4.2 and the note that follows it.

> 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?

        God I hope not.  The last thing in the world we want is wrappers.  My perspective is the core components documents do not, in their current form, adequately address the requirements document, nor do they provide what I had hoped they would - a consistent methodology to define core components.  In my mind, the core components would be the building blocks that, in conjunction with business PROCESS modeling, would be the basis for message constructs.  If ebXML does not derive an acceptable CC methodology that harmonizes with modeling, then the EWG/X12 initiative must, and will, pick up the banner and quickly finish the work. A primary focus of the June meeting in St. Louis will be to assess the state of the ebXML core component documents and 1) validate approved documents to include making changes where necessary to harmonize with EWG/X12 philosophy,  or finish what ebXML has started. 

Mark Crawford
Research Fellow - XML Lead
E-business Strategies
______
Logistics Management Institute
2000 Corporate Ridge, McLean, VA 22102-7805
(703) 917-7177   Fax (703) 917-7518
Wireless (703) 655-4810
mcrawford@lmi.org
http://www.lmi.org
"Opportunity is what you make of it"


> -----Original Message-----
> From: William J. Kammerer [mailto:wkammerer@foresightcorp.com]
> Sent: Monday, April 09, 2001 5:56 PM
> To: ebXML Core
> Cc: Frank Dreisch (E-mail)
> Subject: QRT's comments, DIN 16557-5, xCBL and EDIFACT
>

>
> 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.
>
>
> 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"
>
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
>



[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