W3C home > Mailing lists > Public > xml-dist-app@w3.org > April 2002

Re: Issue 195: soap-rpc:result

From: Noah Mendelsohn/Cambridge/IBM <noah_mendelsohn@us.ibm.com>
Date: Mon, 8 Apr 2002 14:11:50 -0400
To: rayw@netscape.com (Ray Whitmer)
Cc: jacek@systinet.com, Herve Ruellan <ruellan@crf.canon.fr>, "Sanjiva_Weerawarana/Watson/IBM%IBMUS" <sanjiva@us.ibm.com>, tjewald@develop.com, xml-dist-app@w3.org
Message-ID: <OF65BF5772.89D766E5-ON85256B95.0063663C@lotus.com>

I probably came on a bit too strong in the note that you quote.  I think 
the use of schema in WSDL to describe encoded graphs involves some 
unfortunate compromises, and  I think that the WSDL group should take a 
hard look at these issues.  That said, I think that existing experience 
with WSDL shows that conventions can be developed to promote a substantial 
degree of interoperability based on current WSDL technology and SOAP graph 

The decision tree that I suggest we follow is this: 

* If SOAP indeed requires a fairly general graph encoding that can model 
traditional programming language data structures, then I think the one we 
have is reasonable.  I'm not sure there is any other graph encoding we 
would propose that would be more schema friendly.  On the contrary, I 
believe ours works particularly well with schema. The other way to go 
would be to drop the SOAP graph encoding entirely, and use an XML-tree 
representation for RPC arguments.  This would support only a subset of the 
RPC's that we can do today, but would model more directly in XML schema of 
course.  On the other hand, I'm not at all sure this would meet the 
expectations of the SOAP community, and I believe we have a specific 
requirement in our charter, which calls for: "A mechanism for serializing 
data representing non-syntactic data models such as object graphs and 
directed labeled graphs, based on the datatypes of XML Schema." [1]

* Presuming that we do want to keep a graph model, then the burden then 
falls on the WSDL group to decide what modeling technology to use for 
interface contracts.  As I say, what they have works moderately well for 
many common cases. 

So, I apologize for having been a bit too extreme in my earlier analysis. 
I do think there are some issues, but on balance I am not prepared to 
recommend at this point that protocols workgroup abandon the current graph 
encoding.  Thank you.

[1] http://www.w3.org/2000/09/XML-Protocol-Charter#scope

Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142

rayw@netscape.com (Ray Whitmer)
04/08/2002 01:29 PM

        To:     Noah Mendelsohn/Cambridge/IBM <noah_mendelsohn@us.ibm.com>
        cc:     Herve Ruellan <ruellan@crf.canon.fr>, jacek@systinet.com, 
tjewald@develop.com, xml-dist-app@w3.org, 
"Sanjiva_Weerawarana/Watson/IBM%IBMUS" <sanjiva@us.ibm.com>
        Subject:        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 

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 represe
(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
Received on Monday, 8 April 2002 14:29:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:19 UTC