I agree with Steve Vinoski’s comment that you can’t expect it to work across the internet. However, his comment applies to generic clients such as browsers, and not clients that you and I are creating for specific applications where we need to be able to understand how to process a message without looking at the contents of the body or by “guessing” by looking at the URI or something else.

Secondly, I don’t necessarily see using a MIME property such as “schema=…” very different from using “+xml”. Clients that understand application/xml do understand media types ending with “+xml”. The MIME type specification of, say, a “application/vnd.foo+xml” could very well describe a schema along with other useful information about that media type.

I talked about it more here:

http://bill.burkecentral.com/2008/03/05/restful-xml-content-negotitation/

For instance, when a client sees a Content-Type: application/vnd.amazon.book+json, it can refer to that media type specification (albeit an informal one) to interpret its syntax and semantics. The same goes for requests as well. When a client finds that a given URI can process application/vnd.amazon.book.comment+json, it can refer to that media type to learn how to construct the request body.

In that sense, by using these extension media types, we can live without something like a WADL.

+xml makes a certain amount of sense because there are a few interesting things you can do with a format if you know it’s XML, even if you don’t know its specifics; e.g., hand off to an XSLT processor. JSON doesn’t yet have either that shared set of useful generic tools, or enough formats that are genuinely at the level of an Internet media type (i.e., something you persist and interchange between systems that span more than a single application).

Besides, if every up-and-coming metaformat wanted a +suffix, we’d be up to our eyeballs in them :) Sometimes I wonder if there’s any real value in +xml, much less others.

FWIW, i use application/vnd.my-object+json quite a bit internally.