LC304: proposal to disambiguate serializations used in HTTP binding

We had a discussion last week about LC304[1]. The core of the issue is
that the current notation for serialization formats, using media type
syntax, is ambiguous.

If one sees in a WSDL:

  <binding type="http://www.w3.org/2005/08/wsdl/http" name="foo">
    <operation whttp:method="POST" ref="bar:op"
               whttp:inputSerialization="application/rdf+xml" />
  </binding>

what serialization format does "application/rdf+xml" exactly refer to?
The one that the W3C DAWG may come up with (supposing that they do
come up with one, which I think they will), the one that I may come up
with in my spare time, etc.?

I proposed to draft a proposal, taking into account the problem that
LC337[2] was trying to address.

Here is a 3 point proposal:

- instead of naming serialization with an IANA media type token, name
  serializations with IRIs: this is unambiguous, and this is usually
  how we deal with extensibility points

- consequently rename our current serializations:
  - application/x-www-form-urlencoded →
    http://www.w3.org/YYYY/MM/wsdl/http/application/x-www-form-urlencoded
  - application/xml →
    http://www.w3.org/YYYY/MM/wsdl/http/application/xml
  - multipart/form-data →
    http://www.w3.org/YYYY/MM/wsdl/http/multipart/form-data

- change the type of {http input serialization}, {http output
  serialization} and {http fault serialization} to an xs:list of
  xs:anyURI's: for LC337, the DAWG will be able to list serializations
  they want to use

The result for my example above would be, to make it clear which
application/rdf+xml serialization is in use:

  <binding type="http://www.w3.org/2005/08/wsdl/http" name="foo">
    <operation whttp:method="POST" ref="bar:op"
               whttp:inputSerialization="http://hh.example/application/rdf+xml" />
  </binding>

I was originally worried about redesigning the HTTP binding because of
this issue. Having thought about this more, I don't think that it is a
redesign: we had an ambiguous extensibility point, we are simply
tidying it by changing the naming of serialization formats.

Note that this will result in one complication for the DAWG: they will
need to define the serialization formats other than the ones we define
that they want to use in their WSDL. I believe that this is not a bad
thing: if they want to have to have a fault which is serialized as
some random human-readable HTML, then they should cleary define it.
Also, they'll have to come up with an RDF serialization. If we go this
route, we'll definitely have to check with them.

As for the difference with the current resolution of LC337, we lose
the ability to use media type parameters out of the box, which is a
good thing IMO because the resolution to LC337 doesn't say how they
should be used anyway.

Regards,

Hugo

  1. http://www.w3.org/2002/ws/desc/5/lc-issues/#LC304
  2. http://www.w3.org/2002/ws/desc/5/lc-issues/#LC337
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/