Review of LC304 in light of the resolution of LC337 (was Re: LC304: proposed resolution)

I said last week that I would have another look at LC304 in light of
the resolution of LC337 at the F2F[3].

* Hugo Haas <hugo@w3.org> [2005-09-20 16:46+0200]
> 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.

I believe that the resolution to LC337 resolves LC304 at the syntactic
level by clearly defining the syntax of the value of serialization
information properties.

However, the proposal adopted seems not precise enough about the
meaning of this value at this point:

| <alewis> proposal: copy the content of section 2.2 of the Describing
| Media Types for Binary Content note (a product of this WG) into part
| two, AND
| 
| <alewis> point the definition of whttp:inputSerialization,
| whttp:outputSerialization, and whttp:faultSerialization at that
| definition, AND
| 
| <alewis> check other references to these serialization properties to
| insure that they do not improperly restrict serialization to a single
| mime type. 

The xmime:expectedContentTypes attribute follows the syntax defined in
[4], which allows accept-params. The proposal does not indicate what
should be done with accept parameters. Currently, none of our
serialization formats says anything about media type parameters.

Also, it doesn't explicitly tie the media types listed in this list to
serialization formats defined.

I am still worried about somebody saying {http input serialization} =
"application/*", then a client sending some RDF built with certain
rules from the instance data as application/rdf+xml, and then the
service receiving this and having a different idea of what the
application/rdf+xml serialization of the instance data should have
been.

We define an extensibility point (people can define new serialization
formats), but there can be ambiguities about those extensions. I would
be more comfortable with using URIs to specify serialization formats
(as shown below) so that there is no ambiguity about them, but that
goes against the resolution of LC337 and its wildcard mechanism, and I
unfortunately wasn't around.

[…]
> • 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

Before agreeing to close LC304, in order to be more comfortable about
our extensibility story, I would like us to agree on some text for the
spec from somebody who was around during the LC337 discussion:
- addressing what the accept parameters mean and how they interact
  with the serialization formats.
- showing the link between the value of {http fault serialization},
  {http input serialization} and {http output serialization} and the
  serialization formats that we and other may define.

I am afraid that implementing LC337 at this point would require some
guessing and architecting by the editors to have a crisp resolution.

Cheers,

Hugo

  3. http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/att-0067/20050926-ws-desc-minutes.html#item18
  4. http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/