RE: RPCTF: Issues 16 and 78

 Frank,
 I like what you're attempting to do here. 8-)
 I'm against boxcarring. 8-)
 See more of my comments inside.

                            Jacek Kopecky

                            Idoox
                            http://www.idoox.com/




On Tue, 24 Jul 2001, Frank DeRose wrote:

 > 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.

I would change the fault part here to  "or a SOAP Fault message
resulting from an RPC fault." Your original wording may suggest
that you want to call every fault message an RPC message.

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

I don't like the use of the term root here. Root is a
serialization-only thing, even the attribute (unqualified by the
spec) is usually in the SOAP encoding namespace. I'm going to
finish reading the discussion on issue 78 and then post a message
about the roots (if it hasn't been handled already which I don't
know yet.)

 > 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

Received on Wednesday, 25 July 2001 13:50:02 UTC