I'm not exactly sure how you inturpreted my comment... (I agree on how
"Stand" XML is... was that not clear?). Anyway, you want to know what I've
worked on. So here you go:
1.) An XML standard for purchase order transactions. This is relevant to
your discussion on XSLT. Your right, translation will increase
exponentially if companies tend to use multiple standards. However, how
likely is it that a majority of companies will choose to use their own
standard? If you do business with one million companies and you have one
thoudand translations, is it really such a hangup? No, because tranlations
aren't that difficult to create. So, while there will be a number of
translations, that number is not likely to be significantly large. However,
if everyone you intend to ever do business with is using EDI then so should
you. But, how likely is that?
2.) An online exam system for Washington University. This is a project that
showcase just how flexible XML can be. I use XML to store exams and XSLT to
translate to HTML, PDF, and charts/graphs. The flexibility to translate XML
documents in the manner done by this system outweighs the cost of
translations in my mind (but, agian, it depends on the variety of business
partners you intend to deal with).
3.) Currently working with XML to develope a hybrid web directory. The
exponential number of translations problem will be tested here. In
addition, XML will be utilized for configuration management and storage of
statistical data for internal and external publication.
4.) A programming language independant representation for code (i.e code can
be easily translated to C++, C, Java, Python, etc).
So, hope that fulfills your curiousity. Now, as for "International Usage,"
you do realize that XML is easilty translated to other languages, right? In
other words, a Japanese company can easily understand a standard developed
in the United States. I'm not seeing the difficulties here... Besides, most
foriegn techies speak english (I work with them daily at Wash U).
Brian
-----Original Message-----
From: Steve Bollinger [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 31, 2000 5:58 PM
To: XML EDI Listserv (E-mail)
Subject: Is the Internet/XML Going to Kill EDI?
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
------ 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
