RE: Issue 16: methods with void return type and no out params

Yes. That was precisely one of the points I was trying to make with the
following sentence from my original post:

"Should methods with void return type always be handled in the same way or
should they be handled differently depending on different circumstances (for
example, whether the method does or does not have out parameters, or whether
items need to be returned in the header, or whether items besides the
response need to be returned inside the body)?"

If you have header items, then you need a payload. So, this would be yet
another form assumed by a SOAP RPC reply message for a method with a void
return value and no out parameters: you would have an envelope, a header,
and a (mandatory) (empty?) body.

F

> -----Original Message-----
> From: Mark A. Jones [mailto:jones@research.att.com]
> Sent: Friday, May 25, 2001 7:59 AM
> To: Frank DeRose
> Cc: xml-dist-app@w3.org
> Subject: Re: Issue 16: methods with void return type and no out params
>
>
> Frank,
>
> Isn't it possible that there will be intermediaries in the return path
> of a SOAP RPC call that may want to insert headers or otherwise process
> the return message?  If we don't always return a valid message, this
> would be a problem for behavior 1.
>
> Frank DeRose wrote:
>
> >  I have been asked by the WG to seed discussion on issue 16 from the
> > issues list [1].
> >
> > Bryan Murray, the author of  issue 16, asserts that Section 7.1 of the
> > SOAP spec [2] does not explicitly state how a method with a void
> > return type and no out parameters should be mapped onto the SOAP
> > protocol. Bryan conceives of four possible behaviors:
> >
> > 1.      return HTTP 204 No Response
> > 2.      return an empty SOAP Envelope
> > 3.      return an empty SOAP Body
> > 4.      return an empty SOAP method response
> >
>
> --
> Mark A. Jones
> AT&T Labs - Research
> Shannon Laboratory
> Room A201
> 180 Park Ave.
> Florham Park, NJ  07932-0971
>
> email: jones@research.att.com
> phone: (973) 360-8326
>   fax: (973) 360-8970
>
>
>

Received on Friday, 25 May 2001 14:56:36 UTC