XML is sort of like Java was thought of 4 years ago - a cure-all
technology, But like Java it is not.
Mark Kusiak wrote:
>
> 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.
This epitomizes what a lot of people think of XML - a "pretty" way of
displaying data and that is about all its good for. While it is neat
that you can view XML in drill down trees in Microsoft (MS) Internet
Explorer (IE) and Windows 2000 has a built in XML parser which provides
excellent support for reading, writing, transmitting, and receiving XML,
this is just the tip of the iceburg...And who care about display of data
anyway when you are talking EDI.
> Where XML falls flat is in true business system integration between
> two separate or remote computer systems.
This is totally false. Data flies around the Internet all day and night
via HTTP. HTTP is not just for serving up HTML-based user interfaces.
It is used for Remote Procedure Calls (RPC) and is _platform
independent_. XML is the preferred "rail" that data and data objects
run on over HTTP. Even a non-HTTP protocol such as DCOM can use XML.
Yes, when we compare Trad-EDI(ANSI/EDIFACT) data files and XML data
files to each other there is no advantage of sending/receiving one over
the other. I'll admit that from a mapping point of view it is
meaningless to compare, for example, an ANSI 4010 850'S BEG segment vs.
the equivalent in XML because mapping from both is just as time
consuming and expensive:
ANSI example:
BEG*00*SA*0007058668**20000725
vs. the XML equivalent (which could be anything) example:
<BeginningSegmentForPurchaseOrder>
<TransactionSetPurposeCode>00</TransactionSetPurposeCode>
<PurchaseOrderTypeCode>SA</PurchaseOrderTypeCode>
<PurchaseOrderNumber>0007058668</PurchaseOrderNumber>
<PurchaseOrderDate>20000725</PurchaseOrderDate>
</BeginningSegmentForPurchaseOrder>
As a side bar why would we even do it this way in XML? It would be more
in conformance with client/server data to list the PO in XML as
<ROW>
<POHeader>
<TransactionSetPurposeCode>00</TransactionSetPurposeCode>
<PurchaseOrderTypeCode>SA</PurchaseOrderTypeCode>
<PurchaseOrderNumber>0007058668</PurchaseOrderNumber>
<PurchaseOrderDate>20000725</PurchaseOrderDate>
</POHeader>
<PODetail>
...
</PODetail>
</ROW>
But it is what you can do inside the XML file in conformance with its
protocol that gives it way more flexibility than sending Trad-EDI. For
example, I can use SOAP (Simple Object Access Protocol) embedded in an
HTTP request to provide a simple and lightweight mechanism for
exchanging structured and typed information between peers in a
decentralized, distributed environment using XML. In other words within
an XML document I can send my data request along with an RPC to get data
back. For example:
HTTP/1.1 200 OK
Content-Type: text/xml;
charset="utf-8"
Content-Length:
nnnn
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Body>
<m:GetOrderStatus xmlns:m="Some-URI">
<POHeader>
<PurchaseOrderNumber>0007058668</PurchaseOrderNumber>
</POHeader>
</m:GetOrderStatus>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
The response might be:
HTTP/1.1 200 OK
Content-Type: text/xml;
charset="utf-8"
Content-Length:
nnnn
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Body>
<m:GetOrderStatusResponse xmlns:m="Some-URI">
<POHeader>
<PurchaseOrderNumber>0007058668</PurchaseOrderNumber>
<Status>Shipped Complete</Status>
<DateShipped>20000727</DateShipped>
</POHeader>
</m:GetOrderStatusResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Point is, I just did EDI with XML.
The day will come (it's here) when you go to my website and tell my
system what XML you need back for your system. In other words you do
the mapping on my website to tell me what you need and what you are
sending me and how it matches with my published data sources.
And for those who poo-poo XML because of size issues consider this: in
the next year we will see same amount of aggregate data travel over the
Internet in one second as did in one month in 1997.
> 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.
This is totally false as well. This has been solved by SSL and 128 bit
encryption. AT&T's VAN is already doing it. But it does not have to be
a VAN. The same HTTP exchange I explained above can be done over HTTPS
without a VAN. Why do you care about someone else's purchase orders or
invoices anyway? - it's a red herring. Avoiding EDI over the Internet
because of security concerns is ridiculous.
--
Richard Druckenmiller
[EMAIL PROTECTED]
=======================================================================
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/
