W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2002

RE: FW: LC Comments: Web Method Feature

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
Message-ID: <OF5D587D8C.6B149918-ON85256BEB.0056F4E5@lotus.com>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:10 GMT