Skip to content

What if a @context URL response is HTML? #66

Closed

Description

@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)

Activity

  1. iherman commented on Apr 27, 2019

    @iherman
    Member

    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.

  2. iherman commented on Apr 27, 2019

    @iherman
    Member

    This issue was discussed in a meeting.

    • No actions or resolutions
    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
  3. BigBlueHat commented on Apr 29, 2019

    @BigBlueHat
    MemberAuthor

    Sorry! Someday they'll move that button... 😖

  4. dlongley commented on Apr 29, 2019

    @dlongley
    Contributor

    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?

    This sounds like the right direction to me.

  5. dlongley commented on Apr 29, 2019

    @dlongley
    Contributor

    @iherman,

    ...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.

  6. gkellogg commented on Apr 30, 2019

    @gkellogg
    Member

    @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.

  7. azaroth42 commented on Jul 15, 2019

    @azaroth42
    Contributor

    Closing, done. The levels discussion has happened in the syntax issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions