[LC304] Improved simplified proposal

I have been thinking about Sanjiva's and Ümit's pushback against my
simplified proposal, and think I found a way to accomodate the Flickr
description problem.

Here is my improved simplified proposal for LC304.

We keep our 3 predefined serialization formats:
- application/x-www-form-urlencoded
- application/xml
- multipart/form-data

The value of the serialization variables will be one or several media
type token. If we have more than one, then it means a set of possible
media types to use.

This leaves us with defining the meaning of one of those media types.

In order to accomodate image/jpeg, I am taking the value of the
{message content model} property of the Interface Message Reference
bound into account.

- if the value of {message content model} is #any or #element:

  - application/x-www-form-urlencoded identifies our
    application/x-www-form-urlencoded serialization format rules

  - multipart/form-data identifies our multipart/form-data
    serialization format rules

  - application/xml identifies our application/xml serialization
    format rules [ no change until now ]

  - any other media type identifies our application/xml serialization
    format rules, but used with the value of the serialization
    property as the content type HTTP header [ this is new ]

- if the value of {message content model} is #none: the payload must
  be empty, so the value of the serialization property is irrelevant
  [this is not currently spelled out in the spec and should be ]

- if the value of {message content model} is #other: the content-type
  header value is set by the value of the serialization property, and
  the message payload is undefined [ this is new too, and the HTTP
  binding currently oddly does not say anything about #other ]

One can now use:

  <interface>
    <operation>
      <input …>
      <output element="#other"/>
    </operation>
  </interface>

  <binding>
    <operation whttp:outputSerialization="image/jpeg"/>
  </binding>

With regards to media type parameters, we can allow them and say that
they are passed along in the Content-Type header.

An example of them:

  <interface>
    <operation>
      <input …>
      <output element="myns:foo"/>
    </operation>
  </interface>

  <binding>
    <operation whttp:outputSerialization="application/x-foo+xml;myParam='bar'"/>
  </binding>

serializes as:

  Content-Type: application/x-foo+xml;myParam='bar'

  <myns:foo xmlns:myns="…">
    …
  </myns:foo>

If one wanted to use say another schema language, the extension would
also define the way to serialize their model:

  <myext:MyCoolSchemaLanguage wsdl:required="true" />

  <interface>
    <operation>
      <input …>
      <output element="#other" myext:element="myns:foo" />
    </operation>
  </interface>

  <binding>
    <operation whttp:outputSerialization="application/x-foo-xml"/>
  </binding>


I believe that this solution:
- clarifies what a media type token in a serialization property actually means
- doesn't prevent description of services using binary objects
- doesn't introduce substantial changes
- allows for clean extensibility

Comments?

-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/