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

>> However, it is not coherent with the framework we have defined for a 
>> binding to mandate the *use* of a feature. 

I'm afraid we disagree on this.  I think it's not only coherent, it's 
desireable in situations like this.

>> In a sense that introduces something akin to mustUnderstand for features

I don't think so.  MustUnderstand is important for headers because 
messages can arrive from arbitrary sites with unexpected mixtures of 
headers.  Features are very different.  If you are using a particular 
binding, then you MUST know and obey the specification for that binding. 
If the binding says as part of its local interface to the node "you MUST 
give me a destination URI", you must do that.  If the binding says:  "you 
MUST use feature F", then you must do that.  No negotiation is needed. 
Nothing resembling mustUnderstand.  If you've read the spec for the 
binding, then you know what to do.  If not, then you have no hope of using 
the binding correctly anyway.  In effect, the feature becomes a part of 
the binding spec.

Again, why have it as a feature at all?  To maximize compatibility across 
multiple bindings that may provide the same capability in a similar 
manner.  Optionality is an orthogonal issue IMO.  Thank you!

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







"Williams, Stuart" <skw@hplb.hpl.hp.com>
Sent by: xml-dist-app-request@w3.org
07/23/2002 09:38 AM

 
        To:     "'noah_mendelsohn@us.ibm.com'" <noah_mendelsohn@us.ibm.com>
        cc:     xml-dist-app@w3.org
        Subject:        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 Wednesday, 24 July 2002 12:25:14 UTC