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

RE: [getf] Proposal for Web-friendly representation of RPC's in SOAP

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Thu, 30 May 2002 12:54:59 +0100
Message-ID: <5E13A1874524D411A876006008CD059F192BE9@0-mail-1.hpl.hp.com>
To: "'Dan Brickley'" <danbri@w3.org>, "Williams, Stuart" <skw@hplb.hpl.hp.com>
Cc: "'Henrik Frystyk Nielsen'" <henrikn@microsoft.com>, noah_mendelsohn@us.ibm.com, xml-dist-app@w3.org

Hello Dan,

> -----Original Message-----
> From: Dan Brickley [mailto:danbri@w3.org]
> Sent: 30 May 2002 10:50
> Hi all
> On Thu, 30 May 2002, Williams, Stuart wrote:
> > > -----Original Message-----
> > > From: Henrik Frystyk Nielsen [mailto:henrikn@microsoft.com]
> > > Sent: 30 May 2002 00:10
> > > To: noah_mendelsohn@us.ibm.com; xml-dist-app@w3.org
> > > Subject: RE: [getf] Proposal for Web-friendly representation of RPC's


> > > 2) When you say that one should use PUT for creating a resource, we
> > > should make it clear that this doesn't involve a SOAP message as such.
> > > The semantics of PUT is that the entity-body in the request represents
> > > the state of the resource to be created. If the operation succeeds and
> > > perform a GET I get the resource that I just PUT. The PUT request
> > > doesn't "execute" the SOAP message. The reason I said "as such" is
> > > it is of course perfectly valid to PUT a SOAP message and subsequently
> > > do a GET on it.
> >
> > If this "doesn't involve a SOAP message as such." what has it got to do
> > SOAP?
> One possible related scenario: the use of the SOAP Encoding data format as
> a stand alone data format, outside of SOAP as-xml-protocol interactions
> some specific service. I'm using it in this way: I have a directory full
> of 'software_package_name_soapenc.xml' files on my Web server, also
> available in a tar.gz bundle. Each soap-encoded document describes a
> software package. Using SOAP Encoding is nice as these XML docs can be
> turned into running Java/Perl/Ruby really easily; but I'm not using
> SOAP-as-protocol. HTTP PUT, or even WebDAV, is a fine mechanism for
> interacting with such documents.
> The SOAP spec doesn't call out such uses (in fact we had to strip out the
> protocol stuff from the SOAP-Enc'd instance data, so we may be at odds
> with the spec). Maybe it should? Seems a cheap way of using pure HTTP (per
> the REST lobby's concerns) while also exploiting a major chunk of the SOAP
> specification.

So... you are using SOAP encoding as a content-format and the protocol you
are using is HTTP.

> I'll send feedback on this work after the next Working Draft 
> is published.
> > This seems like regular HTTP, using PUT to write to some storage and GET
> > retrieve it. Don't really understand why we would have to say anything
> > all about this, other than remind folks that the can use  HTTP as HTTP.
> > PUT request doesn't "execute" the SOAP message.' implies that the SOAP
> > message processing model does not apply which IMO further reinforces the
> > notion that this usage is plain HTTP with a SOAP message as a content
> > - nothing more.
> >
> > I'm not arguing against regular HTTP, just that SOAP is something
> > - but then, maybe the title of part 1 doesn't mean anything.
> What about SOAP part 2?


> The encoding bits of SOAP are something different. SOAP encoding --
> basically just defines another Web data format that is particularly 
> useful in protocol contexts. 

So... I think that we're agreeing - yes?

> SOAP Encoding is a *big* and complex part of SOAP to implement, test; if
it can't be used 
> outside of SOAP protocols (eg. in normal HTTP transactions) we have
something of a
> re-use problem. SOAP 1.2 would be greatly simplified if Encoding were
> relegated to a separate Note (personal view); if it is to stay, it should
> imho earn its place by being re-usable as a doc format in pure HTTP apps.

Is that re-use, or just being clear about what SOAP-Encoding is? And yes, I
think that you are right that the SOAP-Encoding is indeed a seperable and
reusable piece of the work of the WG. 

> To say that pure-HTTP apps have nothing to do with SOAP ignores the hidden
> value of the Encoding / part 2 section of the SOAP 1.2 draft.

Actually, I've just realised I mis-interpreted Henrik's item 2) above, since
he goes on to explain the 'as such'. There has been some tone in the WG
discussions about doing HTTP GETs, getting back GIFs and calling it SOAP.
That is what provoked the question 'If this "doesn't involve a SOAP message
as such." what has it got to do with SOAP?'.

I don't object to doing pure-HTTP with SOAP-Encoding as a content-format (or
even as a format for part of the content) - and didn't mean to give that

> [....]
> > Well... in that case I think we have stepped outside of the "SOAP 1.2
part 1
> > Messaging Framework" and we are doing HTTP with SOAP Messages just
> > content format.
> >
> > If that's what we want to do... we should say so... but I wouldn't then
> > to call it a messaging framework.
> Implementor feedback preview: this is *exactly* what I'm doing. It is

Yes... your doing HTTP with SOAP-Encoding as a content-format.

Are you doing SOAP? Are you conforming to the SOAP spec? I really don't
Are you doing HTTP? Are you conforming to the HTTP spec? I expect that you

> > I don't think it is our role to describe the behaviour of things that
> > not SOAP nodes.
> Please try to describe the meaning of SOAP Encoding documents
> independently of processing scenarios.

I think that part 2 does a fair job of separating out the data-model, an
encoding of a data-model and a convention for their use in RPC. I think many
in the WG would share your views about the separate utility of these pieces
from the rest of the spec. Some would focus more strongly on the messaging
framework as being what SOAP was about, others would focus on a data
representation format.

> Having a working group try to imagine all likely processing scenarios for
a data format is risky.
> Consider XSLT, and the massive re-use of it that we've seen that go way
> beyond original goals as a styling mechanism. SOAP Encoding could enjoy a
> similarly rosy future if specified in a way that doesn't try to
> second-guess the uses that the Web community will find for it.
> cheers,
> Dan
> -- 
> mailto:danbri@w3.org
> http://www.w3.org/People/DanBri/


Received on Thursday, 30 May 2002 07:57:14 UTC

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