RE: WSDL 1.2 drops use="encoded"

Don Box writes:

>> That statement is not accurate. At all.
>> 
>> DB
>> 
>> 
>> > -----Original Message-----
>> > From: Rich Salz [mailto:rsalz@datapower.com]
>> > Sent: Tuesday, February 25, 2003 9:20 PM
>> > To: Jonathan Marsh
>> > Cc: xml-dist-app@w3.org
>> > 
>> > 
>> > Just to make sure I understand, is the following statement accurate:
>> >    WSDL 1.2 cannot describe SOAP 1.1 "section 5" messages
>> >    (and therefore presumably "RPC encoding" of SOAP 1.2)
>> > 
>> > 

Don,

With respect, I think that the statement is in certain respects valid 
(though as I make clear at the end of this note I am in favor of the 
proposed changes to WSDL).  I believe that the following is a more 
accurate statement than the formulation Rich offers:

"You can write XML schemas, and hence WSDL 1.2, that will validate some or 
all of the representations of any given SOAP 1.2 data model graph.  On the 
other hand, there are many potentially important graph constraints and 
equivalence classes that XML schema cannot effectively model.  WSDL no 
longer attempts to use (bindings to) XML Schema to model such graph 
constraints (and in that sense Rich is right)."

Here's why I believe this:

IMO systems like RMI and presumably SOAP got into the business of graph 
encodings because certain programming data structures you may wish to 
transmit are cyclic  or otherwise non-tree-like.   For example, let me 
describe a perfectly useful contract that we might wish to agree on for an 
encoded Web service.  Because WSDL and schema can't accurately model this 
constraint, I will describe it to you in English (as I would on the phone 
if I were trying to help you connect to my service):

===========Interface definition================

*  I have a data structure which is in all cases a circularly linked list 
of items.  Using SOAP 1.2 data model, the edge names are all n:node, where 
n is bound to my namespace.

* You may invoke my method "insert" passing in to me an argument which 
must be one of the nodes in that circular structure, and one other 
argument, which must not be in the cycle.  I will return to you a similar 
cyclic structure.

Note that this is not a particularly unusual method signature, at least 
for local methods.  It would be an exact match to:

        Node insert(Node cycle, Node newNode);  //returns updated cycle

The intended validation when you receive a message from me is: 
a) follow the edges from the first element I've sent graph that I've sent 
you (which in SOAP encoding can be represented as element children or 
multi-ref targets) and make sure that every node appears in the same 
cycle, and that the cycle closes. 
b) make sure that the second argument is NOT in the cycle.
========================================

Keep in mind that the following encode identical soap graphs (Three nodes 
in a cycle forming the first RPC argument, plus one free standing second 
argument):

<s:Body>
  <insert xmlns:n="...">
   <!-- ------------------------------------
    arg 1 (the cycle):
    represent most edges as children
    ------------------------------------ ->
    <node soapEnc:id="closeCycle">
     <value>1< /value>
        <link>
       <node>
        <value>2< /value>
        <link>
         <node>
          <value>3< /value>
          <link soapEnc:ref="closeCycle"/>
         </node>
          </link>
       </node>
        </link>
    </node>
   <!-- ------------------------------------
    arg 2 (the new node)
    ------------------------------------ ->
    <node>
        <value>100<</value>
        <link xsi:nil="true">
    </node>
  </insert>
</s:body>

<s:Body>
  <insert xmlns:n="...">
   <!-- ------------------------------------
    arg 1 (the cycle):
    represent all edges with id/ref
    ------------------------------------ ->
    <node soapEnc:id="node1">
     <value>1< /value>
     <link soapEnc:ref="node2"/>
    </node>
   <!-- ------------------------------------
    arg 2 (the new node)
    ------------------------------------ ->
    <node>
        <value>100<</value>
        <link xsi:nil="true">
    </node>
  </insert>

  <!-- ------------------------------------
   multiref targets
    ------------------------------------ ->
  <node soapEnc:id="node2">
   <value>2< /value>
   <link soapEnc:ref="node3"/>
  </node>
  <node soapEnc:id="node3">
   <value>3< /value>
   <link soapEnc:ref="node1"/>
  </node>
</s:body>

These two examples represent the SAME soap encoding graph.  I claim it's 
extremely hard to write a useful schema that accepts all reasonable 
variations along these lines, but rejects representations that conflict 
with my English description of the constraints.

That said:  I think the proposed restrictions on WSDL are spot on, and 
long overdue.  WSDL never should have tried to model graphs with Schema. 
The situation we have with the new WSDL proposal is, I believe:

* You can use WSDL and schema to do strong validation of literal content.

* You can use WSDL and schema to do validation of encoded content in the 
common case where the graph is in fact a tree (as opposed to DAGs, cycles, 
whatever.)

* You can use SOAP encoding for the more complex structures, which are 
self-describing when the message is received (you can easily decode the 
cycles above), but we do not have a graph description language to define 
equivalence classes of, for example, representations of cycles.

As I say, I think this is a good state of affairs.  Web Services are about 
loose coupling, IMO, and I think that DAGs, cycles, etc. don't make the 
80/20 cut in trying to model loosely coupled web services.  Many, many 
documents (Purchase Orders) and method invocations will be hierarchical or 
near hierarchical.  Thank you!
 
------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Tuesday, 4 March 2003 11:38:36 UTC