W3C home > Mailing lists > Public > public-linked-json@w3.org > February 2014

Re: Context Questions

From: Robert Sanderson <azaroth42@gmail.com>
Date: Mon, 3 Feb 2014 14:42:47 -0700
Message-ID: <CABevsUHdft+1DgwRTU8RzbRw0ATC=sS6F8uKacGVBed-o9pziA@mail.gmail.com>
To: Gregg Kellogg <gregg@greggkellogg.net>
Cc: Markus Lanthaler <markus.lanthaler@gmx.net>, Linked JSON <public-linked-json@w3.org>
Thanks Markus, Gregg,

Yes you interpreted the question correctly, I should have been more clear.
 Thanks for the answers.

And one response below...

On Mon, Feb 3, 2014 at 2:22 PM, Gregg Kellogg <gregg@greggkellogg.net>wrote:

> > Link headers are ignored for application/ld+json responses and (at least
> > theoretically) @context should be ignored in all other documents. In
> > practice, however, I assume most implementations will use embedded
> > @context's. The processor starts with the one in the link header and then
> > adds the ones in the document.
> Once processing starts for a document, it MUST include processing embedded
> &context definitions, even if it was passed using application/json
> originally. But, why wouldn't you just use application/ld+json if you're
> serving a JSON- LD document?

For backwards compatibility with /other/ systems.  Some examples, of
varying importance and interest:

* web browsers don't understand application/ld+json, meaning that for a
developer it gets downloaded rather than rendered.  Not a big deal but ...
* web frameworks won't parse application/ld+json, instead the developer
needs to intercept it manually.  For example, in the Python bottle
framework, you can read request.json ... but only if Content-Type is


* And most importantly, the same for AJAX responses in frameworks that
trigger off of content-type.  I think in jQuery you can manually set
dataType:"json" but for other systems I'm sure that's not always the

Basically, no one these days has control of the entire stack when building
either end of the transaction, and application/json has some desirable
magic properties.

Received on Monday, 3 February 2014 21:43:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:41 UTC