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

"Outer" Package

Other Stuff

SOAP Envelope

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