W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2002

RE: FW: LC Comments: Web Method Feature

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Wed, 3 Jul 2002 20:49:51 +0100
Message-ID: <5E13A1874524D411A876006008CD059F04A06EFD@0-mail-1.hpl.hp.com>
To: "'noah_mendelsohn@us.ibm.com'" <noah_mendelsohn@us.ibm.com>
Cc: "'Mark Baker'" <distobj@acm.org>, Marc Hadley <marc.hadley@sun.com>, "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>

Hi Noah,

> -----Original Message-----
> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com]
> Sent: 03 July 2002 19:02
> To: Williams, Stuart
> Cc: 'Mark Baker'; Marc Hadley; 'xml-dist-app@w3.org';
> xml-dist-app-request@w3.org
> Subject: RE: FW: LC Comments: Web Method Feature
> Stuart Williams writes:
> >> Mandating its use (needlessly IMO) denies the
> >> messaging/tunneling view.
> I don't think so.

Seems Mark B would disagree with you about that, from [1]:

> >> Mandating its use (needlessly IMO) denies the
> >> messaging/tunneling view.
> For HTTP, yes it does, more or less.  

> All the admonitions to use GET vs. POST are SHOULDs. 
> Therefore a "tunnelist" can blindly use POST and get on with it, as he or 
> she always has.  Well, you might say (I infer somewhat presumptuously), 
> why should a "tunnelist" even have to think about something so 
> disorienting as a feature having to do with HTTP and REST.  To which I 
> would answer:
> * Because to use a binding such as HTTP you need to learn to use the API 
> documented for that binding.  That API happens to have a property which 
> essentially is documented as "set this to GET if your a chameleon who 
> knows what you're doing and you care, otherwise use POST."  So, not 
> caring, you use POST.

Well, from my point of view that was the whole point of the feature/property
abstraction. To a parcel that 'API' up into small reusable pieces and to
create the binding 'API' as an assemblage of those pieces working as
specified and where the user of that assemblage only has to deal with the
pieces that they understand.

The view that you promote now requires that the user of a binding has to
recognise the named binding in addition to recognising the supported
features (that it wishes to use) because the binding may introduce further
constraints. IMO this view undermines the value of the framework that we
have established...

> * All of the properties are abstractions anyway.  None of this requires a 
> typical user to bother or not bother with anything.

I certainly agree on the implementation pragmatics here. 

> If you are building 
> an implementation that's intended for use only by tunnelists, nothing here

> requires you to surface the choice to your users.  Surely you had to set 
> the method to POST in the actual HTTP transmission in any case no matter 
> what architecture we chose, and that's all you have to do now.

But... we could described this behaviour clearly and within the framework
with the proposal that I made.

At the moment... if the binding user doesn't use the Web Method feature (yes
in the abstract) we don't define behaviour for the HTTP binding.

> In other words, existing SOAP HTTP implementations are already more or
> compatible with the new binding, they just don't offer a level of control 
> over WebMethod that a chameleon should want.
> Cheers.
> Noah
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0031.html
Received on Wednesday, 3 July 2002 15:52:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:20 UTC