Re: issue 78

<em>+1</em>

;-)

Henrik Frystyk Nielsen wrote:
> 
> 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."

Received on Wednesday, 20 June 2001 12:43:18 UTC