RE: xCBL and openness

["Gregory, Arofan" <arofan.gregory@commerceone.com>]

Phil:

Who is talking about "throwing away" EDIFACT?

The point is, that the *syntax* used by EDIFACT is being replaced in many
techonology circles by XML. xCBL and other XML vocabularies have - if
well-done - based their semantics on EDIFACT. But the influence of a syntax
on the structures in many cases is one that conflicts with modelling the
same semantics in XML.

This doesn't count as "throwing away" - I think what is happening in ebXML
is a harmonization and distillation of what is best in EDIFACT and X12
(semantics), so that we can build a good solid XML standard *syntax*
expression maintained through an open process.

xCBL as it exists today is a very large vocabulary, because it lacks the
concepts of context that ebXML is exploring, and because most XML systems
don't support the use of XML namespaces very well (although this is rapidly
changing). the next iteration of xCBL - whether done through and open
process or not - will leverage both the ebXML context concept and the use of
namespaces to modularize in such a way that it becomes both smaller and more
manageable. Further, it will make greater use of run-time extension
processing, something that is not available in older technologies (such as
traditional EDI syntaxes and DTD-based XML).

In no way is EDIFACT's work being "thrown" away. I guess if I believed that
this was the case, I wouldn't even be a part of ebXML, and the same holds
for the work done in X12. They represent the work that we are starting with
- the semantic basis of all of ebXML Core Component work.

As for the capabilities of EDIU syntax, that is a different story: as
technologies, XML and EDI are very unlike, and I would argue that XML
represents the future. Hence, "ebXML," rather than "ebEDI".

There is also agreement that ebXML-compliant systems will need to support
legacy EDI syntaxes, which is very much a reality, and a requirement that
has been taken to heart by the CC team.

So, I repeat: "Who is talking about 'throwing away' EDIFACT?"

Cheers,

Arofan Gregory

-----Original Message-----
From: Philip Goatly [mailto:philip.goatly@bolero.net]
Sent: Monday, April 02, 2001 1:03 AM
To: stuart.campbell@tieglobal.com; 'ebXML Core'
Subject: Re: xCBL and openness


Hi Stuart,

     If EDIFACT is 'thrown away' then one loses many man years of work and
expertise.

     One may argue about the way EDIFACT did some things, but many of the
principles are excellent.

      I feel that many people are reluctant to start with EDIFACT because
they are unfamiliar with EDIFACT - new kids on the block syndrome ;-) and
they would have to do a lot of homework.

      If one starts from scratch one will have to go through all the same
thinking that EDIFACT required, and any new technology may ease the pain of
implementation etc. but the business specification process may not be any
less painful.

     Cheers, Phil






----- Original Message -----
From: "Stuart Campbell" <stuart.campbell@tieglobal.com>
To: "'ebXML Core'" <ebxml-core@lists.ebxml.org>
Sent: Friday, March 30, 2001 6:43 PM
Subject: xCBL and openness


> (Response to Sue probert)
>
> Hi Sue
>
> I wonder if your xCBL comments are made about version 2.0 or version 3.0?
> ***Its true, really version 2.  Whilst is great there are more involved
and
> its on a non C1 specific website the bottom lines are:
> 'who makes the final decision on the changes to xCBL"
> If the answer is'C1/SAP' then this is a long way from being open
>
> and
> 'Is it reasonably (openly) possible for external companies to be part of
the
> team that decides the changes'.
> If the answer is no, then this is a long way from being open
>
> I think these points are the ones i would like answers to and would invite
> to be put on the exploder
>
> "offered this work to the ebXML follow-on group as a starting
> point if it proves to be of interest. Of course, this technical
information
> is already available openly but what both companies have also offered is
> some commitment to play a part in supporting the work i.e. to provide
links
> to the joint development team itself."
>
> xCBL should IMHO under no way be a 'starting point' - this should be
EDIFACT
> or start from zero.  XCBL, like other inputs, should be welcomed to
> influence the starting point; so if this is what C1 is saying then thats
> great as well
>
> Cheers
>
> STUART
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
>


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org