Re: Issue 195: slightly updated simple proposal

 Ray,
 my proposal below resolves issue 195 saying that we don't think
mandating the full qualified name of the return value is a bad
idea. I don't think that the resolution must necessarily agree
with the issue originator.
 But there is still my other proposal (the full [1]) where I
suggest we remove the notion of return value altogether, moving
it into the application domain. I don't think I've heard many
opinions against it.
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Apr/0113.html


On Tue, 23 Apr 2002, Ray Whitmer wrote:

 > Since there has been apparently no more recent discussion, I will 
 > comment on this proposal.
 > 
 > This apparently does nothing whatsoever to resolve issue 195.  I find 
 > issue 195 to be a real concern.  I think it should be possible to use 
 > schema to accurately describe simple RPC calls.  If a struct has been 
 > chosen as the return vehicle, then if a fixed name with a fixed type is 
 > required, this is not possible.
 > 
 > There is nothing in the charter or in the requirements that lead me to 
 > believe that it is essential to know without knowing the method 
 > signature that a particular return value is a special unnamed return, 
 > which a language may or may not support.  There are so many other things 
 > that the binding is expected to understand or map arbitrarily, and SOAP 
 > 1.2 has made this worse by making both a struct and an array as options 
 > because now every language, whether it supports named or positional 
 > arguments has to support calls that will be of the other type just 
 > because someone decided they should be.
 > 
 > How about the following language instead:
 > 
 >  * In the struct representation of the response, the label of the
 > unnamed return value outbound edge is the one which does not
 > correspond to any of the named out or in/out parameters.
 > 
 > In most languages you have to know the names of the parameters anyway, 
 > so they can be associated with positions, since few languages associate 
 > by name.  This way, the result is given a meaningful name and type, 
 > which is good for a variety of reasons.  This is also no worse than the 
 > case of a returned array where you do not know whether or not there is a 
 > return value unless you know the signature and binding.
 > 
 > Ray Whitmer
 > rayw@netscape.com
 > 
 > 
 > Jacek Kopecky wrote:
 > 
 > > Hi all, 8-)
 > > this is the first part of my former proposal [1], updated a 
 > >little and standing on its own so it's not so confusing.
 > > In short, the update removes the mandatory presence or absence
 > >of the return value in the struct representation, it adds a note
 > >about the array representation, and it does some rephrasing in
 > >places.
 > > The proposal:
 > >
 > > It needs to be clarified that in the array representation of RPC
 > >result the return value is not named rpc:result (because as we
 > >cannot specify positions in structs, we cannot specify names in
 > >arrays). Therefore I propose the fifth bullet to be changed to:
 > >
 > > * The response is viewed as a single struct or array containing
 > >an outbound edge for the return value and each [out] or [in/out]
 > >parameter. If the response is an array, the return value edge
 > >MUST be the first edge in the array.
 > >
 > > And the sixth bullet in the RPC Body section - 4.1 [1] - should
 > >be split into:
 > >
 > > * Each outbound edge has a label corresponding to the name of
 > >the parameter (see A Mapping Application Defined Name to XML
 > >Name) or a position corresponding to the position of the
 > >parameter. 
 > >
 > > * In the struct representation of the response, the label of the
 > >return value outbound edge is "result" and it is
 > >namespace-qualified with the namespace name
 > >"http://www.w3.org/2001/12/soap-rpc".
 > >
 > > * 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. If the return value of the
 > >procedure is void, the first edge is the first [out] or [in/out]
 > >parameter.
 > > Note: in case the application designers only know the format of
 > >the messages, they are free to choose to treat the first out
 > >parameter as a return value or as the first out parameter.
 > >
 > > The note should probably go somewhere else than in the bullet, 
 > >but I don't know where, really.
 > >
 > >                   Jacek Kopecky
 > >
 > >                   Senior Architect, Systinet (formerly Idoox)
 > >                   http://www.systinet.com/
 > >
 > >
 > >
 > >[1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Apr/0113.html
 > >
 > >
 > 
 >

Received on Wednesday, 24 April 2002 05:44:37 UTC