Re: Context Questions

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
application/json

http://bottlepy.org/docs/0.10/api.html?highlight=json#bottle.BaseRequest.json

* 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
paradigm.

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.

Rob