Steve,
Excellent response. As for Rosetta Net possibly solving the problem of
trading partner diversity and making it plug and play, see the
ComputerWorld article
B-to-B XML Harder Than Anticipated
http://www.computerworld.com/cwi/story/0,1199,NAV47_STO44885,00.html
Doug Fangmeier
Consulting Manager
B2B Solutions
Charter Solutions, Inc.
-----Original Message-----
From: Steve Bollinger [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 05, 2000 3:10 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: The REAL problem: The Trading Partnership (is there any
benefit?)
Hear, hear! very well said Rachel! You hit the nail on the head!
Regardless of EDI or XML the content must still be programmed and
integrated.
The real problem with Richard's statement was not what he said about
XSL. The real problem in the generality: "it is far easier using a
common language XSL" is the "far easier" part of the phrase. It still
must be programmed by a programming staff and that takes work whether in
EDI or XML.
Yes XML is about content, but the X in XML (extensibility) means you can
have so many variations (just like EDI). Each variation must be
programmed to integrate this into the ERP/CRM, etc. That takes
resources. Resources leaves out the little players. This is the major
problem in EDI also.
This brings us to the REAL problem of EDI. It has nothing to do with
the EDI format vs. XML format. It is the fact that there is such
diversity in format definition among EDI Trading Partnerships. XML does
nothing to change this fact. Where XML may be helpful (remains to be
seen) is if some infrastructure can be built that will allow very small
"rip & tear EDI" type partners to use their browser with no other cost
involved. This could definitely be a benefit of XML over EDI. Speed of
XML may also be a plus (again remains unproven to me).
However for those partners automating the messages into/out of their ERP
or other system the benefits/disadvantages of EDI vs. XML are far less
clear and more nebulous. Generalities of "far easier" and "much better"
are just so much hype. I take a "Show me" "Prove it" attitude.
Lest someone think I am part of some EDI conspiracy (as was suggested
recently in this thread), I have done EDI for 12 years for about a
dozen different clients, some large: Cisco, Sun, Qualcomm. I am now on
a Java/XML project to replace some EDI. I very much dislike the
problems of EDI and would love to scrap the whole thing with the next
generation of XML or whatever that would solve the problems of EDI.
Believe me I have no prejudice in favor of EDI nor desire to keep doing
EDI !!! What I do wish to see however is REAL benefits, not just hype.
I am not married to any technology and want what really works. I would
love to see us evolve to the next generation of exchanging business
transactions.
Here is the REAL problem for both EDI & XML as I see it: There is much
variation in Trading Partnerships requiring differing formats. Here at
Cisco we had 17 variations on the X12 214 all programmed. We have
trimmed this number down some but still have variations. If a big
company like Cisco has these differences, imagine what it is like in the
smaller trading partner!
It works like this. General rule: Customers define the formats for
vendors. Someone in the partnership must do this. It is often the
customer. Sometimes it is the large company over the small company
becoming the "hub". Yes, X12 and EDIFACT have "standards" of
transaction sets, but there are many optional element and ways of
implementing them. There needs to be an agreement as to the meaning and
use of some of these "optional" features that end up being required of
the trading partnership.
Example: Say a large company like Cisco tells all it's vendor trading
partners "here is our published standard for the PO we will send you.
To do EDI business with us you must follow this". Many vendors accept
this and trading begins. Information flows are speeded-up and this is
good.
Now some of these smaller vendors also supply parts to HP and Sun. HP
and Sun have their own PO formats and hand these out to their vendors.
Now the little partner is burdened with maintaining three different
formats. This takes programming resources not just to program but also
to maintain. This is costly regardless of whether it is programmed in
C, Java, COBOL, XSL, XSLT, whatever. It doesn't matter. It is not the
format that is the problem. It is the differing types of information
which companies decide to exchange. THAT is the problem. Get it?
I hear too much argument of technologies, whereas the far bigger problem
is the nature of the beast: TRADING PARTNERSHIP ARE DIFFERENT. XML
does nothing to solve this!
RosettaNet is working on this in defining set standards that all will
use. They seem to be the farthest along in doing this in XML. Whether
they can really pull this off or not remains to be seen, but I certainly
applaud their efforts in this regard. Their intention is to have the
formats so standard that adding new partnerships will be plug and play.
Partly they do this by defining more mandandory fields and less
optional. The problem with this is that in those mandandory fields that
you have no reasonable data to supply, then zeros in numeric fields and
"XXXXXX" or other hard coded values go into these fields. This renders
them optional anyway in practice.
REASON: I believe the reason for such diversity in partnership comes
from doing business in a free market where there is much competition.
To get the competitive advantage, addition data is required by this
company but not by that company.
I don't profess to know the answers here. I do know that to REALLY make
XML the next generation over EDI we have to get a bit smarter in our
arguments about how to really make business transactions become
plug-n-play. I don't see this happening by arguing the benefits of
XSLT. I am hopeful that XML/XSLT will help us. However, I think the
REAL issue we need to argue is the way in which to re-engineer the type
of information that businesses exchange. It is only through
standardizing THAT, that we will leap into the next generation.
Anyhow, what I have taken many paragraphs to say, was communicated very
accurately and succinctly by Rachel in a single paragraph. I recommend
you re-read what she said included below.
Thanks for listening,
Steve Bollinger
Cisco Systems GPS-IT XML/EDI Logistics & Maintenance Project
At 12:29 PM 7/3/00 -0500, you wrote:
>There are even more who don't get the fact the XML/XSL or any of the
other
>components in a full suite of XML tools will NOT provide automatic
alignment
>of the business meaning of data....what I term semantic alignment. This
task
>is where the rubber hits the road, regardless of what set of rules
(EDI,
>XML, proprietary) one is using to structure data. This is also where
human
>effort must be applied. Thus, while XML has some usefulness neither it
nor
>EDI nor any other data structuring rules will align the business mean
of
>data between disparate applications even if both applications can parse
an
>XML data stream.
>
>Rachel
Steve Bollinger 408-853-8478
Cisco Systems GPS-IT XML/EDI Logistics & Maintenance Project
------ 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
