Re: New issues with #195 and section 3.1.5.3

 Robert,
 as for the first issue, as Ray correctly pointed out, the
rpc:result boolean attribute is not a possible solution because
there is no place for such an attribute in the data model. The
other solution - removing the notion of a return value (and
letting applications deal with it as they can) was already
suggested when issue 195 was discussed and the suggestion was not
accepted at that time.
 On whether array items can be named differently, see the issue 
231. There are differing views out there.
 Anyway, I agree rpc:result (of type QName) naming the return
value accessor is an overly complex solution for the problem, and
I think it was accepted for the wrong reason (XML Schema
usability). See Systinet's LC comments. [1]

 As for the second issue, the explanation of the status quo is as
follows: in the data model, edges are not nodes. Therefore, a
reference is not a first-class value (same as in Java, for
example, and different from C/C++) and a reference cannot itself
be referenced. Only values can be referenced. My opinion is that
this is the better - simpler, cleaner and less confusing -
approach to references in a (mostly) RPC data model.

 Best regards, 

                   Jacek Kopecky

                   Senior Architect, Systinet Corporation
                   http://www.systinet.com/

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



On Mon, 15 Jul 2002, Robert van Engelen wrote:

 > 
 > 
 > 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 Sunday, 21 July 2002 21:17:45 UTC