Thanks Rob. I am adding your comments to the mail-list thread. Steve At 04:58 PM 7/6/00 -0700, you wrote: >Thank you thank you! Finally someone has put things in the correct light. >I agree 100% with what you've said. Until all market participants agree on >a single standard or dictionary for their industry (which is not likely in >my lifetime), than any new technology that comes along will only be more of >the same. New technology cannot fully plug the holes which come with the >current standards. XML by it's very structure will encourage little >standardization, which will only serve to put batch processing back into >pre-EDI days. I too am not married to any one technology. I would just >assume see EDI and XML go away for a real solution. Any technology that >purports to solve the human driven (egos, etc) problems with the current >standards is really just "magic" in my books. > >Rob > >-----Original Message----- >From: Steve Bollinger [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, July 05, 2000 1: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 > 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
