LC304: proposed resolution

I took an action item to propose a resolution to LC304:

  LC304: Definition of a IANA media type token
  http://www.w3.org/2002/ws/desc/5/lc-issues/#LC304

At the end of the email is a brand new proposal.

The following points were raised in the discussion last week[1]:
1. "IANA media type token" is undefined: there was agreement that we
   should define it
2. it was not clear whether we should allow media type parameters
3. it was not clear whether there was a clear relationship between the
   name of a serialization and the media type used for the HTTP
   message body.

Let's start with #3 as I think it is a bigger issue.

The serialization property is a string, which has the format of a
media type, corresponding to the name of a serialization format. This
serialization format, in turn, spells out which content-type to use.
So the "application/xml" serialization, for example, says that the
Content-Type to use is "application/xml". A more complex case:
"application/x-www-form-urlencoded" may serialize the body as
"application/xml".

This has the following limitation: we have defined an
"application/x-www-form-urlencoded" serialization with a particular
template syntax, serializing either as
application/x-www-form-urlencoded or application/xml. If somebody
wanted to design another application/x-www-form-urlencoded
serialization, then they should pick a name with a media type syntax,
say "application/x-www-form-urlencoded-2", which would serialize
things as application/x-www-form-urlencoded with other properties than
ours.

I am therefore increasingly convinced that it would be better NOT to
use an IANA media type token for the value of {http input
serialization}, {http output serialization} and {http fault
serialization}.

It would make issue #2 above go away. In any case, I believe that the
use of parameters for media types would need to be defined in the
serializations, which we have not done. If one wants to allow them in
a new serialization, one can do so, and use an extra attribute to do
so, for example.

• Proposal:

I am therefore proposing to use an identifier which is not an "IANA
media type token" for serialization. I am proposing to use IRIs.

The changes would be:
- change the type of {http fault serialization}, {http input
  serialization} and {http output serialization} to xs:anyURI
- change the name of the serializations we define as follows:
  - 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

These are a little long, but:
- it resolves the issue by removing the term "IANA media type token"
- it solves an extensibility issue

If people did not want to resolve the issue this way (i.e. keep the
extensibility issue), then I would propose using the definition I
proposed when I raised the issue[2], without allowing parameters.

Cheers,

Hugo

  1. http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/att-0018/20050915-ws-desc-minutes.html#item05
  2. http://lists.w3.org/Archives/Public/public-ws-desc-comments/2005Aug/0004.html
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/