OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [Fwd: Re: [xml-dev] Edi complexity, does ebxml really reduce it?]

I'd support Duane point of vue. More precisely : EDI is a concept, EDIFACT
is an ASCII format containing "some" business semantics coming fom 25
years
of experience.
EDIFACT isn't an infrastructure. The only link I see with any VAN
infrastucture is the fact that there is an EDIFACT envelope (UNB segment)
which can be processed by a VAN in order to deliver the message. But this
doesn't give me a clue on what technologies could be used to transfer it.

ebXML is clearly an infrastructure which is competing with VAN. By itself,
ebXML doesn't reduce EDI complexity because it's the business complexity
and
diversity which is behind that. ebXML brings an easy and cheaper way to
send
Business transactions between partners.

Jean-Luc Champion

E-Busines Standards Development

-----Message d'origine-----
De : Duane Nickull [mailto:dnickull@adobe.com] 
Envoyé : mardi 13 juillet 2004 17:45
À : Chiusano Joseph
Cc : ebxml-dev@lists.ebxml.org
Objet : Re: [Fwd: Re: [xml-dev] Edi complexity, does ebxml really reduce
it?]

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.

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.  

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 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




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>>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]