Repository navigation
Link header for HTML and JSON-LD #204
Description
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.
Activity
pchampin commentedon Jul 19, 2019
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
Am I getting this correctly?
dlongley commentedon Jul 19, 2019
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+jsonbut 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 commentedon Jul 19, 2019
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+jsonand it includes a Link header withrel="...#context"a processor would load the context from the specified location. (creates another opportunity for infinite recursion, which would need to be handled).BigBlueHat commentedon Jul 23, 2019
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 commentedon Jul 25, 2019
Minutes of previous call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-07-19-json-ld#section5-1
iherman commentedon Aug 9, 2019
This issue was discussed in a meeting.
View the transcript
Link header for HTML and JSON-LDBenjamin 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
… 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 commentedon Aug 10, 2019
Proposal
In LoadDocumentCallback (which defines how all JSON-LD processors should handle document retrieval) after step 4:
Content-Typeis not application/json or any media type with a +json suffix as defined in [RFC6839] and the response has an HTTPLinkHeader [RFC8259] using thealternatelink relation with typeapplication/ld+json, set url to the associatedhrefand restart the algorithm at step 2, ensuring that the resulting resource is of typeapplication/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-Typewas text/html and that a Link header was included which directed tohttps://schema.org/docs/jsonldcontext.jsonldand the document loader would essentially redirect to that resource, which MUST then be of typeapplication/ld+jsonWe'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 commentedon Aug 11, 2019
Minor:
one 'and' too much...
Otherwise +1 for me
Add support for the `alternate` link relation with type `application/…
Add containing section on Modifying Behavior with Link Relationships …
Remove requirement for extracting a context from HTML.
Remove "Using an HTML document as a Context section.
Remove "Using an HTML document as a Context section.
iherman commentedon Aug 16, 2019
This issue was discussed in a meeting.
RESOLVED: merge api#134 and syntax#212, and close syntax#204View the transcript
Benjamin Young: Link header: preemptive conneg.Benjamin Young: See Syntax issue #204
Benjamin Young: See API PR #134
Benjamin Young: See Syntax PR #212
Benjamin Young: 2 PRs are ready to go, right?
Gregg Kellogg: Yes. Open question for base during redirect.
… If you retrieve something non-json. Doc loader will detect rel-alternative links, and redirect to that resource.
… I think the original requested document should be preserved as base URL.
… Just like 303 redirect semantics. In 302, this would not be the case.
Rob Sanderson: JS will silently follow redirects and give you the results. So you don’t know which redirects got you there.
Gregg Kellogg: JS should correctly implement redirect semantics.
Dave Longley: +1 to using 303 semantics, so on, +1 to gregg’s position.
Gregg Kellogg: You have processing state to keep track on this.
Proposed resolution: merge api#134 and syntax#212, and close syntax#204 (Ivan Herman)
Rob Sanderson: +1
Dave Longley: +1
Benjamin Young: +1
Rob Sanderson:
Ivan Herman: +1
Gregg Kellogg: +1
Ruben Taelman: +0.5
Resolution #2: merge api#134 and syntax#212, and close syntax#204
gkellogg commentedon Aug 16, 2019
This particular issue relates to #211, while #212 is for #172.
Add containing section on Modifying Behavior with Link Relationships …
Add support for the `alternate` link relation with type `application/…
Remove requirement for extracting a context from HTML.
Remove "Using an HTML document as a Context section.