Mark, et al,
My example wasn't at all intended to be an epistle on the advantages
of XML vx X12. From a pure efficiency perspective, we all know that
X12 wins.
All my example was trying to show was that stuffing the abstract X12
"stuff" into an XML document adds no value. You've just layed
complexity into another layer of complexity. Since XML is intended to
be human readable, all I was advocating was that rather than using the
abstract code value (which would require a reference to the underlying
X12 standard) just use the code definition of the specific code and
expose the semantic.
Like it or not, XML is an avalanche coming down the mountain. Rather
than trying to stop the avalanche, I think it would be more prudent to
learn to ride the wave! After all, our EDI clients will, hopefully,
ask us to help them with their XML strategy and implementation. I, for
one, intend to be ready to help my clients with both traditional EDI
and XML and whatever else comes down the pike....
Rachel
First let me apologize for taking this off thread, but
I read that someone
was looking for the advantages/disadvantages of XML,
internet, VAN, ect.. I think
that in the last 12 hours of exchanges, we've gotten
more on the subject then we could
get from most books.
Rachel,
I agree that the CODES in EDI & UN/EDIFACT are where
the semantics are at, but not everyone agrees with
which code to use to represent a piece of data. Case
in point, there are
probably no less then 5 codes in the PO to represent a
Vendor Part Number, a Buyer Part
number or a UPC code for that fact, in X-12.
This "interpretation" of the "code" is what requires
that high degree of coordination between
a trading partner. Heck, I have five codes in X-12
and we all speak the same language
supposedly. Every time the a new "code" with a
slightly different meaning comes into
existence, you will still be running back to your
interface to modify it to recognize
that new meaning as something it already knows about.
Yes, design it better such that they
can be feed to the process through a table or file,
but that's complex and takes time to build.
Most companies need it yesterday. Get a process in
place and if it changes we'll cross that
bridge when we come to it. This is the prevailing
idea in business today. Don't give me a
picture of what I'm in for up front less I balk at it,
but provide me with the ammo to blame
you if the cost or headache gets to be unbearable and
well run in a new person.
Bottom Line is that you do not avoiding costs
associated with these issues in XML either.
Now, I ask, what advantage do I have from XML other
then Microsoft's new Swiss army knife
can parse, process, and display it? That's not to say
that XML is bad, it does have it's
advantages. I'm just searching heavily for additional
skills and tools knowledge to add to my
bag that I can take to a client and use to solve
his/her problems, not just hype. I'm at the
position where if I go into the client and sell them
hype and it doesn't work, I'm sure I
won't be coming back :-).
Mark
-----Original Message-----
From: Rachel Foerster [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 25, 2000 9:29 AM
To: [EMAIL PROTECTED]
Subject: Re: XML for EDI book: Any comments?
In general terms I agree with Richard. However, I do
have a problem
(more like heartburn!) with his proposed XML version
of the X12 850
PO. Why on earth would you want to describe and convey
all of those
X12 codes. That's where the real semantic information
is. Thus, I
would suggest something like this would be more
appropriate:
<StandalonePurchaseOrder>
<PurchaseOrderNumber>0007058668</PurchaseOrderNumber>
<PurchaseOrderDate>20000725</PurchaseOrderDate>
<Shipto>Some ship to address with children
elements</Shipto>
<Item>
<ItemNumber>D1906</>
<Quantity>10</Quantity>
<UnitofMeasure>Case></UnitofMeasure>
<ContractPrice>$24.96</ContractPrice>
</Item>
<Item>
<ItemNumber>BF2152</>
<Quantity>3</Quantity>
<UnitofMeasure>Each></UnitofMeasure>
<ContractPrice>$4.96</ContractPrice>
</Item>
</StandalonePurchaseOrder>
It's the codes -- both in X12 and UN/EDIFACT -- where
all of the
semantic is buried. Forget about the code values, use
the code
definition!
Furthermore, the ebXML message services specification
-- which will be
approved at the Tokyo ebXML meeting the week of 11/6,
offers far more
fiunctionality and capability than SOAP....which isn't
even yet a W3C
Candidate Recommendation let alone an approved
Recommendation.
Rachel
----------------------------------------------------------------------
---------
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/
======================================================================
=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/
--3662957-4795-972503776=:1496
Content-Type: TEXT/html; CHARSET=US-ASCII
Content-ID: 0
Content-Language: en-USA
<html><head></head><body>
<font size=2 >First
let me apologize for taking this off thread, but I read that someone
</font><div>
<font size=2 >was
looking for the advantages/disadvantages of XML, internet, VAN, ect..
I
think</font><div>
<font size=2 >that
in the last 12 hours of exchanges, we've gotten more on the subject
then we
could </font><div>
<font size=2 >get
from most books.</font><div>
<font size=2 ></font><div>
<font size=2 >Rachel,
</font><div>
<font size=2 ></font><div>
<font size=2 >I
agree that the CODES in EDI & UN/EDIFACT are where the semantics
are at,
but not everyone agrees with </font><div>
<font size=2 >which
code to use to represent a piece of data. Case in point, there are
</font><div>
<font size=2 >probably
no less then 5 codes in the PO to represent a Vendor Part Number, a
Buyer Part
</font><div>
<font size=2 >number
or a UPC code for that fact, in X-12. </font><div>
<font size=2 ></font><div>
<font size=2 >This
"interpretation" of the "code" is what requires that high degree of
coordination between</font><div>
<font size=2 >a
trading partner. Heck, I have five codes in X-12 and we all speak the
same
language </font><div>
<font size=2 >supposedly.
Every time the a new "code" with a slightly different meaning comes
into
</font><div>
<font size=2 >existence,
you will still be running back to your interface to modify it to
recognize
</font><div>
<font size=2 >that
new meaning as something it already knows about. Yes, design it
better such
that they</font><div>
<font size=2 >can
be feed to the process through a table or file, but that's complex and
takes
time to build.</font><div>
<font size=2 >Most
companies need it yesterday. Get a process in place and if it changes
we'll
cross that</font><div>
<font size=2 >bridge
when we come to it. This is the prevailing idea in business today.
Don't give
me a </font><div>
<font size=2 >picture
of what I'm in for up front less I balk at it, but provide me with the
ammo to
blame </font><div>
<font size=2 >you
if the cost or headache gets to be unbearable and well run in a new
person.</font><div>
<font size=2 ></font><div>
<font size=2 >Bottom
Line is that you do not avoiding costs associated with these issues in
XML
either.</font><div>
<font size=2 >Now,
I ask, what advantage do I have from XML other then Microsoft's new
Swiss army
knife </font><div>
<font size=2 >can
parse, process, and display it? That's not to say that XML is bad, it
does
have it's </font><div>
<font size=2 >advantages.
I'm just searching heavily for additional skills and tools knowledge
to add to
my </font><div>
<font size=2 >bag
that I can take to a client and use to solve his/her problems, not
just hype.
I'm at the </font><div>
<font size=2 >position
where if I go into the client and sell them hype and it doesn't work,
I'm sure
I </font><div>
<font size=2 >won't
be coming back :-). </font><div>
<font size=2 ></font><div>
<font size=2 >Mark</font><div>
<font size=2 ></font><div>
<font size=2 >-----Original
Message-----</font><div>
<font size=2 >From:
Rachel Foerster [mailto:[EMAIL PROTECTED]]</font><div>
<font size=2 >Sent:
Wednesday, October 25, 2000 9:29 AM</font><div>
<font size=2 >To:
[EMAIL PROTECTED]</font><div>
<font size=2 >Subject:
Re: XML for EDI book: Any comments?</font><div>
<font size=2 ></font><div>
<font size=2 ></font><div>
<font size=2 >In
general terms I agree with Richard. However, I do have a
problem</font><div>
<font size=2 >(more
like heartburn!) with his proposed XML version of the X12
850</font><div>
<font size=2 >PO.
Why on earth would you want to describe and convey all of
those</font><div>
<font size=2 >X12
codes. That's where the real semantic information is. Thus,
I</font><div>
<font size=2 >would
suggest something like this would be more appropriate:</font><div>
<font size=2 ></font><div>
<font size=2 ><StandalonePurchaseOrder></font><div>
<font size=2 >
<PurchaseOrderNumber>0007058668</PurchaseOrderNumber></fon
t><div>
<font size=2 >
<PurchaseOrderDate>20000725</PurchaseOrderDate></font><div
>
<font size=2 >
<Shipto>Some ship to address with children
elements</Shipto></font><div>
<font size=2 >
<Item></font><div>
<font size=2 >
<ItemNumber>D1906</></font><div>
<font size=2 >
<Quantity>10</Quantity></font><div>
<font size=2 >
<UnitofMeasure>Case></UnitofMeasure></font><div>
<font size=2 >
<ContractPrice>$24.96</ContractPrice></font><div>
<font size=2 >
</Item></font><div>
<font size=2 >
<Item></font><div>
<font size=2 >
<ItemNumber>BF2152</></font><div>
<font size=2 >
<Quantity>3</Quantity></font><div>
<font size=2 >
<UnitofMeasure>Each></UnitofMeasure></font><div>
<font size=2 >
<ContractPrice>$4.96</ContractPrice></font><div>
<font size=2 >
</Item></font><div>
<font size=2 ></StandalonePurchaseOrder></font><div>
<font size=2 ></font><div>
<font size=2 >It's
the codes -- both in X12 and UN/EDIFACT -- where all of
the</font><div>
<font size=2 >semantic
is buried. Forget about the code values, use the code</font><div>
<font size=2 >definition!</font><div>
<font size=2 ></font><div>
<font size=2 >Furthermore,
the ebXML message services specification -- which will be</font><div>
<font size=2 >approved
at the Tokyo ebXML meeting the week of 11/6, offers far
more</font><div>
<font size=2 >fiunctionality
and capability than SOAP....which isn't even yet a W3C</font><div>
<font size=2 >Candidate
Recommendation let alone an approved Recommendation.</font><div>
<font size=2 ></font><div>
<font size=2 >Rachel</font><div>
<font size=2
>---------------------------------------------------------------------
-</font><div>
<font size=2 >---------</font><div>
<font size=2 ></font><div>
<font size=2 >XML
is sort of like Java was thought of 4 years ago - a
cure-all</font><div>
<font size=2 >technology,
But like Java it is not.</font><div>
<font size=2 ></font><div>
<font size=2 >Mark
Kusiak wrote:</font><div>
<font size=2 >></font><div>
<font size=2 >>
The real truth about the XML vs. EDI is that XML is sexy. It's
the</font><div>
<font size=2 >>
newest thing to come down the pipe in a long while. As far
as</font><div>
<font size=2 >>
performing "rip and read", it has merits and incentives for
cost</font><div>
<font size=2 >>
reduction that can be achieved very quickly.</font><div>
<font size=2 >>
Most PC workstations today have XML enabled browsers or can
be</font><div>
<font size=2 >updated</font><div>
<font size=2 >>
with them very quickly at next to nothing in cost. That means
that</font><div>
<font size=2 >the</font><div>
<font size=2 >>
XML data file can be displayed on the browser and made available
to</font><div>
<font size=2 >>
the direct user of the information without much intervention
between</font><div>
<font size=2 >>
the gateway and the user. It has the potential of getting data
to</font><div>
<font size=2 >the</font><div>
<font size=2 >>
person who needs it rapidly. This is a real advantage of XML
and</font><div>
<font size=2 >>
should be exploited if that is the goal.</font><div>
<font size=2 ></font><div>
<font size=2 >This
epitomizes what a lot of people think of XML - a "pretty" way
of</font><div>
<font size=2 >displaying
data and that is about all its good for. While it is neat</font><div>
<font size=2 >that
you can view XML in drill down trees in Microsoft (MS)
Internet</font><div>
<font size=2 >Explorer
(IE) and Windows 2000 has a built in XML parser which</font><div>
<font size=2 >provides</font><div>
<font size=2 >excellent
support for reading, writing, transmitting, and receiving</font><div>
<font size=2 >XML,</font><div>
<font size=2 >this
is just the tip of the iceburg...And who care about display
of</font><div>
<font size=2 >data</font><div>
<font size=2 >anyway
when you are talking EDI.</font><div>
<font size=2 ></font><div>
<font size=2 ></font><div>
<font size=2 >>
Where XML falls flat is in true business system integration
between</font><div>
<font size=2 >>
two separate or remote computer systems.</font><div>
<font size=2 ></font><div>
<font size=2 >This
is totally false. Data flies around the Internet all day
and</font><div>
<font size=2 >night</font><div>
<font size=2 >via
HTTP. HTTP is not just for serving up HTML-based user
interfaces.</font><div>
<font size=2 >It
is used for Remote Procedure Calls (RPC) and is _platform</font><div>
<font size=2 >independent_.
XML is the preferred "rail" that data and data objects</font><div>
<font size=2 >run
on over HTTP. Even a non-HTTP protocol such as DCOM can use
XML.</font><div>
<font size=2 ></font><div>
<font size=2 >Yes,
when we compare Trad-EDI(ANSI/EDIFACT) data files and XML
data</font><div>
<font size=2 >files
to each other there is no advantage of sending/receiving
one</font><div>
<font size=2 >over</font><div>
<font size=2 >the
other. I'll admit that from a mapping point of view it is</font><div>
<font size=2 >meaningless
to compare, for example, an ANSI 4010 850'S BEG segment</font><div>
<font size=2 >vs.</font><div>
<font size=2 >the
equivalent in XML because mapping from both is just as
time</font><div>
<font size=2 >consuming
and expensive:</font><div>
<font size=2 >ANSI
example:</font><div>
<font size=2 >BEG*00*SA*0007058668**20000725</font><div>
<font size=2 >vs.
the XML equivalent (which could be anything) example:</font><div>
<font size=2 ><BeginningSegmentForPurchaseOrder></font><div>
<font size=2 >
<TransactionSetPurposeCode>00</TransactionSetPurposeCode><
/font><div
<font size=2 >
<PurchaseOrderTypeCode>SA</PurchaseOrderTypeCode></font><d
iv>
<font size=2 >
<PurchaseOrderNumber>0007058668</PurchaseOrderNumber></fon
t><div>
<font size=2 >
<PurchaseOrderDate>20000725</PurchaseOrderDate></font><div
>
<font size=2 ></BeginningSegmentForPurchaseOrder></font><div>
<font size=2 >As
a side bar why would we even do it this way in XML? It would
be</font><div>
<font size=2 >more</font><div>
<font size=2 >in
conformance with client/server data to list the PO in XML
as</font><div>
<font size=2 ><ROW></font><div>
<font size=2 >
<POHeader></font><div>
<font size=2 ></font><div>
<font size=2
><TransactionSetPurposeCode>00</TransactionSetPurposeCode>
</font><div>
<font size=2 >
<PurchaseOrderTypeCode>SA</PurchaseOrderTypeCode></font><d
iv>
<font size=2 >
<PurchaseOrderNumber>0007058668</PurchaseOrderNumber></fon
t><div>
<font size=2 >
<PurchaseOrderDate>20000725</PurchaseOrderDate></font><div
>
<font size=2 >
</POHeader></font><div>
<font size=2 >
<PODetail></font><div>
<font size=2 >
...</font><div>
<font size=2 >
</PODetail></font><div>
<font size=2 ></ROW></font><div>
<font size=2 ></font><div>
<font size=2 >But
it is what you can do inside the XML file in conformance with
its</font><div>
<font size=2 >protocol
that gives it way more flexibility than sending Trad-EDI.</font><div>
<font size=2 >For</font><div>
<font size=2 >example,
I can use SOAP (Simple Object Access Protocol) embedded
in</font><div>
<font size=2 >an</font><div>
<font size=2 >HTTP
request to provide a simple and lightweight mechanism for</font><div>
<font size=2 >exchanging
structured and typed information between peers in a</font><div>
<font size=2 >decentralized,
distributed environment using XML. In other words</font><div>
<font size=2 >within</font><div>
<font size=2 >an
XML document I can send my data request along with an RPC to
get</font><div>
<font size=2 >data</font><div>
<font size=2 >back.
For example:</font><div>
<font size=2 ></font><div>
<font size=2 >HTTP/1.1
200 OK</font><div>
<font size=2 >Content-Type:
text/xml;</font><div>
<font size=2 >charset="utf-8"</font><div>
<font size=2 >Content-Length:</font><div>
<font size=2 >nnnn</font><div>
<font size=2 ></font><div>
<font size=2 ><SOAP-ENV:Envelope</font><div>
<font size=2 >
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"</font><div>
<font size=2 >
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
;</font><dv>
<font size=2 >
<SOAP-ENV:Body></font><div>
<font size=2 >
<m:GetOrderStatus xmlns:m="Some-URI"></font><div>
<font size=2 >
<POHeader></font><div>
<font size=2 >
<PurchaseOrderNumber>0007058668</PurchaseOrderNumber></fon
t><div>
<font size=2 >
</POHeader></font><div>
<font size=2 >
</m:GetOrderStatus></font><div>
<font size=2 >
</SOAP-ENV:Body></font><div>
<font size=2 ></SOAP-ENV:Envelope></font><div>
<font size=2 ></font><div>
<font size=2 >The
response might be:</font><div>
<font size=2 ></font><div>
<font size=2 >HTTP/1.1
200 OK</font><div>
<font size=2 >Content-Type:
text/xml;</font><div>
<font size=2 >charset="utf-8"</font><div>
<font size=2 >Content-Length:</font><div>
<font size=2 >nnnn</font><div>
<font size=2 ></font><div>
<font size=2 ><SOAP-ENV:Envelope</font><div>
<font size=2 >
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"</font><div>
<font size=2 >
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
;</font><dv>
<font size=2 >
<SOAP-ENV:Body></font><div>
<font size=2 >
<m:GetOrderStatusResponse xmlns:m="Some-URI"></font><div>
<font size=2 >
<POHeader></font><div>
<font size=2 >
<PurchaseOrderNumber>0007058668</PurchaseOrderNumber></fon
t><div>
<font size=2 >
<Status>Shipped
Complete</Status></font><div>
<font size=2 >
<DateShipped>20000727</DateShipped></font><div>
<font size=2 >
</POHeader></font><div>
<font size=2 >
</m:GetOrderStatusResponse></font><div>
<font size=2 >
</SOAP-ENV:Body></font><div>
<font size=2 ></SOAP-ENV:Envelope></font><div>
<font size=2 ></font><div>
<font size=2 >Point
is, I just did EDI with XML.</font><div>
<font size=2 ></font><div>
<font size=2 >The
day will come (it's here) when you go to my website and tell
my</font><div>
<font size=2 >system
what XML you need back for your system. In other words you
do</font><div>
<font size=2 >the
mapping on my website to tell me what you need and what you
are</font><div>
<font size=2 >sending
me and how it matches with my published data sources.</font><div>
<font size=2 ></font><div>
<font size=2 >And
for those who poo-poo XML because of size issues consider this:
in</font><div>
<font size=2 >the
next year we will see same amount of aggregate data travel
over</font><div>
<font size=2 >the</font><div>
<font size=2 >Internet
in one second as did in one month in 1997.</font><div>
<font size=2 ></font><div>
<font size=2 >>
The use of the new standards</font><div>
<font size=2 >>
(I use this term lightly as they are changing faster then you
can</font><div>
<font size=2 >>
shake a stick) will require that an interface be either built
for</font><div>
<font size=2 >the</font><div>
<font size=2 >>
XML centered transactions or that the existing EDI
interface</font><div>
<font size=2 >programs</font><div>
<font size=2 >>
be modified to handle the data provided. The second branch will
be</font><div>
<font size=2 >the</font><div>
<font size=2 >>
method by which the implementation of XML happens.</font><div>
<font size=2 >>
EDI has always been envisioned as the enabling technology to
allow</font><div>
<font size=2 >>
information from one computer in a company to be transmitted
to</font><div>
<font size=2 >>
another company, translated, and loaded to that companies</font><div>
<font size=2 >application.</font><div>
<font size=2 >>
All EDI affiliated professionals know that this is the true crux
of</font><div>
<font size=2 >>
costs in accomplishing the "computer to computer integration
of</font><div>
<font size=2 >>
information". XML has NOT solved this problem, unless it's
cheaper</font><div>
<font size=2 >to</font><div>
<font size=2 >>
hire a clerk to sit, gather, and plug in what he/she sees on
the</font><div>
<font size=2 >>
browser (I feel that this is a huge step backwards).</font><div>
<font size=2 >>
Most XML pundits believe that EDI cannot be communicated over
the</font><div>
<font size=2 >NET.</font><div>
<font size=2 >>
Most managers believe the same thing. THIS IS FALSE. EDI data
will</font><div>
<font size=2 >go</font><div>
<font size=2 >>
just as fast as XML data. The problem which has not been solved
by</font><div>
<font size=2 >>
either standard is that the data (invoicing and ordering) must
be</font><div>
<font size=2 >>
secure between the two companies. Not just the firewall, but
the</font><div>
<font size=2 >>
transmitted file of data moving across the nodes on the WEB.
This</font><div>
<font size=2 >>
means that a fast and reliable encryption must be used to
ensure</font><div>
<font size=2 >that</font><div>
<font size=2 >>
the data is not sniffed in the middle. XML's promise of
reduced</font><div>
<font size=2 >>
communications costs are given at the sacrifice of
security.</font><div>
<font size=2 ></font><div>
<font size=2 >This
is totally false as well. This has been solved by SSL and
128</font><div>
<font size=2 >bit</font><div>
<font size=2 >encryption.
AT&T's VAN is already doing it. But it does not have
to</font><div>
<font size=2 >be</font><div>
<font size=2 >a
VAN. The same HTTP exchange I explained above can be done
over</font><div>
<font size=2 >HTTPS</font><div>
<font size=2 >without
a VAN. Why do you care about someone else's purchase
orders</font><div>
<font size=2 >or</font><div>
<font size=2 >invoices
anyway? - it's a red herring. Avoiding EDI over the
Internet</font><div>
<font size=2 >because
of security concerns is ridiculous.</font><div>
<font size=2 ></font><div>
<font size=2 >--</font><div>
<font size=2 >Richard
Druckenmiller</font><div>
<font size=2 >[EMAIL PROTECTED]</font><div>
<font size=2 ></font><div>
<font size=2
>=====================================================================
=</font><div>
<font size=2 >=</font><div>
<font size=2 >To
signoff the EDI-L list,
mailto:[EMAIL PROTECTED]</font><div>
<font size=2 >To
subscribe,</font><div>
<font size=2 >mailto:[EMAIL PROTECTED]</font><div>
<font size=2 >To
contact the list owner: mailto:[EMAIL PROTECTED]</font><div>
<font size=2 >Archives
at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/</font><div>
<font size=2 ></font><div>
<font size=2
>=====================================================================
==</font><div>
<font size=2 >To
signoff the EDI-L list,
mailto:[EMAIL PROTECTED]</font><div>
<font size=2 >To
subscribe,
mailto:[EMAIL PROTECTED]</font><div>
<font size=2 >To
contact the list owner: mailto:[EMAIL PROTECTED]</font><div>
<font size=2 >Archives
at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/</font><div>
<font ></font></body></html>
--3662957-4795-972503776=:1496--
======================================================================
=
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/
