1. 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

2. Outline Understanding WSDL 1.1s design SOAP 1.2 and XSD realities What can we do for WDL 1.2?

3. WSDL 1.1 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 Dont 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)

4. cont. Alternate syntax may have made this clearer: – – * –

5. 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=)

6. WSDL 1.1 SOAP binding 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

7. WSDL 1.1 SOAP binding (cont.) Works ok for element case But for use=literal, type=: –Says the type is the type of and not the part itself for doc style –There can be only one part

8. Outline Understanding WSDL 1.1s design SOAP 1.2 and XSD realities What can we do for WDL 1.2?

9. SOAP 1.2 Data Model Envelope Body Header Block 1 Block 2 Block n Element 1 Element 2 Element n

10. SOAP 1.2 DM with Attachments Envelope Body Header Block 1 Block 2 Block n Element 1 Element 2 Element n Outer Package SOAP Envelope Other stuff

11. 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

12. 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

13. Outline Understanding WSDL 1.1s design SOAP 1.2 and XSD realities What can we do for WDL 1.2?

14. WSDL 1.2 Possibilities: Message Even if we only concentrate on SOAP, theres more than one thing in a message I dont 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)

15. 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

16. Non-XML type systems MIME, in particular DIME-like URI identifiers for types Other more radical ones like java:foo

17. On style=document/RPC RPC style is a way to let the WSDL processor generate the contents of 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

18. On use=literal/encoded If WS-Is going with literal then lets 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

19. Conclusions None really – its up to us to decide on subjective positions to take