RE: MIME type

> 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
@markuslanthaler

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