RE: issue 78

I agree that vague areas of the spec should be cleared up.
In this case though, there are lots of things that are not part
of the core spec.   Digital Signature isn't part of the core spec
but is allowable, right?  I see boxcarring as the same type
of thing in that the spec isn't going to talk about it (except
to say it isn't going to talk about it  8-)  but that doesn't mean
it can't be done - they're just not going to tell us how to do
it.  You're equating "not part of the core spec" with "not
allowed" and I don't think they're the same thing. When the
spec disallows something a "MUST NOT" is used.
-Dug



"Frank DeRose" <frankd@tibco.com>@w3.org on 06/15/2001 06:53:12 PM

Sent by:  xml-dist-app-request@w3.org


To:   Doug Davis/Raleigh/IBM@IBMUS, "Jean-Jacques Moreau"
      <moreau@crf.canon.fr>
cc:   <xml-dist-app@w3.org>
Subject:  RE: issue 78



Doug,

The passage you refer to reads:

"A major design goal for SOAP is simplicity and extensibility. This means
that there are several features from traditional messaging systems and
distributed object systems that are not part of the core SOAP
specification.
Such features include

...

Boxcarring or batching of messages"

This seems to me just to say that boxcarring is not part of the core SOAP
specification. How, then, do you conclude that the SOAP spec allows
boxcarring? My own interpretation of this passage was that the spec did NOT
allow boxcarring.

So, I draw the following conclusions:

1.) The fact that two readers can conclude from the same passage that
boxcarring is allowed (Doug) or not allowed (me) seems to be positive
evidence that the spec is vague (needs to be rewritten) on this point.
2.) The WG needs to decide whether boxcarring should or should not be
allowed. My own personal opinion is that it should not be allowed (the S in
SOAP stands for "Simple"). But, if the WG decides that it should be
allowed,
the spec should be changed to describe explicitly how boxcarring should be
performed. In particular, as Doug points out, some convention for handling
faults should be supplied.
3.) If the WG decides that it wants boxcarring, then my proposed rewriting
of Section 7.1 obviously won't do.

F


> -----Original Message-----
> From: Doug Davis [mailto:dug@us.ibm.com]
> Sent: Friday, June 15, 2001 3:55 AM
> To: Jean-Jacques Moreau
> Cc: Frank DeRose; xml-dist-app@w3.org
> Subject: Re: issue 78
>
>
> Yes it does allow it, but it says that it isn't going to
> talk about it [1] (look for boxcarring).  I believe it is
> valid to put multiple RPC calls in the body (each one being
> its own body element) - if fact you can even put each RPC
> as a separate header - there are lots of ways to do it.
> But, the spec doesn't tell you how to handle things like
> faults (or multiple faults) or rollback if the 3rd rpc
> fails.  So, if someone wants to do this it would be up
> to them to decide how these issues are handled - as long
> as they conform to the spec.
>
> -Dug
>
> [1]
> http://www.w3.org/2000/xp/Group/1/06/01/xmlp-soap-02.html#_Toc478383487
>
>
>
> "Jean-Jacques Moreau" <moreau@crf.canon.fr>@w3.org on 06/15/2001 03:41:58
> AM
>
> Sent by:  xml-dist-app-request@w3.org
>
>
> To:   Frank DeRose <frankd@tibco.com>
> cc:   xml-dist-app@w3.org
> Subject:  Re: issue 78
>
>
>
> Frank,
>
> Am I missing something obvious, or does the spec allow you to have two
RPC
> requests within a single SOAP message? (I am also wondering why the usual
> QName+actor dispatching mechanism does not work here.)
>
> BTW, in your example, why couldn't "id1" be a header?
>
> Frank DeRose wrote:
>
> > <SOAP-ENV:Body
> > SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
> >   <SOAP-ENC:int id="i1" SOAP-ENC:root='0'>34.5</SOAP-ENC:int>
> >   <m:GetLastTradePriceResponse xmlns:m="Some-URI">
> >     <PriceAndVolume>
> >       <LastTradePrice href="#i1"/>
> >       <DayVolume>10000</DayVolume>
> >     </PriceAndVolume>
> >   </m:GetLastTradePriceResponse>
> > </SOAP-ENV:Body>
>
> Jean-Jacques.
>
>
>
>
>

Received on Friday, 15 June 2001 20:27:30 UTC