Repository navigation
What if a @context URL response is HTML? #66
Description
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)
Activity
azaroth42 commentedon Mar 1, 2019
Then it's an error.
From https://www.w3.org/TR/json-ld11-api/#overview
gkellogg commentedon Mar 1, 2019
It’s currently an error, but we can update to handle this case.
azaroth42 commentedon Mar 1, 2019
Only if there's a previous context that establishes a 1.1 processing mode, no?
gkellogg commentedon Mar 1, 2019
Maybe, there’s not really a danger of a 1.00 processor misinterpreting this, which is the purpose of the
@versionannouncement, 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 commentedon Apr 25, 2019
This requires some syntax changes as well, and we should allow frames to be in HTML too.
Add a section on using HTML documents for contexts (and frames).
BigBlueHat commentedon Apr 26, 2019
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 commentedon Apr 26, 2019
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 commentedon Apr 26, 2019
Indeed.
BigBlueHat commentedon Apr 26, 2019
Maybe... 😃 Defining in the syntax document how one can normatively convey JSON-LD in HTML doesn't implicitly require that JSON-LD's core API be the thing to deal with it. For instance, you can convey HTML inside JSON, but that/hasn't meant that HTML parsers should find, extract, and display those values when present (see also MIME, etc).
My concern (when we first discussed this and now) is that we've drastically raised the bar for API implementations when API changes were not in fact required to make the embedding cases normative from a syntax perspective.
It feels like once embedding in HTML became normatively defined the scope quickly crept to making HTML documents potential first-class JSON-LD documents...and that's where the scary parts come in...
At the API level my expectation was/is that there would be an
extract()function that could be (optionally) run if/as needed and if/as wanted by various implementations or deployment configurations.Keeping the bar low and/or layered for processing JSON-LD is important for its future success in areas like Web of Things, credentials, etc.
Is there a way (presently) that we can reconsider the API level concerns around extracting JSON-LD from HTML?
dlongley commentedon Apr 26, 2019
I think @BigBlueHat is absolutely right here. We need to keep things layered in a sensible way.
gkellogg commentedon Apr 26, 2019
As I said, we can further extract some of the bits into the HTML Content Algorithms section and do something like you expect with an
extract()call. But, I think the issue isn't so much about how distributed the text is, but how normative the requirement is.Perhaps adding a preface that describes a "JSON-LD in HTML" conformance level and reinforcing that where the algorithm is invoked, in the HTML Content Algorithm sections, and moving the relevant tests out of expand/compact manifests and into separate html manifest would satisfy your concern?
The changes to the syntax (and framing) sections should be a bit simpler.
2 remaining items
BigBlueHat commentedon Apr 29, 2019
Sorry! Someday they'll move that button... 😖
dlongley commentedon Apr 29, 2019
This sounds like the right direction to me.
dlongley commentedon Apr 29, 2019
@iherman,
I suspect jsonld.js core will not have any HTML support. Our library is written such that an HTML document loader could be written and used in conjunction with the library, however.
gkellogg commentedon Apr 30, 2019
@BigBlueHat @dlongley @iherman I added a section on processor levels and added text around parts of the algorithm which manipulate HTML to use them. (Also added similar text to w3c/json-ld-syntax#167). See if this satisfies your concerns. If so, I can split out tests into a separate context.
Add a section on using HTML documents for contexts (and frames).
azaroth42 commentedon Jul 15, 2019
Closing, done. The levels discussion has happened in the syntax issue.
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.
Remove requirement for extracting a context from HTML.
Remove "Using an HTML document as a Context section.