Q Is the Internet/XML Going to Kill EDI?
A. only in a perfect world
Brian Curtis wrote: Unless someone can give valid reason for why a company should
choose EDI over XML....
Yes, Brian, I can give you some valid reasons. I would additionally like to comment
on your response to Kurt "there is a standard for data type definition (i.e DTD)".
Perhaps I mis-read your intent here, but I hear from many quarters how "Standard" XML
is. Yes, we have XML 1.0 which is a good standard at the language level. Far more
important however, is standards at the semantic level. There is an old computer
saying about standards: "The great thing about computer standards is that there are
so many to choose from!" ;) This is terribly true right now in XML as it relates to
the semantic level. RosettaNet which seems to be the farthest along right now (and
has been at it for several years) currently has at last report only a handful of
trading partnerships now up and running now in actual production mode using RosettaNet
standards.
Saying XML is "standard" because we have XML 1.0 is like saying all Java applications
written in Java 1.3 are standard and compatible to each other. Quite true at the
language level, not at all necessarily true (or likely) at the application level
unless they were intentionally built to interact with each other and be compatible.
Get the difference?
I suspect that there are differing views here because of differing backgrounds.
Brian, you told us you have done several XML jobs successfully and from what you have
told us you have done a good job. Fair enough. Some of us long time EDI folk such as
John Sanders, Rachel and myself come from a background of handling many different
trading partners on the same transaction types. We would like to believe in a perfect
world where everyone conforms to the same standard (long time EDI hype) but too many
years dealing with so many trading partners has disabused us of this idea. It just
isn't the real world. We know that in the real world "Trading Partnerships differ" on
the same transaction type (PO, Invoice, etc.). Some require additional data and
processing that others don't.
John Sanders wrote: "I sat on various committees in the mid 80s and gamely pronounced
that UN/EDIFACT was going to offer true standardization. I believed it, I soon woke
up"
We have lived too many years with the EDI perfect world hype but saw the actual
reality of it. We also see that XML does not solve this problem, and some of the "XML
solves it all" statements are really just the same EDI hype in new clothes. This is
the downside to EDI whether in X12 or EDIFACT or XML and I believe the problem to be
actually a little worse in XML. Read on.
Brian, I would like to ask, are your projects with multiple trading partners or single
partner? What is the transaction(s) you are sending? Let's assume that your projects
are running smoothly. Now you add more trading partners. Some accept your DTD,
while others are already trading with others using a different DTD (differing tags and
structure) for this same transaction type. They won't change their DTD because it is
already establishing in a production environment. You won't changes yours for the
same reason. Now, you now need to do some mapping (XSLT) between these. As your
number of differing trading partnerships increases, your maintenance on XSLT
transformations goes up exponentially.
If you have an ideal situation where you are the hub (you designed the DTD) and all
your partners conform to only to that, then the above issue won't be a problem for
you. But as you venture into a larger range of partnerships and transactions that
picture will change. Is it perhaps this different background that gives us a
differing view? I think perhaps, yes.
All of this maintenance costs the business. This is why EDI is so costly and why I
believe XML will be even a bit more costly.
several Reasons EDI can be preferred over XML:
1. Field naming: XML is stated to have the advantage here because you can say
<OrderQuantity> instead of the mundane X12's PO102. This may be a big plus where XML
is used in conjunction with the web and HTML, etc. But in fact that is part of XML's
downside when we are discussing XML/EDI. The programmer can always count on the order
quantity being in the PO102 regardless of differing partnership requirements when
working in X12. In XML it could be: <OrderQuantity>, <OrderQty>, <Quantity>,
<OrdQty>, <LineItemQuantity>, ad infinitum. At least in X12 all the main fields
(PO#=BEG03, PODate=BEG05, UOM=PO103, Unit Price=PO104, etc.) are always the same field
name. No need for different coding there. In XML EVERY field can be named
differently. This means big mapping differences for every trading partner with a
different DTD. Compare to X12 with a few different periphery fields have to be
accomdated but all the main ones are the same. X12/EDIFACT gets a big plus over XML !
here
.
Supporting this, John Sanders wrote: "all of the XML implementations that I have seen
to date offer the supplier an even more confusing situation. He has to learn new
methods, new operations, new formats etc etc for each of his buyers. Back to paper
but worse ! At least in the traditional EDI world he could have a front end that
dealt with the variations on a theme - with XML he is invariably told to "log into my
site - it's XML based so its standard" then he finds the reality."
2. Internationalism. XML is supposed to score big here. But the reality in using XML
for EDI, is that it is going to be easier for a non-english speaking programer to deal
with things like remembering that PO102 is quantity, than a number of differing
English representations as in the examples above. There are even bigger issues with
XML between differing languages than there is in X12 or EDIFACT. Here the
NON-descriptiveness of the field name has its advantages over descriptiveness.
I realize I have just been talking about problems with both EDI and XML. The solution
I have to admit is a bit beyond my scope or ability to solve. The closest solution I
have heard on this list is Rachel's article of July 6th on the thread: RE: The REAL
problem: The Trading Partnership (is there any benefit?).
see: http://www.mail-archive.com/[email protected]/msg00260.html
If we really can pull off standardized "business processes" and get ERPs, DRPs etc. to
comply, then we can finally get beyond the X12/EDIFACT vs. XML discussion which
doesn't fix the real problems in exchanging business transactions electronically,
anyway. The new XML hype is mostly (not all) a fancy and shiny extension to the old
EDI hype we have endured for years.
I realize I am in the minority here when I say: Depending on the application I
honestly believe that many new trading partners are better off with EDI, as painful as
that may sound.
Steve
Steve Bollinger 408-853-8478
Cisco Systems B2B Service Logistics Pjt
------ XML/edi Group Discussion List ------
Homepage = http://www.XMLedi-Group.org
Unsubscribe = send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank
Questions/requests: [EMAIL PROTECTED]
To receive only one message per day (digest format)
send the following message to [EMAIL PROTECTED],
(leave the subject line blank)
digest xmledi-group your-email-address
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
