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

Hi Noah,

Well... I guess that the upside is that we know what we disagree about...
but the downside is that we do disagree.

> >> 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. 

So that is the very point that we disagree about. If you are using a
particular binding, then you MUST know and obey the feature specifications
of those features that you actually make use of. That was the point of the
framework.

> If the binding says as part of its local interface to the node "you MUST 
> give me a destination URI", you must do that.

But... you do that by providing a feature, which persumably the user is
motivated to use, and the feature definition mandates the use of a property
to convey the destinationURI. Maybe destination URI is not a good example,
both of the MEPs we define require the specifcation of an immediate
destination URI.

> If the binding says:  "you MUST use feature F", then you must do that.

I think I am deny that our framework (as is) allows you to make such a
statement... and if it were to allow you to say that then I think it
undermines a substantial part of its raison-d'etre.

> No negotiation is needed. 

Its not really negotiation... there is no dialog.

> Nothing resembling mustUnderstand.  

I think that it is very similar.

> If you've read the spec for the 
> binding, then you know what to do.

If you've read the spec of the binding, then you, the binding developer know
what to do.

If you've read the spec of the features you intend to use, then you the
application developer know what to do.

> If not, then you have no hope of using the binding correctly anyway.

You should only *have* to understand the spec of the features you intend to
use - then you should be able to make use of any binding that supports that
combination of features... at least that was what the TBTF I was part of set
you to achieve by producing a framework.

> In effect, the feature becomes a part of the binding spec.

Certainly, the binding spec. about how to realise the semantics of those
features through the use of an underlying protocol.

> 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.

Agreed... although I wouldn't go so far as the "in a similar manner" as long
as the semantics of the feature (as specified in the feature specification)
are honored when it is used.

> Optionality is an orthogonal issue IMO.  Thank you!

Don't follow... optionality of use of a feature IS the issue.

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

Noah... I think that I have been clear about my position on this and
consistent throughout. I think that we understand each others positions and
sustained debated between us is unlikely to change them. I'm conscious that
mostly I'm repeating myself and adding very little that's new. So unless I
find myself with something fresh to say on this topic, I'm likely to go
silent on this thread until it comes up for discussion on a telcon.

Best regards

Stuart

Received on Wednesday, 24 July 2002 10:05:05 UTC