RE: issue 78

<delurk>
FWIW, boxcarring a large number of transactions is a very common 
technique at Schwab.  Moreover, at least one of the places
in which we do boxcarring is one of our best candidates for
web services.

I also think there are some scenarios here that may show the
applicability of both P1 and P2. I would see P1 being 
useful where we have a "batch response" to a single endpoint.
I would see P2 being useful where the different roots each
have their own response, perhaps to different endpoints.

Just a thought. 
</delurk>

-----Original Message-----
From: Bob Cunnings [mailto:cunnings@lectrosonics.com]
Sent: Saturday, June 16, 2001 10:42 AM
To: xml-dist-app@w3.org
Subject: RE: issue 78


Hello,

IMHO <FranksVersion3OfSection71> seems the better choice.

Is "boxcarring" in a section 7 RPC context an important enough 
use case to warrant a shift to P2? I think that it strains the 
processing model too much... multiple fault elements in the 
response and all. The loss of a one to one mapping between 
procedure call and message instance certainly complicates 
matters. More than anything else in XMLP, I would hope that the 
RPC mechanism remain as simple as possible.

Maybe I'm missing something and boxcarring will prove to be an 
indispensable technique... the subject comes up
from time to time but I wonder just how much it would be used.

Just my 2 cents worth.

RC

> > 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
> 
> Fair enough. Let me try again.
> 
> The WG needs to decide between the following two positions:
> 
> P1: In an RPC message, the Body MUST contain one and only one
serialization
> root.
> P2: In an RPC message, the Body MUST contain at least one serialization
root
> and MAY contain more.
> 
> P1 would still allow boxcarring, but only through a single serialization
> root. For example, each parameter in your request element could itself be
a
> request element; and each parameter in your response element could itself
be
> a response or Fault element (begging the question, of course, of whether a
> Fault element can appear somewhere other than as an immediate child of the
> Body). P2 would allow boxcarring through multiple serialization roots.
That
> is, each request/response/Fault element would be a direct child of the
Body.
> 
> The spec should be changed to state explicitly which position is mandated.
> If the WG decides to mandate P2, then my proposed rewriting of Section 7.1
> obviously won't do. So, here are two new proposed rewritings,
corresponding
> to P1 and P2:
> 
> Proposed rewriting that corresponds to P1 (essentially the same as
> <Version2OfProposedRewriteOfSection71> from [1]):
> <FranksVersion3OfSection71>
> The Body of a SOAP RPC message MUST contain one and only one serialization
> root. In the case of a request message, this root is the request element.
In
> the case of a response message, this root is EITHER a response element OR
a
> Fault element.
> 
> In the case of an RPC with a void return type and no [out] or [in,out]
> parameters, the response element MUST be empty.
> </FranksVersion3OfSection71>
> 
> Proposed rewriting that corresponds to P2:
> <FranksVersion4OfSection71>
> The Body of a SOAP RPC message MUST contain one serialization root and MAY
> contain more. In the case of a request message, each root is a request
> element. In the case of a response message, each root is EITHER a response
> element OR a
> Fault element.
> 
> In the case of an RPC with a void return type and no [out] or [in,out]
> parameters, the response element MUST be empty.
> </FranksVersion4OfSection71>
> 
> It should be obvious by now that personally I would prefer
> <FranksVersion3OfSection71>.
> 
> If you've got suggested rewrites, please lay your ass on the line. ;>)
Just
> identify your rewrite (like <FranksVersion3OfSection71>), so we can refer
to
> it easily.
> 
> F
> 
> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jun/0160.html

Received on Monday, 18 June 2001 11:02:01 UTC