RE: RPCTF: Issues 16 and 78

Chris,

I think your rewording is a definite improvement. Actually, I think we need
to tighten up the terminology even more.

Here is a proposal for adding RPC terms to the glossary so that they can be
used unambiguously in Section 7 (see [1] for an earlier version of this
proposal).

[Please forgive my seemingly pretentious use of elements like
<FranksVersion2OfRPCTerms>. I'm trying to make it possible for us to refer
to proposed rewrites unambiguously.]

<FranksVersion2OfRPCTerms>
RPC message: a SOAP message (SOAP Envelope) containing an RPC request
element, an RPC response element, or a fault element in its Body.

RPC request message: a SOAP message (SOAP Envelope) containing an RPC
request element in its Body.

RPC request element: inside the Body of an RPC request message the
serialization root that represents the [in] part of the RPC.

RPC response message: a SOAP message (SOAP envelope) containing an RPC
response element or fault element in its Body.

RPC response element: inside the Body of an RPC response message the
serialization root that represents the [out] part of the RPC or the fault
generated by the RPC.
</FranksVersion2OfRPCTerms>

Note that these definitions would need to be rewritten if we decide to allow
boxcarring (see below).

Below are my most current attempts at rewriting the last paragraph of
Section 7.1. <FranksVersion5OfSection71> prohibits boxcarring.
<FranksVersion6OfSection71> allows boxcarring. For more discussion (and
earlier versions) of these two alternatives see [2].

<FranksVersion5OfSection71>
The Body of an RPC message MUST contain one and only one serialization root.
In the case of an RPC request message, this root is the RPC request element.
In the case of an RPC response message, this root is EITHER an RPC 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 RPC response element MUST be empty.
</FranksVersion5OfSection71>

<FranksVersion6OfSection71>
The Body of an RPC message MUST contain one serialization root and MAY
contain more. In the case of an RPC request message, each root is an RPC
request element. In the case of an RPC response message, each root is EITHER
an RPC 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 RPC response element MUST be empty.
</FranksVersion6OfSection71>

F

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jun/0160.html
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jun/0164.html

> -----Original Message-----
> From: Chris.Ferris@Sun.COM [mailto:Chris.Ferris@Sun.COM]On Behalf Of
> christopher ferris
> Sent: Tuesday, July 24, 2001 12:26 PM
> To: Frank DeRose
> Cc: xml-dist-app@w3.org
> Subject: Re: RPCTF: Issues 16 and 78
>
>
> Frank,
>
> w/r/t issue 16, I think that the proposed rewording needs to be
> tightened up.
>
> I would therefore offer a friendly amendment to your proposed
> resolution. I suggest that:
>
> ?A SOAP RPC reply message MUST contain either a response or a fault in the
> body. A SOAP RPC reply message MUST NOT contain both a response
> and a fault
> in the body. In the case of a method with a void return type and
> no [out] or
> [in,out] parameters, the response MUST be empty.?
>
> should be rephrased as follows:
>
> ?A SOAP RPC reply message MUST contain either a response or a fault in the
> body. A SOAP RPC reply message MUST NOT contain both a response
> and a fault
> in the body. In the case of a method with a void return type and
> no [out] or
> [in,out] parameters, the response body MUST be empty.?
> 				  ^^^^
>
> Cheers,
>
> Chris
>
>
> Frank DeRose wrote:
> >
> > Issues 16 and 78 were scheduled for discussion at the last face-to-face
> > meeting of the WG, but this discussion was postponed due to lengthy
> > discussion of more pressing issues. The RPC Task Force (RPCTF)
> is currently
> > reviewing these issues and would like input from the SOAP
> community. Please
> > review the discussion of issue 16 [1] and issue 78 [2] and provide any
> > further feedback to the RPCTF. Thanks.
> >
> > Frank DeRose
> > TIBCO Software Inc.
> > 3165 Porter Dr
> > Palo Alto, CA 94303
> > 650-846-5570 (vox)
> > 650-846-1267 (fax)
> > frankd@tibco.com
> > www.tibco.com
> >
> > [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0328.html
> > [2] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jun/0110.html

Received on Tuesday, 24 July 2001 16:33:49 UTC