RE: issue 227

Mark,

To the best of my knowledge and throughout my involvement in the TBTF and
the WG it has always been clear (at least to me) that the binding
framework/SOAP extensibility model along with the concepts of features,
properties, property containers (message exchange context) modules and
bindings are descriptive tools to enable the structuring and re-use of
components parts of a specification. At no time (to my recollection) has it
ever been the intention that the structure of the description (partitioned
into features specs, binding specs, and module specs) be prescriptive on the
structure of an implementation. The thing that it does make sense to be
precriptive about is the externally observable behaviour of implementations
that claim conform to the specifications - ie. they claim to exhibit the
behaviour that the specifications require.

The position you appear to be taking is that the WGs resolution of 227 does
indeed place requirements on the structure of an implementation. I may have
miss read that - in which case I'm sure you will correct me. But if that is
your position, then I believe that it is on the other side of a line that
the TBTF and the WG took some care not to cross.

To summarise:

The binding framework (features, properties, message exchange contexts) in
particular is about structuring the behavioural description embodied in a
binding specification. It is *not* about constraining the structure of an
implementation. It may be convenient as a means to meet the behavioural
requirements of a binding specification to structure an implementation along
the lines of the framework based specification... but it is not (IMO) a
requirement to do so.

So suggest otherwise... is what I characterised as attempting "...to cease
more ground...." in an earlier response... and would be a *big* change in
the WG's philosophy with respect to the framework.

Best regards

Stuart
--

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: 22 August 2002 00:20
> To: noah_mendelsohn@us.ibm.com
> Cc: Henrik Frystyk Nielsen; jacek@systinet.com; 
> jones@research.att.com;
> marc.hadley@sun.com; moreau@crf.canon.fr; skw@hplb.hpl.hp.com;
> xmlp-comments@w3.org
> Subject: 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 Thursday, 22 August 2002 05:34:03 UTC