1. (or not)

2. : What problem is it trying to solve? Indicate the data that is sent to or received from a service Typically the information sent is more than one thing –May contain optional pieces of data or things which occur repeatedly Each thing is typed –At least two type systems are common on the Web: Schema, MIME –Others must also be supported, e.g.: Java

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

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

5. Options for WSDL 1.2 Leave –Doesnt support repeating stuff, optionality etc. –Type/element split causes binding headaches Inline within –See proposal by Sanjiva –Still has many of the problems of Just say input/output of an operation is a single complexType or element –Have to do some sleight-of-hand in the SOAP binding Basically already has a type (say x:tBody), and this type would effectively be an alternate type –Non-XSD type systems

6. An Approach The type cannot be arbitrary –Having attributes means you cannot literally stuff it in We would need to go thru and precisely define what subset of complexType is legal and acceptable for a variety of bindings –Use the PASWA-style approach for non-XSD type systems Having to name the type sucks

7. An Approach #2 …. Alternatively we can define input as an extension of complexType: … (See next page)

8. Syntax (etc.) …

9. Pros/Cons Pros: –Eliminates / –SOAP doc/lit binding is immediate PASWA style approach for attachments is also immediate –Gives optionality etc. as offered by XSD Cons: –Sleight-of-hand for soap:Body type –Second class support for other type systems