Re: Brave new world

[Margaret Pemberton <diskray@w150.aone.net.au>]

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