W3C home > Mailing lists > Public > www-ws-desc@w3.org > October 2005

[LC304] Improved simplified proposal

From: Hugo Haas <hugo@w3.org>
Date: Fri, 28 Oct 2005 18:00:10 +0200
To: www-ws-desc@w3.org
Message-ID: <20051028160010.GG2847@w3.org>
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:

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

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

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:

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

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

serializes as:

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

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

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" />

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

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

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


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

Received on Friday, 28 October 2005 16:00:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:57 UTC