You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Along the lines of what @Gellogg was referring to: we had a somewhat similar problem in RDFa as for what types of capabilities an RDFa processor may have, see, e.g., RDFa Core Accessing the Processor Graph. That section also includes several classes of RDFa Processors.
Translating this to our context, this means that we may introduce 'classes' of JSON-LD processors:
The whole deal (I believe this should be the default)
No HTML content (but I believe this should mean no processing of embedded JSON-LD in general, not separating a @context)
Streaming processor (although this may be only informative, because we will not yet provide a 100% foolproof specification on what that means)
I am not sure it is necessary to have a standard way of declaring the processor class or just to leave it to the processor.
I would also think that a 'whole deal' should be the default case, ie, unless a processor clearly declares to be a no-HTML content then it should be such a default.
View the transcript
ob Sanderson: TOPIC Issue: context response as HTML
Rob Sanderson: link: #66
Rob Sanderson: what happens if you deref. a context and you get back HTML
… currently it’s an error
… however we opened the door of dealing with HTML within json-ld
… is it justified though?
Gregg Kellogg: we did look to this as part of our solution on how to document json-ld
… I created an example as part of one of the pull requests
… what does this mean in terms of processing
… you get HTML turn that into JSON and pass that to the processor
… where that didn’t work was with contexts
… related to WebIDL section of the api spec that discusses framing (?)
David Newbury: workergnome_ has joined #json-ld
Rob Sanderson: having a context that self-documents with HTML seems like a potential benefit
… if you don’t want to have HTML then just use content negotiation to request json only
Benjamin Young: web of things/credentials/etc. more than likely won’t ship with dom parsers
… if there’s a way of making html parsing more modular
… or at least not making it a requirement, would be preferred
Dave Longley: +1 to everything bigbluehat just said
Ivan Herman: if I don’t care about the implementation, and that I can use json-ld with HTML
… user’s might be confused when they can actually use json-ld+html
Benjamin Young: if there’s any req. that a context stays the same (e.g. for hashing or what not) than you would properly not want to have it in HTML
… verifiable claims would properly freak out if they have to include a dom parser too
… if there’s a way to achieve this in the api spec, then +1!
Dave Longley: perhaps we can have a conformance class around document loaders and push everything that way—and say that you have to use a document loader that understands JSON-LD in HTML if you want to support that, and then we don’t need two specs, just more conformance classes around document loaders (maybe)
Gregg Kellogg: wondering whether we can actually pull the HTML part out into an own spec, or define a profile for it
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?
...unless a processor clearly declares to be a no-HTML content then it should be such a default.
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.
@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.
Activity
iherman commentedon Apr 27, 2019
Along the lines of what @Gellogg was referring to: we had a somewhat similar problem in RDFa as for what types of capabilities an RDFa processor may have, see, e.g., RDFa Core Accessing the Processor Graph. That section also includes several classes of RDFa Processors.
Translating this to our context, this means that we may introduce 'classes' of JSON-LD processors:
@context)I am not sure it is necessary to have a standard way of declaring the processor class or just to leave it to the processor.
I would also think that a 'whole deal' should be the default case, ie, unless a processor clearly declares to be a no-HTML content then it should be such a default.
iherman commentedon Apr 27, 2019
This issue was discussed in a meeting.
View the transcript
ob Sanderson: TOPIC Issue: context response as HTMLRob Sanderson: link: #66
Rob Sanderson: what happens if you deref. a context and you get back HTML
… currently it’s an error
… however we opened the door of dealing with HTML within json-ld
… is it justified though?
Gregg Kellogg: we did look to this as part of our solution on how to document json-ld
… I created an example as part of one of the pull requests
… what does this mean in terms of processing
… you get HTML turn that into JSON and pass that to the processor
… where that didn’t work was with contexts
… related to WebIDL section of the api spec that discusses framing (?)
David Newbury: workergnome_ has joined #json-ld
Rob Sanderson: having a context that self-documents with HTML seems like a potential benefit
… if you don’t want to have HTML then just use content negotiation to request json only
Benjamin Young: web of things/credentials/etc. more than likely won’t ship with dom parsers
… if there’s a way of making html parsing more modular
… or at least not making it a requirement, would be preferred
Dave Longley: +1 to everything bigbluehat just said
Ivan Herman: if I don’t care about the implementation, and that I can use json-ld with HTML
… user’s might be confused when they can actually use json-ld+html
Benjamin Young: if there’s any req. that a context stays the same (e.g. for hashing or what not) than you would properly not want to have it in HTML
… verifiable claims would properly freak out if they have to include a dom parser too
… if there’s a way to achieve this in the api spec, then +1!
Dave Longley: perhaps we can have a conformance class around document loaders and push everything that way—and say that you have to use a document loader that understands JSON-LD in HTML if you want to support that, and then we don’t need two specs, just more conformance classes around document loaders (maybe)
Gregg Kellogg: wondering whether we can actually pull the HTML part out into an own spec, or define a profile for it
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.