- From: James Snell <jsnell@lemoorenet.com>
- Date: Tue, 17 Oct 2000 22:56:02 -0700
- To: <xml-dist-app@w3.org>
When considering the requirements of ebXML in both architecture and timeline, one would have to agree with this assessment. I think that, at least for the time being, it is best that ebXML takes its own path separate from SOAP in order to accomplish what the ebXML group needs to accomplish. However, I also think that part of the work of this working group should be to look at ebXML and SOAP and find out how and where they are similar; how and where they can be "grafted" together. It must be recognized that in the long term, the best solution for the developers (who matter most here) will not be purity of multiple standards, but the usability of a single standard. ebXML and SOAP and others SHOULD be merged into one -- MUST be merged into one. Anyway.... I realize I'm preaching the choir on this point so I'll shut up now :-) And, oh, by the way, just so everyone knows, I am NOT a member of the working group in any way, I'm just here to, um ... observe ;-) - James -----Original Message----- From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On Behalf Of Dick Brooks Sent: Sunday, October 15, 2000 4:46 PM To: Andrew Layman; xml-dist-app@w3.org Cc: dick@8760.com Subject: RE: !-Re: ebXML Abandons SOAP Andrew, Sorry for the looong delayed response, I've been traveling most of the week. I don't want your very important question to go unanswered, so here goes. James Snell pointed out some of the reasons why SOAP version 1.1 fails to provide a complete infrastructure for ebXML, here are some additional reasons: - no support for "popular" encryption and digital signature technologies (e.g. PGP and S/MIME) - no direct handling of binary objects (without encoding) - no direct support for nesting multiple XML documents in a payload (without manipulation of the documents) - no support for reliable messaging semantics - no packaging semantics for multimedia types - no defined approach for access control/authentication - SOAP is not a standard (ebXML required the use of industry standards whenever possible) I suppose it would be possible to graft all the functionality needed by ebXML onto SOAP 1.1, however ebXML was already far down the road in developing a MIME based solution when SOAP 1.1 was published. Abandoning ebXML's MIME based solution for SOAP 1.1, combined with all the work needed to "fill the gaps", would have introduced significant risk into an already tight delivery schedule. Dick Brooks (ebXML liaison to W3C XP) Group 8760 110 12th Street North Birmingham, AL 35203 dick@8760.com 205-250-8053 Fax: 205-250-8057 http://www.8760.com/ InsideAgent - Empowering e-commerce solutions > -----Original Message----- > From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On > Behalf Of Andrew Layman > Sent: Monday, October 09, 2000 1:44 PM > To: xml-dist-app@w3.org > Subject: RE: !-Re: ebXML Abandons SOAP > > > Thank you for your clarifying explanation. During the intervening year > since ebXML began to investigate candidate technologies there have been > several important changes that ebXML might want to consider. In > particular, > the SOAP specification that is used by most implementors is not the 0.9 > version that ebXML looked at but the 1.1 version submitted to the > W3C on May > 8, 2000 and available at http://www.w3.org/TR/SOAP/. > > This, not the 0.9 version, is the one submitted to the W3C by Ariba, Inc., > Commerce One, Inc., Compaq Computer Corporation, DevelopMentor, Inc., > Hewlett Packard Company, International Business Machines Corporation, IONA > Technologies, Lotus Development Corporation, Microsoft Corporation > SAP AG, and UserLand Software Inc. > > This 1.1 specification is not a large technical change from 0.9 > or 1.0, but > does substantially improve the clarity of the explanations in the > document. > In particular, it makes it clear that the SOAP specification addresses not > just RMC but also general business document exchange. >
Received on Wednesday, 18 October 2000 01:58:41 UTC