Re: New issues with #195 and section 3.1.5.3

These are my own thoughts on this issue.

Robert van Engelen wrote:

>The RPC response encoding rules may conflict with the encoding rules for
>arrays. As a result, the specification of the SOAP encoding rules are
>inconsistent.
>  
>
IMO, The rules for encoding as an array or struct were never intended to 
be very consistent.  An application must know whether the call or return 
in question is to be encoded as an array or an RPC.  If it does not, 
there are more things than this that break down.  Position is irrelevant 
as a struct, and programs that rely on the position of an argument, when 
the encoder encoded it as a struct, will be disappointed.  Likewise, 
names are irrelevant (from an accessor point of view) if it is an array, 
so trying to use them to identify if it is an array is wrong.

I know of no way, other than external schemas, WSDL, etc. known to both 
parties to know which it is.

>Because the arraySize and itemType attributes are optional (3.1.3), empty
>structs/arrays and structs/arrays with one outbound edge are indistinguishable.
>As a consequence, the use of an rpc:result outbound edge is ambiguous for
>structs/arrays with one outbound edge and encoding conflicts may arise.
>  
>
The array need not be size 0 or 1, but those are certainly the most 
obvious examples.

Furthermore, you do not even know with any certainty the encoding of the 
RPC call, so it is really up to the application to know all these things.

>EXAMPLE:
>
>If an array contains one outbound edge and this edge is a non-void return value
>and the arraySize and itemType are absent, then the resulting encoding may be
>similar to a struct:
>
><A>
> <rpc:result>B</rpc:result>
> <B></B>
></A>
>  
>
I do not believe that this is correct encoding for an array.  This might 
be a struct encoding.

>However, only one outbound edge of the array can occur in the array encoding.
>The representation
>
><A>
> <B></B>
></A>
>
>would be a viable alternative, now assuming that <A> is an array. Note the
>absence of the rpc:result edge in this case. The return value information is
>lost when decoded as a struct.
>  
>
This is only proper encoding for an array.  It can be one or the other, 
but not both.

>SOLUTION:
>  
>
I am not sure what we are "solving".  If we want a single structure that 
could be interpreted similar to an array or similar to a struct, then 
that would be a generic compound type, but that is not a legal way to 
encode the RPC call in SOAP 1.2.

>1. Eliminate the notion of a return value alltogether. There is no compelling
>   need for modeling return values as a separate entity next to out and in/out
>   parameters. The use of a return value is not orthogonal to to the use of
>   out parameters.
>
One argument for this is that in the array case, you cannot distinguish 
the return anyway so why should you be able to do it in a struct.

>2. Use of an rpc:result attribute in an outbound edge of a non-void return
>   value.
>   For example
>   <A>
>    <B rpc:result="1"></B>
>   </A>
>   This does not conflict with the encoding rules for structs and arrays.
>
I believe that it does conflict.  With the SOAP encoding, no additional 
attributes are permitted.  You can have a few specific attributes and no 
others.  When you access these values as part of the data graph, there 
would be no place for the result attribute to be attached.  With SOAP 
1.2, the RPC call has literally become a struct or an array in that data 
graph, and may be encoded/decoded using completely-foreign encodings of 
the same data graph -- a struct or an array representing the call.  What 
would happen to this homeless attribute in other encodings?  It has to 
be part of the data graph, IMO, to work, not just tagged on to the 
syntactical representation.

Ray Whitmer
rayw@netscape.com

Received on Tuesday, 16 July 2002 14:48:44 UTC