W3C home > Mailing lists > Public > xml-dist-app@w3.org > April 2002

Re: Proposal for cleanup of RPC section (issue 195)

From: Jacek Kopecky <jacek@systinet.com>
Date: Mon, 8 Apr 2002 23:57:56 +0200 (CEST)
To: Noah Mendelsohn/Cambridge/IBM <noah_mendelsohn@us.ibm.com>
cc: xml-dist-app@w3.org
Message-ID: <Pine.LNX.4.44.0204082350420.12891-100000@mail.idoox.com>
 it is impossible to omit some members in an array. Therefore, if 
the first member is meant to be the return value (and we know 
that from the signature), it will always be there, even if null 
(marked with xsi:null="true"). If the text needs some rewording 
to show that, I won't object to it. 8-)

 Anyway, the quoted text will be gone if we accept my full
proposal.  8-)

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)

On Mon, 8 Apr 2002, Noah Mendelsohn/Cambridge/IBM wrote:

 > Jacek Kopecky writes:
 > >> * In the array representation of the response, 
 > >> the return value outbound edge is the first 
 > >> member of the array 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, therefore the first edge 
 > >> is the first [out] or [in/out] parameter.
 > Is it intentional that when modeling a function with positional [out] 
 > arguments, we cannot reliably determine whether the return value is void 
 > unless we have external knowledge of the method signature and the number 
 > of arguments expected?  For a function taking a variable number of 
 > arguments, it would seem to be impossible to determine in general whether 
 > the return value was void.
 > ------------------------------------------------------------------
 > Noah Mendelsohn                              Voice: 1-617-693-4036
 > IBM Corporation                                Fax: 1-617-693-8676
 > One Rogers Street
 > Cambridge, MA 02142
 > ------------------------------------------------------------------
Received on Monday, 8 April 2002 17:57:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:19 UTC