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