New issues with #195 and section 3.1.5.3

Hi,

After reviewing the SOAP 1.2. spec, I found two issues that IMO may need
further clarification. Testing with our prototype SOAP 1.2. implementation
in gSOAP made these issues even more compelling. Especially #195 which
appears to be in conflict with the encoding rules for structs and arrays.

- Robert van Engelen, FSU.

Comments on "SOAP Version 1.2 Part 2: Adjuncts"
===============================================

OBSERVATION (see also issue #195):

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.

QUOTE:

4.2.2 RPC Response
...
* If the response is represented by an array, each outbound edge has a label
  corresponding to the position of the parameter. A return value MUST be present
  if the return value of the procedure is non-void. If present, the return value
  MUST be represented as the first edge of the array with parameters following.
  If no return value is present, then parameters begin with the first outbound
  edge of the array.

REASON:

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.

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>

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.

SOLUTION:

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.
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.

OBSERVATION:

The limitations on id ref combinations described in 3.1.5.3 are too limiting
for certain realistic graph data models.

QUOTE:

3.1.5.3 Constraints on id and ref attribute information items
The value of a ref attribute information item MUST also be the value of
exactly one id attribute information item.  A ref attribute information item
and an id attribute information item MUST NOT appear on the same element
information item. 

REASON:

This constraint limits the applicability of SOAP RPC to systems with simple
graph data models that do not exhibit pointer chains, i.e. graph data models
that do not allow pointers to pointers.

EXAMPLE:

For example, consider a struct A with a reference field to a node that
contains a sole reference to a node with value D. Both nodes pointed to are
"multi-referenced" (have indegree > 1)

                      |                |
 __________           |                |
| Struct A |      ____V_____        ___V_____
| ref B ---+---->| ref C ---+----->| value D |
| ...      |     |__________|      |_________|
|__________|

A natural data-layout-preserving XML representation would be

<A>
 <B ref="id2"/>
 ...
</A>
...
<C id="id2" ref="id3"/>
...
<D id="id3">value</D>
 
This representation is illegal according to 3.1.5.3 but accurately
characterizes the graph depicted above.

Received on Monday, 15 July 2002 22:26:29 UTC