Rewording of section 4.1.2 based upon resolution of issue 195

Sorry for the delay, I had a hard time reconciling recent drafts with 
decisions I remembered, and various lists archives were down.  I list 
the most recent wording from an editors draft, but even Jacek's proposal 
is based upon previous work with several more bullet items.  Forgetting 
about disorientation in the current drafts, and possibly missing some 
points because the list archives were down more than up, what follows is 
a before and after wording.

Please note that in the new wording, I have included in [] extra 
sentences that contain clarifications that were only briefly mentioned 
but I think might be useful.  I will leave it up to the editors whether 
the extra sentences should be included or not, but if anyone thinks the 
sentences are not true, we should probably discuss them, because it was 
not clear to me why we spent so much time making it possible to identify 
non-void returns in structs when other gaping holes were left up to the 
knowledge of the calling application of the call signature.


        Old wording in latest editor's draft:


        4.1.2 RPC Response

An RPC response is modeled as a struct where parameter access is by name 
or as an array where parameter access is by position.

    *

      The response is represented by a single struct or array containing
      an outbound edge for the return value and each [out] or [in/out]
      parameter. The return value outbound edge SHOULD be the first
      outbound edge.

    *

      Each outbound edge has a label corresponding to the name of the
      parameter (see A. Mapping Application Defined Names to XML Names
      <http://www.w3.org/2000/xp/Group/2/05/14/soap12-part2-1.93.html#namemap>
      ) or a position corresponding to the position of the parameter.
      The label of the return value outbound edge is "result" and it is
      namespace-qualified with the namespace name
      "http://www.w3.org/2001/12/soap-rpc". The return value outbound
      edge MUST be present if the return value of the procedure is
      non-void. The return value outbound edge MUST NOT be present if
      the return value of the procedure is void.

    *

      Invocation faults are handled according to the rules in 4.3 RPC
      Faults
      <http://www.w3.org/2000/xp/Group/2/05/14/soap12-part2-1.93.html#rpcfaults>
      . If a protocol binding adds additional rules for fault
      expression, those MUST also be followed.

An RPC response MUST NOT contain both a result and a fault, because a 
result indicates success and a fault indicates failure.

New wording:

An RPC response is modeled as a struct where parameter access is by name 
or as an array where parameter access is by position. [The  SOAP 
encoding specification defines no way to directly determine whether the 
response is modeled as a struct or as an array.]

    *

      The response is represented by a single struct or array containing
      an outbound edge for the return value and each [out] or [in/out]
      parameter.

    *

      If the response is represented by a struct, then each parameter is
      represented by an outbound edge with a label corresponding to the
      name of the parameter (see A. Mapping Application Defined Names to
      XML Names
      <http://www.w3.org/2000/xp/Group/2/05/14/soap12-part2-1.93.html#namemap>
      ).  A non-void return value is represented in the struct by an
      outbound edge that may be given any unique label.  The qname
      (qualified name) of the label of the edge representing the return
      value is given by a separate outbound edge with the label "result"
      and the namespace name "http://www.w3.org/2001/12/soap-rpc". This
      result outbound edge MUST be present and hold the qname of the
      edge containing the return value within any struct response if the
      return value of the procedure is non-void.  This result outbound
      edge MUST NOT be present if the return value of the procedure is void.

    * If the response is represented by an array, each outbound edge has
      a label corresponding to the position of the parameter.  A return
      value MUST be present if and only if the return value of the
      procedure is non-void.  If present, the return value MUST be
      represented as the first edge of the array and parameters, if any,
      begin with the second outbound edge of the array.  If no return
      value is present, then parameters, if any, begin with the first
      outbound edge of the array.  [The SOAP encoding specification
      defines no way to directly determine whether the first edge of a
      non-empty response array is a return value or whether it is the
      first parameter of a procedure with a void return.]

    *

      Invocation faults are handled according to the rules in 4.3 RPC
      Faults
      <http://www.w3.org/2000/xp/Group/2/05/14/soap12-part2-1.93.html#rpcfaults>
      . If a protocol binding adds additional rules for fault
      expression, those MUST also be followed.

An RPC response MUST NOT contain both a result and a fault, because a 
result indicates success and a fault indicates failure.

Thanks,

Ray Whitmer
rayw@netscape.com