|
|
|
Sanjiva Weerawarana |
|
IBM Research |
|
September 9-11, 2002. WSDL WG F2F |
|
|
|
|
Understanding WSDL 1.1’s design |
|
|
|
SOAP 1.2 and XSD realities |
|
|
|
What can we do for WDL 1.2? |
|
|
|
|
|
|
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) |
|
|
|
|
|
|
|
Alternate syntax may have made this clearer: |
|
<portType name=“..”> |
|
<operation name=“..”> |
|
<input name=“..” type|element=…>* |
|
<output name=“..” type|element=…>* |
|
</operation> |
|
</portType> |
|
|
|
|
|
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=) |
|
|
|
|
|
|
<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 |
|
|
|
|
|
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 |
|
|
|
|
|
|
Understanding WSDL 1.1’s design |
|
|
|
SOAP 1.2 and XSD realities |
|
|
|
What can we do for WDL 1.2? |
|
|
|
|
|
|
|
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 |
|
|
|
|
|
|
|
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 |
|
|
|
|
Understanding WSDL 1.1’s design |
|
|
|
SOAP 1.2 and XSD realities |
|
|
|
What can we do for WDL 1.2? |
|
|
|
|
|
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) |
|
|
|
|
|
|
|
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 |
|
|
|
|
MIME, in particular |
|
DIME-like URI identifiers for types |
|
Other more radical ones like java:foo |
|
|
|
|
|
|
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 |
|
|
|
|
|
|
|
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 |
|
|
|
|
None really – its up to us to decide on
subjective positions to take |
|