- From: <noah_mendelsohn@us.ibm.com>
- Date: Wed, 3 Jul 2002 11:54:09 -0400
- To: "Williams, Stuart" <skw@hplb.hpl.hp.com>
- Cc: "'Mark Baker'" <distobj@acm.org>, "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>, xml-dist-app-request@w3.org
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. 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. 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. 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. For example, I would have no problem if the http binding required some properties named http:xxx and acted on those properties. 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. I think it is reasonable to infer the MEP from the method. 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. 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. On the other hand, I see no strong reason to use multiple MEPs for a given method. GET is naturally a Response only, and I suspect DELETE is as well. PUT and POST seem to be request/response. Thank you! ------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 IBM Corporation Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------
Received on Wednesday, 3 July 2002 12:13:39 UTC