RE: issue 78

I think we've gotten off track here. The original focus of issue 78 was not
"boxcarring." The full range of questions wrt issue 78 is:

1.) What is the meaning of Section 5.6 of SOAP 1.1?
2.) Does the proposed rewriting [1] of Section 5.6 capture that meaning?
3.) Does the proposed rewriting define the SOAP-ENC:root attribute in such a
way that it can used to distinguish a "serialization root" from multi-ref
elements in the Body (or Header, for that matter) of an RPC message?
4.) Does the last sentence of Section 7.1 need to be rewritten [2] in light
of the rewriting of Section 5.6?
5.) What combinations of serialization roots and multi-ref elements does
SOAP 1.1 authorize in the Body of a message? For example, can there be
multiple serialization roots (enabling boxcarring through multiple RPC calls
in one Body)?

I would like to point out some other resources related to Section 5.6 of
SOAP 1.1:

1.) A recent thread [3] on the soapbuilders mailing list related to the
SOAP-ENC:root attribute. I think it's safe to say that the messages in this
thread indicate a substantial degree of uncertainty over how Section 5.6 is
to be interpreted/implemented.
2.) Section 6 of BizTalk Framework 2.0 [4].
3.) An early email from Keith Brown [5]. This is probably the best place to
get information about how the original SOAP authors intended the root
attribute to be used. This email may actually be the key to clearing up all
the confusion about Section 5.6.

F

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jun/0110.html
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jun/0164.html
[3] http://groups.yahoo.com/group/soapbuilders/message/3795
[4] http://www.microsoft.com/biztalk/techinfo/BizTalkFramework20.doc
[5]
http://discuss.develop.com/archives/wa.exe?A2=ind0008&L=SOAP&P=R20591&m=3666

> -----Original Message-----
> From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
> Behalf Of Doug Davis
> Sent: Monday, June 18, 2001 8:37 AM
> To: Frank DeRose
> Cc: Jean-Jacques Moreau; xml-dist-app@w3.org
> Subject: RE: issue 78
>
>
> I'm just wondering what's wrong with saying that the spec
> isn't going to solve this issue and will leave it up to the
> specific implementations to deal with?  The obvious answer
> is that we need a common definition to be able to know how
> to talk to one another, but that really is no different than
> how we solve serialization.  The spec just happens to
> show "one" way to serialize but you can define others.
> I see boxcarring as the same thing.  If you like one approach
> then use it, and propose it as a standard.  Much like
> SOAP w/Attachments is just one way to solve a problem.
> I tend to like the idea of building on top of the SOAP
> spec with more specs rather than having an ever growing
> single spec.
> -Dug
>
>
> "Frank DeRose" <frankd@tibco.com>@w3.org on 06/15/2001 11:58:53 PM
>
> Sent by:  xml-dist-app-request@w3.org
>
>
> To:   Doug Davis/Raleigh/IBM@IBMUS
> cc:   "Jean-Jacques Moreau" <moreau@crf.canon.fr>, <xml-dist-app@w3.org>
> Subject:  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
>
> 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 Tuesday, 19 June 2001 16:54:12 UTC