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

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
in SOAP

<snip/>

> > > 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
I
> > > 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
that
> > > 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
with
> > 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
with
> 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
to
> > retrieve it. Don't really understand why we would have to say anything
at
> > all about this, other than remind folks that the can use  HTTP as HTTP.
'The
> > 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
format
> > - nothing more.
> >
> > I'm not arguing against regular HTTP, just that SOAP is something
different
> > - 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
impression.

> [....]
> > 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
another
> > content format.
> >
> > If that's what we want to do... we should say so... but I wouldn't then
wish
> > to call it a messaging framework.
> 
> Implementor feedback preview: this is *exactly* what I'm doing. It is
useful.

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
know!
Are you doing HTTP? Are you conforming to the HTTP spec? I expect that you
are.

> > I don't think it is our role to describe the behaviour of things that
are
> > 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/

Cheers


Stuart

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