These are the minutes for the RPCTF conference call on 8/24/2001.

We reviewed the status of the following two action items:

Action Item 1: rpc:result
Jacek sent out a proposal for an rpc:result element (see [1], [2]). The
proposal is to introduce a "result" element in the (to be defined) rpc
namespace to represent the return value of an RPC call.

According to the proposal, the response element (the struct that contains
the return value and all the [out] parameters) for an RPC, would be
constructed according to the following rules:

if the return type of the procedure is nonvoid
  if the return value of the procedure is nonnull
    rpc:result is present with nonempty content
  else // the return value of the procedure is null
    Alternative 1: rpc:result is present, with empty content, and with the
xsi:nill attribute
    Alternative 2: rpc:result is omitted
else // the return type of the procedure is void
  rpc:result is omitted

Frank collected feedback on this proposal from the various mailing lists.

The first strand of feedback came from Stefan Haustein [3] who objected to
making the result element namespace qualified. The task force decided that
this was not a legitimate objection since namespace qualification is
required by SOAP as a whole.

The second strand of feedback came from Elke Meier [4] and Graham Glass
[5],
who expressed a strong preference for dropping Alternative 2. [I share
their
view.] This would require that we drop Section 5, Item 9 of the SOAP spec.
Andrew Layman weighed in [6] with arguments for keeping Alternative 2 and
Section 5, Item 9 intact. The RPCTF decided there was no good reason for
dropping Alternative 2 and resolved to present Jacek's proposal at the f2f
exactly as originally written with the recommendation of keeping both
Alternative 1 and Alternative 2. The proposal will be divided into two
questions, however:

1.) Should we create an rpc namespace with an rpc:result element? Are there
other suggestions for the name of the element?
2.) Should we keep both Alternative 1 and 2, or just Alternative 1?

Action Item 2: Relationship of Section 5 to Section 7
Henrik had an action item from the previous RPCTF confcall to attempt to
redraft Section 5 so that a distinction was made between the data model and
the representation/serialization/encoding. It was hoped that this would
eliminate the dependencies that Section 7 has on Section 5. Henrik had not
yet generated a draft. Frank was given an action item to ping Henrik.

New Action Items
We set the following action item for Frank.

Generate an agenda of RPC-related issues to be discussed at the f2f.
Currently, this agenda consists of the following items:

1.) rpc:result
2.) RPC result/fault codes
3.) relationship of Section 5 to Section 7
4.) rewriting Section 7 in terms of infoset (new item)

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Aug/0170.html
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2001Aug/0197.html
[3] http://lists.w3.org/Archives/Public/xml-dist-app/2001Aug/0180.html
[4] http://lists.w3.org/Archives/Public/xml-dist-app/2001Aug/0178.html
[5] http://lists.w3.org/Archives/Public/xml-dist-app/2001Aug/0179.html
[6] http://lists.w3.org/Archives/Public/xml-dist-app/2001Aug/0201.html