RE: Brave new world

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

Dear Margaret Pemberton:

I think that you need to learn more about XML to understand it's application
in promoting the kind of increased interoperability that has plagued the EDI
world.

Because XML is capable of encoding object-relationships, it can allow for
variation-tolerant applications within messages that are related by being
subclasses of a single parent (or set of single parents, as this functions
at the level of any component of a document, as well as at the level of the
document as a whole). This is radically different than EDI - Commerce One,
my employer, has built technology based on this kind of cutting-edge XML
technology.

If you are interested in learning about the extension and polymorphic
capabilities of schema-based XML, then you might want to go to: www.xCBL.org
and do the "SOX Tutorial". This will take a few hours (2-3) but will
definitely help you understand the way in which ebXML is not "just another
standard" - we anticipate that xCBL will become an instantiation of ebXML
core components, and leverage exactly these features of XML Schema to
promote interoperability that is simply impossible with flat files.

This in no way removes the need to promote standardization, but it does make
that very significant problem somewhat less daunting. The tools we have to
enable back offices to communicate around a core set of standard semantics
are simply getting better.

Cheers,

Arofan Gregory

-----Original Message-----
From: Margaret Pemberton [mailto:diskray@w150.aone.net.au]
Sent: Wednesday, July 12, 2000 5:44 AM
To: ebXML Core
Subject: Re: Brave new world


Lisa

To date I have been an avid reader, if not participant, in the ebXML list
servers. However, your response below has made me speak what I have been
thinking ever since the XML hype has started.

You state:

> This is where XML comes in.  XML has the technology and application
vendors
> attention.
>
> As for the really tough problems, semantically consistent, stable, and
> concise messages, guidance for application vendors, consistent enveloping,
> etc.  This is where ebXML comes in.  The context work being done in Core
> Components will yield a solid technical approach to this difficult
> problem.  In addition, when combined with process models, represents a
> blueprint to application vendors for interaction with external systems.
>

From what I am reading (in both the list servers and documents), I really
cannot see how ebXML can solve any of the problems that EDI had. The
semantics of the data being sent are the minor problem of any sender (or
receiver) - the real problem is in the back end application being able to
understand, process and correctly (i.e. as the sender requires) reply to the
data received. In the real world, most senders and receivers are using
different applications, requiring and providing different pieces of data to
complete the required business process  - until everyone uses the exact same
process model, I cannot see how these problems can be resolved by "YET
ANOTHER STANDARD".

As an EDI consultant, I have always found that the technology of sending and
receiving message (whether they be UN/EDIFACT, X12, proprietary or even XML)
has been the easy part - getting the business data suitable for both ends of
the relationship has always taken the larger part of any implementation!! As
an example, what if the receiving application requires their own product
codes, delivery locations, whilst the sender has no way of converting these
from their codes. Or worse, the sender produces invoices of what has been
despatched at that time, while the receiver can only handle an invoice that
contains details for a single purchase order.

I will be the first to admit I am no XML expert - but to date, no one has
been able to explain to me how XML (or ebXML) will solve these business
issues, which are the real stopper for a SME that has a back end application
(either in-house or package). Many that I have talked to as to why they want
to use XML rather that "traditional-EDI" have stated that it is because of
the lower costs of parsers (aka translators?) - but I am yet to be convinced
that this is the 'real' cost of EDI - in my experience it has been the cost
of implementing the messages into the back end application systems.

Despite all of the above, I am keeping an open mind, and would like to hear
comments to the contrary!

Margaret Pemberton