Re: Issue 25: SOAP 1.2 data model and WSDL

 Roberto, thanks for writing this up! 8-)
 However, I would summarize the options a bit differently (with 
the prefix 'j' to distinguish easily):
 j1) remove "encoded" use (if we keep the ability to use 
different schema languages from XML Schema, your option 1 is 
still viable but we don't need to specify the SOAP Data Model 
Schema Language)
 j1*) specify the SDMSL anyway
 j2) specify how "encoded" use works, precisely your option 2

 I don't believe your option 3 is viable as it is either 
equivalent to option 1 (if the instances must conform to the 
schema) or to option 2 (if the schema need not be followed) - 
except that again it would be underspecified.

 I have no preference among the three options I listed (j1, j1*, 
j2). I don't think we need to do j1*. If we do j1, I believe we 
should keep the ability to use schema languages other than XML 
Schema and that we clarify how this is done and what it means, at 
least by some additional examples.

 Best regards,

                   Jacek Kopecky

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



On Thu, 11 Jul 2002, Roberto Chinnici wrote:

 > 
 > 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 Sunday, 14 July 2002 15:44:46 UTC