Decentralizing media types

| 3 Comments | No TrackBacks

There's a debate regarding decentralized media types.

Here's a case, I think, where the scale of solutions in a corporate Intranet are different from the solutions at Internet-scale.

Say you're in an IT department, want to use RESTful web services for your SOA, but have your own canonical XML schemas for representing data in many of your business domains. How do you register those media types?

You could


  1. use the plain application/xml media type and hope people will sniff the XML namespace and hope it accurately describes what's in the document (most common, not very RESTful)
  2. use my own media type with my own private registry (pretty common but not necessarily interoperable + consumers require a priori knowledge of where the registries are)
  3. use the most general media type you can for the representation and a URI as a media type parameter that points to a registry with more metadata (which could lead to some interoperability, cacheability, etc.)
  4. go back to using SOAP and UDDI. (....)

Obviously #3 seems to make the most sense, with caveats. I echo other commenters when I say that "application/data-format" is too general, that the metadata shouldn't just be RDDL (an HTML page may be more useful in practice!), and that the number of registries should be minimal.

Media type proliferation is a governance problem. On the Internet, the IANA is the governing body. In an Intranet, .... it depends on your governance model. What's clear is that having everyone's IT department register their own vnd media type seems both silly and untenable because those media types will not likely be general. So they'll have their own corporate&partners registry.

As for mixed vocabulary semantics, we do have a problem -- but RDF/OWL is a non-starter for most IT departments. I agree this should change some day, but, baby-steps are needed. So, what can an IT department that wants to use RESTful media types for its SOA do to indicate representation meaning *today*, without adopting the Semantic Web?

For this I imagine a registry that points to a model, whether written text, UML, ERD, or something more formal, that shows an architect or developer how the mixed elements relate to one another. In other words, use configuration management as a palliative. This does not solve the problem in general, but it arguably makes for a workable solution in a smaller scale.

So, coming back to decentralized media types, here's what I see:


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

No TrackBacks

TrackBack URL: http://www.stucharlton.com/blog/mt-tb.cgi/17

3 Comments

Doesn't Atom already enable decentralized media types?

What's wrong with using the Atom media type in the response HTTP header and then wrappering your custom content as an Atom entry (either a top level entry or in a feed envelope)? Then use the "type" attribute of the Atom entry "content" element to declare the (machine processable) media type. See http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.3.1 .

Note that the "type" attribute for the Atom content element does NOT need to provide a MIME type that has been REGISTERED with IANA. The Atom spec only requires that the value "MUST conform to the __syntax__of a MIME media type." (emphasis added)

Using this approach you get the benefits of a general/universal format like Atom, with the ability to label your custom content in a legal/standardized way.

@Nick:

I agree with Stu. If you're wrapping stuff in Atom, might as well use SOAP.

Somebody on another blog suggested using media type properties:

application/xml; schema="http://...."

or something like that. I dont' know yet if that screws up browsers viewing XML or not.

Leave a comment

About this Entry

This page contains a single entry by Stu published on February 11, 2008 11:33 AM.

Facelift was the previous entry in this blog.

Comments are fixed is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

About Me
(C) 2003-2010 Stuart Charlton

Blogroll on Bloglines

Disclaimer: All opinions expressed in this blog are my own, and are not necessarily shared by my employer or any other organization I am affiliated with.