Issue 25: SOAP 1.2 data model and WSDL

In today's conference call I took an AI to describe three options for dealing
with the SOAP 1.2 data model in WSDL.

Gudge described the issue (#25) in [1].

Essentially, the problem is that a SOAP 1.2 data model is a directed, labelled graph,
not an XML infoset, making the use of XML Schema to describe it quite adventurous.
Although that's what WSDL 1.1 did (of course with respect to SOAP 1.1 data models),
the approach used was not formally specified and resulted in several interoperability issues.

It seems inevitable that WSDL 1.2 will have to be able to describe SOAP 1.2 data
models and earlier today we identified three ways to do so:

1. Creating a SOAP Data Model type system

In this approach, we would come up with a new type system for describing
in unequivocal terms families of graphs built according to the SOAP 1.2 data
model rules. Of course, his type system would come with an XML-based
syntax, so that it can be used inside a WSDL document.

This approach was discussed in the XMLP working group. In [2], Jacek
provided an example of what the resulting syntax might look like. Here's an
excerpt:

     <struct name="person">
       <member name="name">
         <terminal xsdBase="xsd:string" />
       </member>
       <member name="address">
         <struct name="address" xsdBase="foo:addressType">
           <terminal name="street" xsdBase="xsd:string" />
           <terminal name="city" xsdBase="xsd:string" />
           <terminal name="country" xsdBase="xsd:string"/>
           <terminal name="zip" xsdBase="xsd:integer" />
         </struct>
       </member>
       <member name="children">
         <array dimensions="1">
           <struct ref="person"/>
         </array>
       </member>
     </struct>

Once this type system is in place, it can be used in conjunction with WSDL in a
way analogous to XML Schema, namely by putting graph type definitions inside
the <wsdl:types/> element.

This approach seems quite elegant, but it involves creating a new type system
from scratch. It does make it very clear that what's being described is a family
of graphs, not an infoset. At the same time, portTypes that used this type system
would be tied to SOAP, at least up to a point -- any protocol capable of carrying
SOAP-encoded graphs would do.

2. Using XML Schema to describe a SOAP data model

This approach is somewhat similar to #1 in that we'd formally define a language
to describe SOAP data models. The main difference is that its syntax would not
be brand new but would reuse XML Schema constructs as much as possible.
In other words, our working group would provide rules that can be used to
describe a SOAP data model using XML Schema.

This is more or less what's happening today with WSDL 1.1 and the SOAP 1.1
binding, but without the ambiguity.

One drawback is that using XML Schema to describe something which is not
an infoset can be construed as an abuse. In particular, these schemas could
not be used directly to validate a message or fragments thereof.

Another potential issue is that a schema created to describe a SOAP data model
would implicitely also describe an infoset, and it's unclear how the two would
be related. In particular, a type defined in such a schema could be also used
by an operation with a document/literal binding, causing the type to be reinterpreted
as a genuine XML Schema type.

3. Using XML Schema to describe an encoding of a SOAP data model

The third and last approach involves using XML Schema to describe not
a SOAP data model directly, but the result of encoding it using the rules for
SOAP 1.2 encoding.

This approach is used by some of the examples of the SOAP 1.1 specification ([3]),
for instance in section 5.4.1 ([4]), but to the best of my knowledge it hasn't been
used in actual WSDL documents.

One drawback of this approach is that aspects of the SOAP 1.2 encoding would
trickle into the abstract portion of a WSDL document, something we've been
trying to avoid in the past. It would also force many tools (for instance, stub
generators) to somehow reverse-engineer the given schema to filter out
the noise from the encoding and arrive at a pure data model.

So these are the options, now let's start the discussion!

Roberto

--- References ---

[1] http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0186.html
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2002Apr/0108.html
[3] http://www.w3.org/TR/SOAP/
[4] http://www.w3.org/TR/SOAP/#_Toc478383520

Received on Thursday, 11 July 2002 18:42:59 UTC