RE: RPCTF: Issues 16 and 78

Comments inline.

F

> -----Original Message-----
> From: Jacek Kopecky [mailto:jacek@idoox.com]
> Sent: Wednesday, July 25, 2001 10:50 AM
> To: Frank DeRose
> Cc: christopher ferris; xml-dist-app@w3.org
> Subject: 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.
>
This sounds like a good change to make. I'll put it in the next version of
the proposal after I get more feedback from people.

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

Yes, it is a problem that the root attribute is in the SOAP encoding
namespace. This is one of those dependencies that Section 7 has on Section
5. Let's talk about this some more in the RPCTF and possibly come up with an
alternative wording. Simply substituting the word "element" for
"serialization root" might be sufficient.

>  > 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 15:26:26 UTC