RE: issue 78

The reason for the last paragraph was issue 16. See my original proposed
rewrite of Section 7.1 [1] and Henrik's objections [2]. What I was trying to
do in the last paragraph of <ProposedRewriteOfSection71> was come up with a
compromise between my original rewrite and Henrik's objections.

So, actually my personal position agrees with that of Chris, Bob, and Simon:
I would very much prefer to omit the last paragraph entirely (or at least
most of it). So, here's version 2 of the proposed rewrite of Section 7.1:

<Version2OfProposedRewriteOfSection71>
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 a method with a void return type and no [out] or [in,out]
parameters, the response MUST be empty.
</Version2OfProposedRewriteOfSection71>

In other words, keep just the first part of the first sentence of the last
paragraph. Now, I know some people will say we should drop even that. But
the absence of any explicit instructions on how to handle methods with void
return type and no [out] or [in,out] parameters was what originally
precipitated issue 16.

As a side note, I think we need to define terminology in Sections 7 and 7.1
better. These sections are for the most part consistent in their use of the
term "invocation" to refer to the serialization root inside the Body that
contains the [in] parameters and of the term "response" to refer to the
serialization root inside the Body that contains the [out] parameters. But,
you also have sentences like:

"Because a result indicates success and a fault indicates failure, it is an
error for an RPC response to contain both a result and a fault."

where the terminology seems confused. ("result" has not been defined. Also,
if an "RPC response" is the response struct (yet another term for the same
thing), how can it be said to contain a "result" or a "fault?) As my rewrite
suggests, I would like to define the following terms:

RPC request message (or, RPC invocation message): a message (envelope)
containing an RPC request element in its Body.

RPC request element (or, RPC invocation element): inside the Body of an RPC
request message the serialization root that represents the [in] part of the
RPC.

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

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

F

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0328.html
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0340.html

> -----Original Message-----
> From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
> Behalf Of christopher ferris
> Sent: Friday, June 15, 2001 10:04 AM
> To: Bob Cunnings
> Cc: xml-dist-app@w3.org
> Subject: Re: issue 78
>
>
> +1
>
> Bob Cunnings wrote:
> >
> > Hello,
> >
> > I agree with Simon... I don't see any benefit in omitting the
> > response element or the entire envelope. I do see a penalty in the
> > form of unnecessary complexity.
> >
> > RC
> >
> > > On Tue, 12 Jun 2001 15:08:29 -0700, in soap you wrote:
> > >
> > > >I've been asked by the WG to seed discussion on issue 78
> from the issues
> > > >list [1].
> > > >
> > > >The crux of issue 78 can be described as follows:
> > >
> > > looks good so far,
> > >
> > > ><ProposedRewriteOfSection71>
> > > >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 a method with a void return type and no [out]
> or [in,out]
> > > >parameters, the response element will be empty, in which
> case it MAY be
> > > >omitted. This will cause the Body to be empty. If the
> Envelope contains an
> > > >empty Body and does not contain a Header, the entire Envelope MAY be
> > > >omitted.
> > > ></ProposedRewriteOfSection71>
> > >
> > > What's the motivation behind the last paragraph, it appear to serve no
> > > purpose except to complicate matters.
> > >
> > > Thanks
> > > Simon
>
>

Received on Friday, 15 June 2001 18:53:21 UTC