W3C home > Mailing lists > Public > public-linked-json@w3.org > August 2011

RE: MIME type

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Wed, 3 Aug 2011 17:12:17 +0200
To: <public-linked-json@w3.org>
Message-ID: <013801cc51ef$bc5f5660$351e0320$@lanthaler@gmx.net>
> JSON only has an application/ tree media type, thus we either can't use
> text and the +json, or have to specify a text/json registration too.
> Also, JSON is represented using UTF-8, UTF-16, or UTF-32; and text tree
> types are US-ASCII otherwise  ;charset= must be present.
> Basically, we'll probably never get registered if we attempt to do
> text/*+json - nothing is impossible, but the odds are severely stacked
> against us if we even attempt (there's a reason there is no text/json
> and that text/javascript is deprecated).

Sadly, that's probably true. So, application/ld+json would probably be the
best candidate. Would like to hear some more opinions on this..

> > What would be the disadvantages of having an optional context
> parameter in your opinion?
> Primarily that it quite probably wouldn't get used in real world usage,
> most parameters (even charset) have failed implementation wise pretty
> miserably, thus IMHO if we are going to use one I'd suggest using
> something that other specifications also use, and that is familiar to
> some JSON users to stand a chance of being used.

Well, since there aren't many JSON-LD processors out there yet, there is
still a chance to make it right this time.

> I'm not saying I think it's a poor technical decision, because it is
> the
> "Right Way" to do it, but in practicality I just can't see it being
> used
> sadly.

Same argument here. We are defining it now and I think at the moment it
still would be easy to change all available JSON-LD processors.

Markus Lanthaler
Received on Wednesday, 3 August 2011 15:12:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:53:18 UTC