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.
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).