Mark,
I like a lot of what you said in your post, but I disagree on two points:
1) XML may indeed facilitate communication between trading partners. This
will require XSL transformation of messages. Although the W3C standards
are settling down, we need solid implementations for this to become a
reality.
2) It is already possible to send secure EDI transactions over the net;
we've been doing it for three years. It will probably become a lot cheaper
to do so in the near future, as vendors roll out products that conform to
IETF's EDIINT AS2 specification.
Andy
---------------------------------------------------------------------------------------------------------------------
Mark Kusiak <[EMAIL PROTECTED]>@LISTSERV.UCOP.EDU> on 10/24/2000 11:45:35
AM
Please respond to Mark Kusiak <[EMAIL PROTECTED]>
Sent by: Electronic Data Interchange Issues <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject: Re: XML for EDI book: Any comments?
The real truth about the XML vs. EDI is that XML is sexy. It's the newest
thing to come down the pipe in a long while. As far as performing "rip and
read", it has merits and incentives for cost reduction that can be achieved
very quickly.
Most PC workstations today have XML enabled browsers or can be updated with
them very quickly at next to nothing in cost. That means that the XML data
file can be displayed on the browser and made available to the direct user
of the information without much intervention between the gateway and the
user. It has the potential of getting data to the person who needs it
rapidly. This is a real advantage of XML and should be exploited if that
is the goal.
Where XML falls flat is in true business system integration between two
separate or remote computer systems. The use of the new standards (I use
this term lightly as they are changing faster then you can shake a stick)
will require that an interface be either built for the XML centered
transactions or that the existing EDI interface programs be modified to
handle the data provided. The second branch will be the method by which
the implementation of XML happens.
EDI has always been envisioned as the enabling technology to allow
information from one computer in a company to be transmitted to another
company, translated, and loaded to that companies application. All EDI
affiliated professionals know that this is the true crux of costs in
accomplishing the "computer to computer integration of information". XML
has NOT solved this problem, unless it's cheaper to hire a clerk to sit,
gather, and plug in what he/she sees on the browser (I feel that this is a
huge step backwards).
Most XML pundits believe that EDI cannot be communicated over the NET.
Most managers believe the same thing. THIS IS FALSE. EDI data will go
just as fast as XML data. The problem which has not been solved by either
standard is that the data (invoicing and ordering) must be secure between
the two companies. Not just the firewall, but the transmitted file of data
moving across the nodes on the WEB. This means that a fast and reliable
encryption must be used to ensure that the data is not sniffed in the
middle. XML's promise of reduced communications costs are given at the
sacrifice of security. Communications via a VAN allow me to have an
organization which is reasonably secure from prying eyes. If it happens
that the data is compromised, I have someone that can pay for the damage in
that the VAN is accountable. Over the net, I don't, so therefore I must be
accountable. Again, I want to stress that XML nor EDI have solved this
problem. There are some heavy issues involved here. Not the least of
which is the federal government here in the states. Until one can encrypt
with impunity and the web can be rendered truly private, the reduction of
costs for communications provided by the net will not be without some real
compromises in privacy. Is this email moving via the web truly private?
No, but I don't really care if Joe Sniffmeout in Cincinnati reads this.
But, I'm not putting my credit card number in it either.
Bottom line is that most people feel that the cost of communicating between
trading partners is the single largest cost of EDI. It is true that the
cost is a variable and residual one that the controller or responsible
manager sees. But that cost will be replaced by the costs to track and
manage security encryption standards and the like. By going to XML,
security costs will become a hidden one. No one will be able to directly
determine them. It will not reduce the costs of doing e-commerce with
others, it will just hide them. I doubt seriously that XML will reduce
costs, it will more then likely raise them and e-commerce will still remain
as difficult to put in place as it was before XML ever came into such
popular appeal.
Mark
PS. This is my opinion only. I've been involved in EDI/e-commerce for
about ten years as a coordinator, analyst and implementation resource.
-----Original Message-----
From: Lee LoFrisco [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 24, 2000 6:09 AM
To: [EMAIL PROTECTED]
Subject: Re: XML for EDI book: Any comments?
I'm a bit confused about the benefits of XML. In a traditional
EDI-intensive shop, where the supply-chain, time-critical documents
are communicated electronically, and at a huge savings, where would XML
improve this process? Granted, when communicating between a web site and
desktop, XML has found a home. Entering a purchase order via a web-based
entry screen, applying edits, and submitting the info to an ERP system is
practical, cost-effective method of order processing for non-EDI orgs.
But,
at some point along the way from entry to placing the order, the XML file
needs to be translated to EDI (or some standard) before updating or else an
org would have to maintain an endless list of unique *maps* to accommodate
all the variations. Now, that sounds like EDI to me.
Without standards, which VP or Director is going to stake his or her career
on recommending changing from traditional EDI to XML? With millions of
dollars invested in effort and resources with EDI, and with the documents
flowing, why change? XML builds larger files and has yet to prove itself.
If it ain't broke, don't fix it!
Why all the hoopla about XML vs. EDI (unless of course it's from the XML
software developers themselves)?
Lee LoFrisco
Sterling Commerce Service Partner Consultant
VoiceMail: 614.210.2706
Cell Phone: 410.963.6218
eFax: 810.277.5002
-----Original Message-----
From: Electronic Data Interchange Issues
[mailto:[EMAIL PROTECTED]]On Behalf Of Glass, John K. III
Sent: Tuesday, October 24, 2000 7:16 AM
To: [EMAIL PROTECTED]
Subject: XML for EDI book: Any comments?
Hello group.
I was browsing through some books at amazon.com and noticed a book that's
supposed to be coming out in November called:
Xml for Edi : Making E-Commerce a Reality
by Hussain Chinoy, Tyna Hull, Robi Sen
I was wondering if anyone has preordered this book and if you have
heard any buzz about what it will contain. You guys don't know of any
other
books which dealt with this whole EDI/XML issue, do you? Anyway, any info
that you have about this book would be appreciated.
Thanks.
=======================================================================
To signoff the EDI-L list, mailto:[EMAIL PROTECTED]
To subscribe, mailto:[EMAIL PROTECTED]
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
_______________________________________________
Why pay for something you could get for free?
NetZero provides FREE Internet Access and Email
http://www.netzero.net/download/index.html
=======================================================================
To signoff the EDI-L list, mailto:[EMAIL PROTECTED]
To subscribe, mailto:[EMAIL PROTECTED]
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
=======================================================================
To signoff the EDI-L list, mailto:[EMAIL PROTECTED]
To subscribe, mailto:[EMAIL PROTECTED]
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
