RE: FW: LC Comments: Web Method Feature

Hi Mark,

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: 03 July 2002 17:24
> To: Williams, Stuart
> Cc: 'xml-dist-app@w3.org'
> Subject: Re: FW: LC Comments: Web Method Feature
> 
> 
> I think there's just one fundamental disagreement here, so I'll respond
> to that first.  After that, just a couple of quickies.
> 
> On Wed, Jul 03, 2002 at 04:23:00PM +0100, Williams, Stuart wrote:
> > A binding spec describes *how* to make use of the underlying protocol to
> > honor the semantics of the features (inc. MEPs) that the binding
> > specification requires implementations of that binding to support. If
the
> > binding specification or implementation introduces further constraints
that
> > aren't part of the relevant feature/MEP definition then it is
implementing a
> > different (undefined) feature from the one that it is claiming to
implement
> > (IMO).
> >
> > Clearly, you can fix this by modifying the relevant feature/MEP
definitions
> > to match the binding behaviour (I think this is your preference but not
> > mine).
> 
> Hmm, that wouldn't be my preference.  My preference would be that it is
> possible for there to be a mismatch between a set of features/MEPs,
> and a protocol binding.  i.e. "sorry, there's no reasonable way to
> implement this feature/MEP with this underlying protocol"

Ok... in our current style that would likely be expressed as a bunch of
precondition wrt to the use of a feature or features in combination. But we
are back to the optional/mandatory nature of the use rather than provision
of features.

I guess what your saying is... the binding user didn't set webmeth:Method,
the binding goes 'barf... you didn't set webmeth:Method' and the binding
user scratches its head... but I know what I expect Request-Response to
do... if its lucky someone says... just plug in POST it'll work, all will be
fine... so I use that recipe with no more or less understanding of who to
organise and identify resources than I had before.

> > > But perhaps some future HTTP-like protocol with its own GET
> > > could do that.
> > 
> > But... why would such a protocol ever need to do that to implement the
same
> > semantics as HTTP GET
> 
> Perhaps because it wants to account for SOAP.
> 
> >... I mean... if we start putting things in the body of
> > the request aren't we identifying resources by means other 
> than URI ;-)
> 
> Well, I didn't say the body would have to contribute to identifying
> anything.  It could just be an alternate header syntax[1].  8-O
> 
>  [1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jan/0416

Well I think that leaves things horribly twisted... but as possibly a non-
or an anti- layerist... I doubt that would bother you ;-)

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

Regards

Stuart

Received on Wednesday, 3 July 2002 14:12:46 UTC