RE: MIME type

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.


> > 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? I don't think a link header is the right thing in this
instance as the context really describes the content itself (so it should be
tightly bound to the content type). Of course a link header with a "rel" of
"describedby" would be an alternative. Perhaps we should allow both!?


--
Markus Lanthaler
@markuslanthaler

Received on Wednesday, 3 August 2011 13:52:14 UTC