Link header for HTML and JSON-LD

[gkellogg]

If we remove support for context extraction from HTML, we might want to consider broadening the Link Header to be able to specify the context location, which might help @danbri. We also might want to revisit whether it can bu used for JSON-LD files as wee, as it’s currently restricted to just plain JSON.

[pchampin]

Let me rephrase. What you are suggesting is to link a JSON-LD context from an HTML page rather than embedding it. This would be done using RFC5988 HTTP headers, so

• it would not require the JSON-LD processor to parse the HTML, and
• it would not require the server to perform "active" content negotiation.

Am I getting this correctly?

[dlongley]

If I understand this, this approach sounds like it wouldn't be that functionally different from following a redirect. So, a JSON-LD processor would hit a URL, get back something that isn't application/ld+json but that has a link header in it that points at a JSON-LD context. We already do something very similar for JSON resources that have a context elsewhere ... so it doesn't seem to me like that much of a stretch to support this if it actually addresses important use cases.

cc: @msporny -- thoughts?

[gkellogg]

The thought I expressed on the call was to re-use the Link header but add semantics so that if the response when fetching a context is not application/ld+json and it includes a Link header with rel="...#context" a processor would load the context from the specified location. (creates another opportunity for infinite recursion, which would need to be handled).

[BigBlueHat]

Let's be sure to distinguish between the HTTP header conversation and the HTML-level <link> tag approach. They have very different requirements in terms of both processing and deployment.

Also @gkellogg's concerns about infinite recursion would likely apply to both scenarios.

[azaroth42]

Minutes of previous call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-07-19-json-ld#section5-1

[iherman]

This issue was discussed in a meeting.

• No actions or resolutions

View the transcript

Link header for HTML and JSON-LD
Benjamin Young: See Issue 204
Gregg Kellogg: this was trying to rely to danbri’s concern about relying on content negotiation
… the best solution I came up with was to rely on a link HTTP header
… A JSON-LD processor expecting a context at a given URL would check for this header,
… and follow the link if any.
Ivan Herman: other people do that, with rel="manifest"
… the Web Publication WG does something similar with rel="publication"
… we can bikeshed about what rel value we want. But this makes sense.
Ruben Taelman: link headers are not always possible on static websites, e.g. github pages.
Benjamin Young: just to be clear, the link header we are talking about is a HTTP header, not HTML $MD_CODE$
… It is not as common as content negotiation on static sites.
… So we should specify that JSON-LD processors should first try content-negotiation,
… if it fails, it should try HTML (which implies embedding a HTML parser)
Dave Longley: +1 to link headers, -1 to involving HTML processing at all w/context processing as it breaks the ecosystem
Benjamin Young: then it should check the link header.
Pierre-Antoine Champin: I think this solution makes sense
… whether content negotiation has priority or not, I think this would be nice to have
… the way I saw it this was a way to get rid of a dependency on HTTP
Gregg Kellogg: this is all because the desire of schema.org (and may be others)
… to avoid doing content negotiation.
… Whenever we can’t do conneg nor HTTP headers,
… we are back to parsing HTML.
Dave Longley: I would be in favor of the link HTTP header solution,
… even if it does not solve all problems.
… I am against the reliance on HTML parser. This would break the ecosystem.
… Also, we should not make decision on the features that github pages have today.
… That may change in the future.
Benjamin Young: (a cosmetic argument that I missed)
Ruben Taelman: I don’t see the benefit of the link header over conneg;
… if a host supports one, it should supports the other, right?
Dave Longley: some static sites can do link headers.
… It requires less processing on the server side than conneg.
Pierre-Antoine Champin: +1

[gkellogg]

Proposal

In LoadDocumentCallback (which defines how all JSON-LD processors should handle document retrieval) after step 4:

1. If the retrieved resource's Content-Type is not application/json or any media type with a +json suffix as defined in [RFC6839] and the response has an HTTP Link Header [RFC8259] using the alternate link relation with type application/ld+json, set url to the associated href and restart the algorithm at step 2, ensuring that the resulting resource is of type application/ld+json.

So, in the case that an HTML resource is returned with a link header such as the following:

Link: <https://schema.org/docs/jsonldcontext.jsonld>; rel="alternate"; type="application/ld+json"

the document loader would see that the Content-Type was text/html and that a Link header was included which directed to https://schema.org/docs/jsonldcontext.jsonld and the document loader would essentially redirect to that resource, which MUST then be of type application/ld+json

We'd also need a section in the syntax document near Interpreting JSON as JSON-LD to describe this behavior and note it's utility for static websites. This would also allow us to remove the need to process embedded HTML for context files, as this handles the documentation requirement.

We could consider a different link relation, but "alternate" seems appropriate, when coupled with type.

cc/ @danbri

[iherman]

Minor:

and and the response

one 'and' too much...

Otherwise +1 for me