Support for +json media types in API

[lanthaler]

The API has to deal with loading remote documents and evaluating the http://www.w3.org/ns/json-ld#context link header. Currently, a remote document is only be considered valid if it's media type is application/ld+json or application/json. In my discussions with the activity streams community I realized that this might be overly restricting. I would thus like to propose that we also process all media types using a +json suffix as defined in RFC 6839.

PROPOSAL 1: The JSON-LD API should also process all documents labeled with media types using the +json suffix. This decision does not impact the processing of the http://www.w3.org/ns/json-ld#context link header, i.e., it will be evaluated for all JSON media types except application/ld+json (which requires the context to referenced or included directly in the document).

This would result in a couple of minor changes in section 11.1 The JsonLdProcessor Interface.

Probably we should also recommend (doesn't need to be normative) that JSON-LD Processors signal in the Accept that they support application/ld+json and application/json when retrieving documents and application/ld+json when retrieving contexts as suggested by Dave Lehn in #255.

[ansell]

One possible conflict with accepting all +json content types may be with content negotiating services sending application/rdf+json in response to application/json calls, as my web services do. As long as application/ld+json is always there with a higher priority than application/json it should not be an issue.

[lanthaler]

That won’t be a problem as such a response wouldn’t include a HTTP Link header referencing a JSON-LD context. The main purpose of this proposal is to be able to interpret things like application/stream+json that at the same time do reference a JSON-LD context as valid JSON-LD documents.

[lanthaler]

RESOLVED: The JSON-LD API should process all documents labeled with media types using the application/json or any media type with a +json suffix. Implementations must not follow an HTTP Link Header if you encounter an application/ld+json media type.

[lanthaler]

The API has been updated to handle +json media types as well. This means that other media types, such as the upcoming ActivityStreams 2.0 which uses application/stream+json as media type, can be interpreted as JSON-LD as well if they have the corresponding HTTP Link Header referencing a JSON-LD context.

Unless I hear objections, I will therefore close this issue in 24 hours.