This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

More About Decentralized Media Types

Stefan Tilkov,

Steve Vinoski changes his mind:

At the end of the day, I understand the various explanations for why decentralizing media types is not a good idea after all, and I agree with them.

Stu Charlton believes there’s merit to the idea, if not the exact implementation:

  • There are many that feel a need to introduce a standardized “more information on this representation” hook , beyond just the IANA media type.
  • A URI likely is the best candidate format for this hook.
  • Other media types are already offering this feature inside the representation body (e.g. XMLNS declarations, GRDDL declarations in HTML) ….
  • … But to work best with the deployed web, and to be most general-purpose, it seems this URI should be somewhere in the HTTP header.
  • The debate is mostly matter of whether a) there is such a thing as a general purpose “more info on this media type” resource , and b) if so, where to place the link, so that it fits well with the deployed Web and doesn’t necessarily cause problems for a future Semantic Web.

Dan Diephouse has no problem being uncool:

There is this idea that we should stay far far away from anything that even remotely reminds anyone of WSDL (even if its not an IDL) because it can be misused. I can’t believe that no one isn’t throwing up their arms against this idea. I suppose this will make me very non-cool, but just because a tool can be used in a bad way doesn’t means that you should never use it.

James Snell is opposed to the whole idea:

The key is to focus on solving specific, real world problems as opposed to coming up with kitchen sink solutions that are so generalized that they’re of no use to anyone.

On February 12, 2008 1:08 AM, Erik Johnson said:

This reminds me of the SOAPAction HTTP header vs. the QName of the first child of the soap:body element. Which one is the “normative” place to figure out what the payload is? The SOAP spec invented the SOAPAction header, but then the WS-I Basic Profile effectively deprecated it. But the WS-I couldn’t eliminate SOAPAction because that meant changing a W3C spec and a number of implementations counted the existence of SOAPAction to correctly dispatch calls. So, the SOAPAction header was put in a weird purgatory of being both required and ignored at the same time.

Part of my concern is that the open media type — parameterized or not — creates the same situation: two places where you identify payload format. Which one wins? My other concern is that the URI parameter is being pitched as a URL to a RDDL. Shouldn’t namespace declarations and documentation locations be separate?. Think of all the XML namespace names with an HTTP:// scheme and how many people believed they were live URLs.

But I can live with the basic proposal: putting a parameter after a registered media type. It’s a good compromise. But the parameter should be a URN declaration only and it should be optional (at least for application-xml).

On February 12, 2008 12:37 PM, Stefan Tilkov Author Profile Page said:

The SOAPAction header, IIRC, was deprecated because it was protocol-dependent (which the WS people wanted to avoid at all costs), so I don’t think this situation is exactly comparable. But you are right that there’s a problem when the proposed URI and the actual content don’t agree about the schema to be used — I don’t see any way around this though.