RE: issue 78

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 11:46:39 UTC