- From: Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>
- Date: Tue, 21 Oct 2003 18:21:40 +0200
- To: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
- Cc: www-ws-desc@w3.org, Jonathan Marsh <jmarsh@microsoft.com>, FABLET Youenn <youenn.fablet@crf.canon.fr>, Herve Ruellan <herve.ruellan@crf.canon.fr>
Wow, what a shock! The immediate SOAP proponent in me says no, we can't really just drop headers! I haven't ever considered SOAP header blocks as just "middleware"; I know some do. Of course, the feature argument sounds compelling... although it opens the door to features being dropped in a (hypothetical) second step, which I would oppose. Obviously, I need to think more about this. I am generally in favour of simplification, but I also like flexibility. Jonathan, since I will be away on Thursday, and since Youenn will have just come back from paternity leave, can we please differ discussion of Sanjiva's proposal until next week? Thank you, Jean-Jacques. Sanjiva Weerawarana wrote: > During the <message> elimination process, I proposed that it be > eliminated by introducing a single element that may go as the > body of the message and zero or more "header" elements. The motivation > was that it was possible in WSDL 1.1 to have such header and body > parts and we didn't want to lose that functionality. > > The main use of the "header" parts are to enable one to use WSDL > to describe middleware protocol type "applications" of WSDL. That > is, one can imagine protocols requiring certain headers to be > present etc.. > > However, to fully describe such protocols the header stuff has to > be much much richer. If you look at the original context proposal > I made back in January this year, you'll see some of that richness, > but even that is not enough. > > At the same time, complicating WSDL to the extent needed to make > it possible to fully describe a handful of middleware protocols > when compared to the millions of "regular" applications doesn't > seem like the right tradeoff. > > Thus, we now propose we drop the "headers" concept from input and > output messages. Messages will simply be a single XML element. > > I also propose a simple syntactic change to exploit this new > simplified structure of messages. Rather than the current form: > > <input messageReference="xs:NCName" > body="xs:QName"? headers="list of xs:QName"?/> > > I suggest we use: > > <input messageReference="xs:NCName" > message="xs:QName"/> > > And similarly for <output>. The same syntactic approach can be > used to make <fault>s consistent with this approach. Rather the > current form: > > <infault messageRefernce="xs:NCName" details="xs:QName"/> > > I suggest we use: > > <infault messageReference="xs:NCName" message="xs:QName"/> > > And similarly for <outfault>. > > Thus, this email proposes the following changes to status quo: > - drop interface/operation/(input|output)/@headers > - rename interface/operation/(input|output)/@body to > interface/operation/(input|output)/@message > - rename interface/operation/(infault|outfault)/@details to > interface/operation/(infault|outfault)/@message > > Sanjiva. > >
Received on Tuesday, 21 October 2003 12:25:20 UTC