Re: Issue 195: soap-rpc:result

Noah Mendelsohn/Cambridge/IBM wrote:

>Herve Ruellan writes:
>
>>>My short reply to your short answer is: XML 
>>>Schema is not suitable for describing data 
>>>in SOAP Data Model (or at least in SOAP Encoding), 
>>>but with a few tweaking, we should be able to used 
>>>XML Schema to describe data in SOAP Encoding for 
>>>RPC requests and responses.
>>>
>
>I respectfully disagree, unless you want to lock in to one of the many 
>legal serializations for each graph.  Note that the latest editors draft 
>of SOAP mandates that reeivers MUST accept any legal serialization of a 
>graph.
>
>The SOAP data model is a Directed Graph, is potentially cyclic, and is 
>only accidently tree-like in particular cases (which are admittedly 
>comon).   For example, I might imagine a program that uses a circularly 
>linked list as a datastructure.  None of the elements is a head or a tail, 
>just a cycle.  I might want to pass one or another member of the list as 
>an argument to an RPC, and pass the entire cycle by value.  SOAP RPC and 
>its encoding can do this trivially. 
>
>You can probably invent a schema that will match one or another, or even a 
>bunch of the legal encodings of your graph, but it's unlikely you'd write 
>a schema that matches even the majority of equivalent representations 
>(I.e. that represent the same graph.)    It only gets worse with more 
>complex structures.
>
>XML Schema is just that:  it's a schema language for XML.  I don't think 
>it is a good language for describing SOAP Data Model graphs, and I think 
>the fudging that goes on in WSDL to try to make it so is a mistake (my 
>opinion, not necessarily IBM's corporate position -- I haven't checked 
>with our WSDL reps on this lately.)  It would be quite reasonable to use 
>XML Schema to insist on one particular representation of a graph, then 
>everyone would have to use exactly that form when serializing.
>
To me, this is very different from what I thought I heard early on -- so 
different, that it is hard for me to understand the references to 
XMLSchema in the SOAP encoding, and so different that I cannot imagine 
that the SOAP encoding is ready for last call without having any real 
example of how to interoperate via some sort of contract.

As the Mozilla implementation of SOAP was being produced, WSDL with XML 
schema was the only thing seriously talked about to describe the 
contract.  So, we have made it work.  We look at the schema, look at the 
native data, cross our eyes a bit, and output the native data in a form 
that follows the XML schema following the rules of the SOAP encoding. 
 When it comes to arrays, we look for hints, as was described for WSDL 
in the schema in the default attribute value.  When it comes to cycles, 
we still haven't found a good way to implement them, so we will not be 
compliant, but I haven't encountered yet a valuable service that relied 
on them in SOAP -- not that such may not exist -- so we haven't solved 
that problem.  But we interoperate with every real service I have tried 
that follows the basic SOAP rules -- not that extensive testing has been 
done.  It doesn't seem too hard to contemplate what WSDL does -- 
describing the model using XML Schema.

If Schema really is not suitable for describing data in the SOAP data 
model, and cannot be made so by adopting a few extra rules for dealing 
with cycles and arrays, then I think this is a very significant problem 
with the spec as it exists today.  How can there even claim to be 
interoperating implementations if no language exists to describe the 
contract?  Do we need to adopt RDF instead as the primary encoding?

Is it possible to define a subset -- say without cycles -- and say that 
XMLSchema is suitable for that subset?

Ray Whitmer
rayw@netscape.com