Re: issue 227

Hi Noah,

On Wed, Aug 21, 2002 at 06:15:14PM -0400, noah_mendelsohn@us.ibm.com wrote:
> * Issue 227 in particular questions such mandatory use of the webMethod 
> feature by the HTTP binding.  The WG has voted to make no change in this 
> mandatory use of the webMethod feature by the http binding.  The HTTP 
> binding continues to mandate that a sending node determine the webMethod 
> (e.g. POST, GET) to be used when transmitting a non-Response message. 
> (Note that the entire property-based binding framework is abstract:  at no 
> point does the HTTP binding attempt to describe a particular API or 
> implementation structure, so this resolution says nothing about whether 
> method names such as GET would be supplied explicitly or otherwise on some 
> particular API;

How do you reconcile that with the proposal;

] [scribenrm] DF: Proposal...(1) we accept that bindings can specify
] that features are mandatory (2) we sweep the spec to ensure that's
] clear (3) leave web method as a mandatory feature of the http
] binding...i.e. that applications must supply a value for the
] property...and to make sure the spec is clear on that point.

specifically the "applications must supply a value" part?

Or, from the LC WD;

"Bindings to HTTP or such other protocols SHOULD use the Web Method
Specification Feature to give applications control over the Web methods
to be used when sending a SOAP message."
 -- http://www.w3.org/TR/soap12-part2/#WebMethodFeature

What I extract from your proposal is that it's ok for the SOAP library
to supply the value without direction from the application.  This seems
to be a significant change from the current WD.  I agree that there are
valid cases where the library can supply the value, such as if the API
it exposes can suitably represent the semantics of the methods to the
developer; e.g.  "o < foo" triggers GET, "o > foo" triggers PUT,
"o >> foo" triggers POST, etc..  But I'm concerned that SOAP
implementers will think that by saying nothing about this, that we're
giving the thumbs up to doing things like inferring the method from the
MEP, or other information which has nothing to do with the method.

If you like that reasoning, I can write it up as a proposal.

>  it merely mandates that the sending node determine the 
> method in some implementation specific manner, and it declines to supply 
> any standard way of inferring the method from other information provided 
> with the message to be transmitted."

Wouldn't a SOAP 1.1 node meet that criteria?

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com

Received on Wednesday, 21 August 2002 19:35:37 UTC