It's deja vu all over again. This article uses concepts, phrases, etc. that
were all applied to traditional EDI several years ago....before XML. Also,
the role the Viacore appears to be playing is not at all dissimilar to the
role of the EDI VANS. It would appear that what goes around comes around!
Rachel
>
>
> 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
