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
