- From: Williams, Stuart <skw@hplb.hpl.hp.com>
- Date: Tue, 3 Sep 2002 11:17:32 +0100
- To: "'Dan Brickley'" <danbri@w3.org>, Jacek Kopecky <jacek@systinet.com>
- Cc: xml-dist-app@w3.org
Jacek, Dan, FWIW I think that in responding [1] to the issue raised by the TAG the XML-WG clearly paved the way to enabling and encouraging the so-called RESTful use of SOAP bound to HTTP. Equally, I don't think that the WG has took the position that such use is the only legitimate use over SOAP/HTTP. I think the 'classic' ways of using SOAP remain available, but there is (strong) encouragement to make resources visible 'on-the-Web' (so that they can be linked, described... etc.) and, as far as is possible, to use access methods that indicate the 'presumed' (on the part of the sender) 'safety' of the message conveyed. Sam Ruby has written an interesting article [2] with practical guidance on a unified approach to REST and SOAP. Regarding Issue 301 itself [3] and Gudge's proposal to close it without action [4]. That seems fine to me. The binding framework provides the abstraction of features and MEP that enables the specification of bindings that support identical or overlapping functionality. Exposing these abstractions (features, MEPs) in implementations (which is not mandated) would enable SOAP applications to make use of bindings that provide the functionality that they need and avoid using bindings that impose unacceptable (to the application) contraints (like the application must use a feature that it doesn't understand). The choice to expose such abstractions (or not) is entirely in the hands of those that design and implement SOAP platform APIs - and yes and their motivation to do so is likely conditioned by the (expected) repetoire of commonly used bindings specifications. Further binding specifications might be both be useful in their own right and useful to reinforce the utility of the framework, but I don't think they are essential for this pass through the process. Best regards Stuart Williams (speaking only for himself) BTW - I preceded RESTful with 'so-called' not to be disrespectful, but because I think that Fieldings REST Architectural *Style* has broader application than the world of http accessible resource - ie. its about more than just the resources that support GET, PUT, POST, DELETE... e.g. consider the sorts of resources identified by URI from none http schemes eg. telnet:example.org, ldap:example.org ... [1] http://lists.w3.org/Archives/Public/www-tag/2002Jun/0124.html [2] http://radio.weblogs.com/0101679/stories/2002/07/20/restSoap.html [3] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x301 [4] http://lists.w3.org/Archives/Public/xml-dist-app/2002Aug/0066.html > -----Original Message----- > From: Dan Brickley [mailto:danbri@w3.org] > Sent: 02 September 2002 20:08 > To: Jacek Kopecky > Cc: xml-dist-app@w3.org > Subject: Re: Issue 301: Universal Transport Binding > > > > On Mon, 2 Sep 2002, Jacek Kopecky wrote: > > > > > Hi all, 8-) > > it will be a pity if SOAP, as provided by the W3C, is limited to > > RESTful application (because we don't want to promote RESTless > > applications over HTTP, do we?) > > I don't think the charter imposes such a limitation, and I have > > yet to see an example of a RESTful application which is benefited > > by using SOAP (as opposed to HTTP alone). > > Surely the SOAP Encoding conventions are useful for RESTful applications? > (although that's only a small piece of SOAP 1.2 itself...) > > Dan > > > > It may come down to the question of why it's W3C and not IETF > > who works on SOAP, but I'm not trying to propose that W3C drop > > the XML Protocol effort. > > Best regards, > > > > Jacek Kopecky > > > > Senior Architect, Systinet Corporation > > http://www.systinet.com/ > > > > > > > > On Sat, 31 Aug 2002, Martin Gudgin wrote: > > > > > > > > I propose that we rule this[1] out-of-scope and close it > with no action. > > > > > > Gudge > > > > > > [1] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x301 > > > > > > > > >
Received on Tuesday, 3 September 2002 06:18:14 UTC