Joe, Standardized infrastructure that draws on the experience and knowledge of hundred of professional computer science and business operations people is ebXML. Locally defined infrastructure defined by a small team of individuals with the only common point of the architecture being a file format is "EDI". Its an aging argument that "we can do it with EDI", or "why not just design our own". An evolution has to take place in the way we do business, and the only way to clear the path for true business innovation is to agree on a lingua franca for how we integrate our businesses. Regards, Matthew MacKenzie Sr. Architect Adobe Systems On Jul 13, 2004, at 11:49 AM, Chiusano Joseph wrote: > Duane, comments below marked with [JMC]. > > Duane Nickull wrote: >> >> They are comparing apples and oranges. EDI is an ASCII format for >> data, >> ebXML is an infrastructure. EDI may be used within the ebXML >> infrastructure. > > [JMC] Yes, but does EDI not include an infrastructure as well, which is > - most often - provided by a VAN? Or are you pointing out (very > correctly, IMO) that ebXML defines a standard representation of > infrastructure while EDI's infrastructure is vendor-variable? > >> Accordingly, finding that the infrastructure is larger than one of >> it's >> components is understandable and I would agree with the author of this >> email. > > [JMC] Which author? The original author, or me? > >> Furthermore, it is my belief that any technology needs to be "hidden" >> before it will be successful. I did not have to know SMTP in order to >> send this email - the clever engineers at Netscape hid all that from >> me > > [JMC] Clever? I prefer MS Outlook, although I too am using Netscape. ;) > > Joe > >> and presented me only with a "send" button. Same with clicking on a >> hyperlink. One does not have to know anything about HTTP. >> >> Duane Nickull >> >> Chiusano Joseph wrote: >> >>> FYI - question about ebXML and EDI on the XML-DEV listserv. >>> Forwarding >>> here for opportunities for correction, expression of differing >>> opinion, >>> etc. >>> >>> Original question is at: >>> >>> http://lists.xml.org/archives/xml-dev/200407/msg00110.html >>> >>> Kind Regards, >>> Joe Chiusano >>> Booz | Allen | Hamilton >>> Strategy and Technology Consultants to the World >>> >>> -------- Original Message -------- >>> Subject: Re: [xml-dev] Edi complexity, does ebxml really reduce it? >>> Date: Tue, 13 Jul 2004 10:02:28 -0400 >>> From: "Chiusano Joseph" <chiusano_joseph@bah.com> >>> Organization: Booz Allen Hamilton >>> To: Michael Kay <michael.h.kay@ntlworld.com> >>> CC: bry@itnisk.com, xml-dev@lists.xml.org >>> References: <20040713133910.HWGG8666.mta02-svc.ntlworld.com@Turtle> >>> >>> You're right Mike. I'll reproduce the questions below and answer them >>> here: >>> >>> >>> >>>> Whenever one examines one of the ebxml specs or reads an article on >>>> the subject >>>> there is likely to be a reference to how edi had problems with >>>> being accepted >>>> because it was too complex, but luckily ebxml, being based on xml, >>>> solves all >>>> this >>>> >>>> >>> >>> Not completely, but it can make usage of EDI easier (please read on). >>> >>> >>> >>>> A very suspect class of assertion it seems like to me. I'm >>>> wondering if >>>> anyone who has familiarity with these technologies can clarify >>>> exactly how and >>>> in what ways ebxml reduces the complexity of edi. >>>> >>>> >>> >>> In general, ebXML is "payload agnostic" - so the payload can be XML, >>> EDI, binary files, etc. So the degree to which it reduces the >>> complexity >>> of EDI depends on how much of an improvement the "ebXML approach" and >>> tools might be over those for EDI (a subjective judgment, IMO). >>> There is >>> also a great lack (IMO) of ebXML tools/products available, and still >>> a >>> good amount of EDI tools/products - so that factors in. There is also >>> the factor of product price, which would require a detailed >>> comparison >>> that I have not done (and I am not aware of anythat exists). >>> >>> >>> >>>> Basically my understanding is that ebxml just wrapped the edi model >>>> in xml, so I >>>> have a hard time seeing how it could be simpler. >>>> >>>> Also am wondering about CPAs in Ebxml, it strikes me that this >>>> process could >>>> actually be somewhat onerous, does anyone know of any case studies >>>> etc. on >>>> problems with making CPAs between two companies? >>>> >>>> >>> >>> CPAs in general represent the system features that are agreed upon - >>> electronically or non - by two trading partners. CPAs include various >>> paramters/settings (pick favorite word) that relate to security, >>> messaging, business process specification, etc. Whether the process >>> is >>> onerous or not comes down (mostly) to the tools that are available, >>> and >>> how easily they automate the process. >>> >>> Hope that helps. >>> >>> Kind Regards, >>> Joe Chiusano >>> Booz | Allen | Hamilton >>> Strategy and Technology Consultants to the World >>> >>> Michael Kay wrote: >>> >>> >>>>> These excellent questions are probably best asked on the >>>>> ebXML-dev list. >>>>> >>>>> >>>> Only if you want an answer from the kind of person who lives on >>>> that list. >>>> If you want answers from the people who have given up on ebxml >>>> because they >>>> found it too complex, asking here might be better. >>>> >>>> Michael Kay >>>> >>>> >>> >>> >>> >> >> -- >> Senior Standards Strategist >> Adobe Systems, Inc. >> http://www.adobe.com > > -- > Kind Regards, > Joseph Chiusano > Associate > Booz | Allen | Hamilton > > The ebxml-dev list is sponsored by OASIS <http://www.oasis-open.org> > The > list archives are at http://lists.ebxml.org/archives/ebxml-dev/ > To subscribe or unsubscribe from this list use the subscription > manager: > <http://www.oasis-open.org/mlmanage/> > The ebxml-dev list is sponsored by OASIS <http://www.oasis-open.org> The list archives are at http://lists.ebxml.org/archives/ebxml-dev/ To subscribe or unsubscribe from this list use the subscription manager: <http://www.oasis-open.org/mlmanage/>
<<attachment: winmail.dat>>