- From: Williams, Stuart <skw@hplb.hpl.hp.com>
- Date: Wed, 3 Jul 2002 18:18:43 +0100
- To: "'noah_mendelsohn@us.ibm.com'" <noah_mendelsohn@us.ibm.com>
- Cc: "'Mark Baker'" <distobj@acm.org>, "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>
> -----Original Message----- > From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] > Sent: 03 July 2002 16:54 > To: Williams, Stuart > Cc: 'Mark Baker'; 'xml-dist-app@w3.org'; xml-dist-app-request@w3.org > Subject: RE: FW: LC Comments: Web Method Feature > > > Stuart Williams writes: > > >> If the binding specification or implementation introduces > >> further constraints that aren't part of the relevant > >> feature/MEP definition then it is implementing a > >> different (undefined) feature from the one that it > >> is claiming to implement (IMO). > > As you know, I think the design is fine as it stands. The reason we > disagree seems to be this: you seem to feel that the application visible > functions provided by a binding should be limited exactly the union of the > features (including MEPs) implemented, with no further constraints of > conventions allowed. I disagree. > > I believe that any features should be used as documented. The current > HTTP binding does this. All uses of req/resp are legal per the spec for > that MEP, and the same for SOAP Response. At present as specified one can successfully use either MEP with any HTTP method and there is nothing in the binding specification that constraints this and only discouraging words in the Web Method feature about the use of anything other than GET with SOAP-Response and POST (and perhaps PUT) with Request-Response. At present no behaviour is specified for the HTTP binding if the Web Method feature is not used at all. > Likewise the Webmethod feature > is used correctly. Furthermore, I note that the two MEPs both use > reqres: for their properties, which signals to me an intent that a degree > of polymorphism is intended in the interface to the two. In other words, > applications need not always be aware of which one they are using. I > believe this was intentional. Must admit that I noticed this and found it mildly awkward (but not enough to offend)... it suggests to me that the reused properties are perhaps more globally useful and that their naming should perhaps be 'rooted' in context: rather than in the name of the exchange pattern. I think in part that what was intentional was a degree of economy in the pages used to describe the binding and features. I think as in general, if MEPs are an important concept, all participants in a exchange should be able to determing correctly what MEP is in use. > Most importantly, tou indicate that the additional constraints imposed by > the binding (I.e. the binding chooses to reject particular combinations of > Web Method and MEP) are a "different (undefined) feature." They are > arguably not a feature, but they are surely defined in the specification > for the HTTP binding. There are no combinations of method and MEP that our binding, as defined, rejects. > So where we differ is: I believe that it's OK for > a binding to have its own semantics and interfaces in addition to those > provided by the features implemented. That would be fine... but I would abstract them as binding specific features and describe then as such within the context of a binding specification. > For example, I would have no > problem if the http binding required some properties named http:xxx and > acted on those properties. That more tricky. Essentially you are introducing a notion of "mustUnderstand" features which I do not believe we have had. Ie. in order to *use* this binding you "mustUnderstand" some particular features that it provides. At present the HTTP binding states: "An implementation of the SOAP HTTP Binding MUST support the following feature: http://www.w3.org/2002/06/soap/features/web-method/" (see 6.4 Web Method Specification Feature)" I take that to be a statement about the *provision* of the feature (which is fine), not about its *use*. > I agree that the explanation in the HTTP binding would benefit from some > editorial clarification. I strongly disagree that the Webmethod should be > inferred from an MEP. My proposal [1] does not say that (at least not as emphatically as you appear to suggest). At the initiator it proposes that: If the Web Method feature is *used* it takes precidence. If the Web Method feature is *not* used the an MEP dependent default HTTP method is used, GET for SOAP-Response, POST for Request-Response. For the responding node I have made no proposal. Philosopically I think it is wrong that it is not possible for the recipient to accurately determine the MEP is use, although (GET | HEAD | DELETE) => SOAP-Response and (PUT | POST) => Request-Response seem reasonable and pragmatically I could live with that. > I think it is reasonable to infer the MEP from the > method. This feels like two sides of the same coin in some sort of constraint/logic programming language. > This follows from the nature of what each of these conveys. In > general, there are lots of methods that could be used with a given MEP. But not all bindings support the concept of Web Method and the MEP features have semantics that are defined independent of the use of Web Method. If the use of a binding chooses not to use Web Method... the MEP if supported by the binding should (IMO) function as adverstised. > For example, if we decide to support PUT (and it is essentially allowed > but discouraged) then that would almost surely join POST as a user of > request/response. I agree... and what I propose does not prohibit that. > On the other hand, I see no strong reason to use > multiple MEPs for a given method. :-) and whether MEP or Method has primacy will depend upon where you want to be on the chamelon / messaging / tunnelling axis. > GET is naturally a Response only, and > I suspect DELETE is as well. PUT and POST seem to be request/response. I don't think we disagree on that... although I would like to think that we could count on SOAP-Reponse to be safe which likely excludes it use for delete. > Thank you! > > ------------------------------------------------------------------ > Noah Mendelsohn Voice: 1-617-693-4036 > IBM Corporation Fax: 1-617-693-8676 > One Rogers Street > Cambridge, MA 02142 >------------------------------------------------------------------ Best regards Stuart [1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0000.html
Received on Wednesday, 3 July 2002 13:19:14 UTC