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 ModelE

nvel

ope

Bod

yH

eade

r

Block1 Block2 Blockn

Element1 Element2 Elementn

SOAP 1.2 DM with Attachments

Env

elo p

e

Bod

yH

eade

r

Block1 Block2 Blockn

Element1 Element2 Elementn

“Outer” Package

SOAP Envelope Other stuff

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