I strongly support Marc's proposal which seems very consistent with the
general rules for encoding a response - from 7.1:
* A method response is modelled as a struct.
* The method response is viewed as a single struct
containing an accessor for the return value and each
[out] or [in/out] parameter. The first accessor is
the return value followed by the parameters in the
same order as in the method signature.
* Each parameter accessor has a name corresponding
to the name of the parameter and type corresponding
to the type of the parameter. The name of the return
value accessor is not significant. Likewise, the
name of the struct is not significant. However, a
convention is to name it after the method name
with the string "Response" appended.
A logical conclusion of this is that *if* there are no [out] or [in,out]
parameters then the struct is empty. That is, the body contains a
single, empty response element whose name is not significant but may
follow the "Response" naming convention like for example:
<S:Envelope xmlns:S='http://www.w3.org/2001/06/soap-envelope'>
<S:Body>
<F:fooResponse xmlns:F="http://entry-name-space"/>
</S:Body>
</S:Envelope>
Henrik
>Or to put it another way, I think we should say:
>
>(from [2])
>"In the case of an RPC with a void return type and no [out] or
>[in,out] parameters, the response element MUST be empty."
>
>rather than:
>
>(from [1])
>"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."