Re: MIME type

Markus Lanthaler wrote:
> Nathan wrote:
>> Markus Lanthaler wrote:
>>> 7) application/ld+json
>> The above looks good, nice and short, uses the +json appropriately, and
>> doesn't repeat the term "json".
> 
> Was also my favourite but perhaps with text/
> 
> 
>>> Would be using "text" instead of "application" an option? E.g.
>>> text/json-ld+json
>> text tree types would require the use of a ;charset=utf-8 suffix, and
>> there may be some nuances around the +json and charsets, could be
>> investigated.
> 
> The charset parameter is not required. It has just to be defined in the
> spec. According to RFC2046 (http://www.ietf.org/rfc/rfc2046.txt):
> 
>    The specification for any future subtypes of "text" must specify
>    whether or not they will also utilize a "charset" parameter, and may
>    possibly restrict its values as well.  For other subtypes of "text"
>    than "text/plain", the semantics of the "charset" parameter should be
>    defined to be identical to those specified here for "text/plain",
>    i.e., the body consists entirely of characters in the given charset.
>    In particular, definers of future "text" subtypes should pay close
>    attention to the implications of multioctet character sets for their
>    subtype definitions.
> 
> I'm favouring the text/ type since (most) browsers would show the JSON-LD
> document instead of always asking where to save it which is IMHO a great
> advantage.. Again, RFC2046 says that
> 
>    The "text" media type is intended for sending material which is
>    principally textual in form.
> 
> which I think applies to JSON-LD even though JSON uses the application-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).

>>> I would also propose to define a media type parameter such as
>> "context" to
>>> be able to directly link to a context document in a HTTP header and
>> thus
>>> eliminating the need of @context in the JSON document itself.
>> Unsure if ;context= would be a good idea, perhaps, maybe some overlap
>> with ;profile= from json-schema, and may be able to leverage a Link
>> header instead for this purpose. I guess it depends whether we think
>> context is, and always will be, ld+json specific.
> 
> 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.

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.

About the best we can hope for, in the common case, is to get .ld or 
.jsonld mapped to application/ld+json in the apache mime types file, if 
we can get that far then I'd class that as a win. Thus, would set it as 
a realistic, if not perfect, target to aim for.

Best,

Nathan

Received on Wednesday, 3 August 2011 14:56:46 UTC