What if a @context URL response is HTML?

[BigBlueHat]

See #53.

The HTML-based response has the value of potentially providing documentation for the contained context, but we lack a few things and/or need to clarify others.

See @gkellogg's suggestions at #53 (comment)

[azaroth42]

Then it's an error.

We dereference the remote context and replace context with the value of the @context member of the top-level object in the retrieved JSON-LD document. If there's no such member, an invalid remote context has been detected.

From https://www.w3.org/TR/json-ld11-api/#overview

[gkellogg]

It’s currently an error, but we can update to handle this case.

[azaroth42]

Only if there's a previous context that establishes a 1.1 processing mode, no?

[gkellogg]

Maybe, there’s not really a danger of a 1.00 processor misinterpreting this, which is the purpose of the @version announcement, see we might allow this as 1.1 behavior. It’s really only when there’s a worry that different versions will process the same document differently that it matters.

[gkellogg]

This requires some syntax changes as well, and we should allow frames to be in HTML too.

[BigBlueHat]

While I like the opportunities this could open up, I remain a bit concerned that the JSON-LD API itself now requires HTML processing vs. having a separate process for extracting JSON-LD and then processing it.

Practically, it means that shipping fully conformant JSON-LD API code requires far more dependencies than it used to. I'd hoped that we could modularize it a bit more such that these things could be layered together when needed.

Would it make sense to move this HTML stuff to an "extraction" process, which is then fed to expansion/compaction/framing, etc?

[gkellogg]

Other than for context processing, it is handled in the WebIDL, with a section on extracting JSON-LD from HTML. We could probably move more algorithmic bits into a separate section and remove some steps from the context area, but there are some subtle differences that might make that more complex.

Once we decided to deal with JSON-LD in HTML normatively, they dye was cast on the need to include HTML tools in a JSON-LD processor.

[iherman]

Once we decided to deal with JSON-LD in HTML normatively, they die was cast on the need to include HTML tools in a JSON-LD processor.

Indeed.