Notes
Outline
On message/part/(@type|@element) and use=document|rpc, style=literal|encoded

A personal opinion
Sanjiva Weerawarana
IBM Research
September 9-11, 2002. WSDL WG F2F
Outline
Understanding WSDL 1.1’s design
SOAP 1.2 and XSD realities
What can we do for WDL 1.2?
WSDL 1.1 <message>
Message is a collection of parts
The message is not a real thing by itself, but just a bag of things
Each part represents one “thing” to be sent or received
Don’t just think of RPC parameters – a medical record being sent to a doctor may consist of some XML document (contained in the SOAP envelope) and lots of other stuff like XRay images etc. as attachments. Each such thing would be modeled as a part.
In other scenarios it may be multiple XML documents or elements from different namespaces (purchase order + vcard)
<message> cont.
Alternate syntax may have made this clearer:
<portType name=“..”>
  <operation name=“..”>
    <input name=“..” type|element=…>*
    <output name=“..” type|element=…>*
   </operation>
</portType>
Defining a part
XSD lets you define one of:
Named, complex type
An element, where the element is typed by pointing to a named complex type or by defining an anonymous type just for that
(Consider just global types and elements for now)
(Ignoring attributes and model groups for now)
XSD also provides a set of built-in types
WSDL 1.1 lets you point to named types (type=) or named elements (element=)
WSDL 1.1 SOAP binding
<soap:body> is what defines how the body is built
If a part is described using type=, then one needs a way to generate an XML element out of it
Basically, some mechanism to do the equivalent of an XSD global element declaration needed
In SOAP RPC case, SOAP RPC rules tell you how to make those into elements
Name based based on part name
Content based on encoded or not
In other cases, no mechanism given
If a part is described using element=, then the XML element is given
WSDL 1.1 SOAP binding (cont.)
Works ok for element case
But for use=literal, type=:
Says the type is the type of <soap:Body> and not the part itself for doc style
There can be only one part
Outline
Understanding WSDL 1.1’s design
SOAP 1.2 and XSD realities
What can we do for WDL 1.2?
SOAP 1.2 Data Model
SOAP 1.2 DM with Attachments
SOAP 1.2 Data Model Realities
A SOAP message has more than one thing in it:
0 or more header blocks
0 or more elements in the body
0 or more related stuff in the outer package
XSD Realities
You can define either a
Named, complex type, or
An element, where the element is typed by pointing to a named complex type or by defining an anonymous type just for that
XSD also provides a set of built-in types
Outline
Understanding WSDL 1.1’s design
SOAP 1.2 and XSD realities
What can we do for WDL 1.2?
WSDL 1.2 Possibilities: Message
Even if we only concentrate on SOAP, there’s more than one thing in a “message”
I don’t believe it makes sense to model the collection of things as a complexType or a global element declaration
We can improve the syntax: not use an explicit message declaration, but do the anonymous equivalent (see previous chart on possible alternate syntax)
WSDL 1.2 Possibilities: Parts and XSD
XSD has both named types and named elements
Suppose we only support named elements:
What about the http binding?
What about other non-XML bindings
Suppose we only support named types:
Equivalent of global element declaration would be needed to actually generate XML out of it
Non-XML type systems
MIME, in particular
DIME-like URI identifiers for types
Other more radical ones like java:foo
On style=document/RPC
RPC style is a way to let the WSDL processor generate the contents of <soap:Body>
Two options:
Indicate that SOAP RPC rules are to be used
Say that one should apply the rules first, generate the XSDs and then say that document is to be sent/received
I compare that to describing the stack frame
On use=literal/encoded
If WS-I’s going with literal then let’s forget about use=encoded (yes and drop the use attribute)
As Arthur has mentioned several times, the encodingStyle concept is useful as a way to indicate how the schema was derived
Should be a characteristic of the part definition instead of the SOAP binding only
That will allow the language binding to do the right thing
Conclusions
None really – its up to us to decide on subjective positions to take