RE: Brave new world

["COOPER,STEPHENIE (HP-PaloAlto,ex1)" <stephenie_cooper@hp.com>]

Hi.

Let's be sure we don't confuse EDI with the two primary standards, X12 and
EDIFACT.  XML can do things that are not currently possible with X12 and
EDIFACT.  The reality, however, is the most of the partners I'm dealing with
right now are merely using XML as another EDI standard (EDI = the
computer-to-computer exchange of business data in a standard format).  In
the RosettaNet eConcert dances, the most popular choice has been PIP3A4, the
discrete Purchase Order and Acknowledgment.

And yes, yes, yes, having done many, many, many implementations, using
business models developed by my industry consortium, EIDX (www.eidx.org),
the biggest cost is ALWAYS the back-end integration, and that cost applies
whether you are using X12, EDIFACT or XML.  The applications tend to support
the same old core functionality out-of-the-box (discrete purchase order,
simple forecast, simple invoice) The sending application has to be able to
generate the business data, you have to be able to get it out of the system
and to a partner, and the receiving application has to be able to read and
process the data.  

The other big myth about X12 and EDIFACT is that the VAN costs are what
cause "EDI" to be so expensive.  So, what did we all have to do for XML (and
for X12 or EDIFACT over the internet)?  Reproduce all those things that the
VANs do, like resolve protocol incompatibilities, security, routing, etc.,
etc., etc.  So what's happening in the marketplace today?  Startup companies
are starting to emerge who provide such services for internet commerce.  But
instead of per message and kilobyte charges, they come up with other pricing
structures so that they won't look like VANs.  They are VANs nevertheless.
By the way, there are a couple of them who use the good old VAN-like pricing
structure for handling internet transactions.  This means that the
difference between a 3 byte tag and a 35 byte tag is going to matter.  

Here's more of my story.  I've been around long enough to remember when file
size did not matter, because a few KB was all the space you'd ever need for
computing.  One small HP3000 was all we needed to run a division.  Then one
day, we found we had to start squeezing more information into fewer bytes.
Then computers got bigger.  And we needed more of them.  My first laptop had
a 500KB hard drive.  Two years later, my 2MG hard drive was going to be
large enough to handle everything for the next few years.  In less than 1
year, my PC support folks told me that 2MG was way, way too small and I
should upgrade to 6MG (the only reason I've got less that 6MG on my hard
drive right now is because I keep most stuff on one of several thousand
network drives in the company).

Size matters, and I personall believe it should be taken into consideration
when developing the core components.

Regards.

-----Original Message-----
From: Arofan Gregory [mailto:arofan.gregory@commerceone.com]
Sent: Wednesday, July 12, 2000 9:38 AM
To: 'Margaret Pemberton'; ebXML Core
Subject: RE: Brave new world


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