RE: FW: LC Comments: Web Method Feature (really Features optional )

Hi Noah,

> -----Original Message-----
> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com]
> Sent: 23 July 2002 03:10
> To: xml-dist-app@w3.org
> Subject: Re: FW: LC Comments: Web Method Feature (really Features
> optional)
> 
> (I've been out for a week.  If this response is no longer pertinent,
> apologies in advance.)
> 
> Long ago in this thread, Jacek Kopecy wrote:
> 
> >>  I agree with Stuart though that once we call
> >> something a feature, it's not mandatory, it
> >> MAY be used to gain something.
> 
> I'm afraid I somewhat disagree, and I think the disagreement is indeed a
> central issue for this thread.
> 
> Yes, features are optional in the sense that there is no one feature
> required of all SOAP implementations, of all SOAP binding specifications
> etc.  However, it is absolutely the case that use of certain features can
> be mandatory per the specification for a particular binding.

I think we need some more precision here with respect to words like
'mandatory'. I think we need to make a distinction between *provision* and
*use*.

IMO it is coherent for a binding specification to mandated the *provision*
of a feature - I have no problem with that.

However, it is not coherent with the framework we have defined for a binding
to mandate the *use* of a feature. In a sense that introduces something akin
to mustUnderstand for features - and we don't have the concept of a
mustUnderstand feature in our binding framework - ie. if the binding
provides a feature that is tagged mustUnderstand and you don't understand
it... then you can't use that binding. There would be some appealing
symmetry with SOAP headers, but that is not how we framework is today.

> Most
> obviously, use of the Request/Response feature was mandatory in earlier
> versions of the SOAP HTTP binding.

It was mandatory that an HTTP binding *provide* that feature, yes. Indeed,
the binding specification still states:

    7.3 Supported Message Exchange Patterns

    An implementation of the SOAP HTTP Binding MUST support the following
message exchange patterns (MEPs):

    "http://www.w3.org/2002/06/soap/mep/request-response/" (see 6.2
Request-Response Message Exchange Pattern) 

    "http://www.w3.org/2002/06/soap/mep/soap-response/" (see 6.3 SOAP
Response Message Exchange Pattern) 


So, both MEPs are each 'as mandatory' as the Web Method feature and no-one
has yet suggested that the use of both is mandatory.

> You didn't have the option to use it,
> you had to use it.

No... you didn't have to *use* it... but it was the only thing available to
*use*.

> Nothing broken there.

Ok... but our emphasis is different...

> Now we have the Web Method
> feature.  I can see that there might be reason to debate its design
(though
> I would have much preferred that debate happen before last call).

On the whole I have no problem with the Web Method feature. Binding
specifications can mandate its *provision*, users of bindings can make *use*
of it if they choose to. This discussion (or at least LC#227) is not about
the description of the Web Method feature - it about the fact that the first
row in table 15 of part 2 *implicit* makes the *use* of the feature
mandatory because the behaviour of the HTTP binding, as specified, is
currently undefined if the feature is not used (ie. webmeth:method if is
absent from the message exchange context).

> I do not
> agree that the problem is or can be lack of optionality.  It is absolutely
> coherent for the HTTP binding specification to say:  to use this binding,
> an application MUST make use of the following feature(s).  Some of those
> might be MEPs, some might be other features.

So... this is the point of disagreement. To me this strikes at the whole
purpose of doing the framework. IMO the point of the framework was to enable
'applications' to be agnostic about the underlying protocols to which they
were bound and to present the (potentially diverse) functionality of those
protocols as features. Applications are then capable of selecting bindings
that support a range of features that the application 'understands' and
requires to use. The step of allowing a binding to mandate the *use* of a
feature forces us (globally) to have to recognise the binding (rather than
individual features) because the binding may impose further constraints not
implicit in the feature definition, and now we have just 'broken' the
purpose of the framework.

Now... I could accept an extension of our framework that allowed for the
concept of mustUnderstand features, so that features could be tagged as
mustUnderstand and applications would avoid using bindings that provided
mustUnderstand features that they did not understand.

If our framework admitted such a concept then the debate would be about
which of Request-Response MEP, SOAP-Response MEP and Web Method feature
should be labelled as mustUnderstand. Personnally, I can see no reason why
any of them should be so labelled. In fact... it perhaps goes beyond simply
mustUnderstand to mustUse (although the latter might be an implicit part of
understanding). I think to impose such a constraint one would have to give a
robust account of the benefits and losses that arise (see minimal constraint
[1,2]).

> Why name it as a feature if in that particular situation it's not
optional?

Again precision over provision and use. Mandatory provision is fine (by me)
- benefit is that it supports the chameleon style of use.

> Because it correctly describes an interface that may well prove to be
> common across other bindings.  For example, some other binding to HTTP
> might support the same feature.  A binding to HTTPS might support the
> feature.  Even a binding to some non-HTTP protocol that supports REST
> semantics would probably use the feature.

I have no argument against the utility of the Web Method feature.

> As has been previously noted, the reason it's the Web Method feature and
> not something else is that it anticipates other REST methods such as
DELETE
> (which would presumably, by the way, use the same MEP as GET).

And that's fine too... but an application that simply understand one or
other of the two supported MEPs should (IMO) be able to do so without
*having* to understand and *use* the Web Method feature. Thet may choose to
do so... they should not be compelled to do so.

> ------------------------------------------------------------------
> 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://www.w3.org/People/Berners-Lee/Weaving/glossary.html
[2] http://www.w3.org/Talks/1999/0211-Sloan-tbl/slide8-0.html

Received on Tuesday, 23 July 2002 09:38:54 UTC