Html base

[gkellogg]

(Based on PR #68).

This adds back language and examples for using HTML base for resolving relative IRIs.

Fixes #23.

---

Preview | Diff

[gkellogg]

This issue was discussed in a meeting.

• Resolution #2: merge open HTML related PRs #93 and #68 and #50 after adding “At Risk” (or similar terminology) to present that things are not finalized

View the transcript

What is ‘base’ for embedded json-ld?

Ivan Herman: link: #23

Ivan Herman: Link of the PR: #93

Benjamin Young: #68

Gregg Kellogg: w3c/json-ld-api#50

Benjamin Young: we discussed that one at tpac
… we sent it in for TAG review, and they basically widened the scope

Gregg Kellogg: there are 2 open PRs
… 1) basic support for json-ld in html
… 2) PR-93 adds text to specifically add text to add html as base
… in the API spec, it’s PR-50

Adam Soroka: quick question, what are we expected to do with their comments?
… shall we respond?

Ivan Herman: what they propose is interesting but beyond our charter
… this would elevate json-ld
… but yeah beyond our charter
… I would say this is something the CG has to pick up
… and we can cross the bridge at some time, but if this is realistic from a manpower perspective I dont know

Benjamin Young: #68 (comment)

Ivan Herman: regarding the PR-93, there is some stuff about having XML

Benjamin Young: the thing I just linked shows how script tags affect html parsing
… it’s syntactically correct json-ld

Gregg Kellogg: what I did in the PR-68 I call out specifics on how to handle those blocks if the media type is application/json
… I think I’ve taken in the specifics on how content of script tags has to be handled and adjusted in for our needs
… we asked specific questions to TAG, got an answer but they kinda got a bit over enthusiastic
… out of this needs to come something that improves web platform

Benjamin Young: the HTML comments stuff as really bothered me since I’ve read it
… but it seems to primarily affect only HTML parsing
… question is how much of this we need to have in the spec
… json-ld in script tags vs “raw” json-ld
… both have totally different escaping rules and what not.. and none of that has something to do with html base

Ivan Herman: for the comment storing, the whole section is a normative thing
… I have the impression this is an HTML problem
… which we should certainly mention, but maybe not as part of a normative section

Benjamin Young: HTML5 spec level text about parsing <script> tags https://www.w3.org/TR/html5/semantics-scripting.html#restrictions-for-contents-of-script-elements

Ivan Herman: we should officially answer to the TAG and will officially add to the standard what they said about base
… and that we try to get the CG involved

Adam Soroka: +1

Gregg Kellogg: comments in html and escaping.. it depends on the encoding
… we don’t need to give guidance on how to handle this

Ivan Herman: https://pr-preview.s3.amazonaws.com/w3c/json-ld-syntax/pull/68.html#ex-103-embedding-json-ld-in-html-with-comments

Ivan Herman: it has to be valid json-ld
… that’s invalid json

Gregg Kellogg: that’s something you see quite often

Benjamin Young: ivan: because https://www.w3.org/TR/html5/semantics-scripting.html#restrictions-for-contents-of-script-elements

Gregg Kellogg: comments are often used just to make sure there are no other issues embedded in the script elements that would cause any issues

Benjamin Young: I did quite some digging on that issue
… the DOM parsing is only concerned with what’s inside the tags
… it’s just treated as raw string
… if there’s something inside the json-ld an html parser would choke on
… the json-ld would need to be treated in such a way such that an html parser wouldn’t choke on it

Pierre-Antoine Champin: one crazy idea by looking at the json-ld embedded in html comments: you could add a js comment in front of the html comment, making it valid javascript
… it could become technically correct

Benjamin Young: sadly it wouldn’t
… it would continue being parsed
… we could make it our own parsing space
… the question is how far the parser gets before it finds the ending script tag

Gregg Kellogg: the json-ld would not be allowed to contain anything that could be interpreted as html and/or html comments
… not really feasible and also not helping our mission
… I’ve outlined multiple approaches to tackle this
… there are only a few cases where json-ld would contain things that resemble comments

Harold Solbrig: why is this an json-ld issue but not a javascript issue?

Gregg Kellogg: [explains why it isn’t]

Gregg Kellogg: it did some test cases for this, exploring corner cases we know of
… I don’t know how to move forward unless addressing at least some of the stuff from the PR

Gregg Kellogg: it describes script tags and data blocks are a subset

Benjamin Young: what’s breaking it, is the potential of one to too early close the script tag
… so this would need somehow being taken care of
… the risk is, the json-ld could contain content that jacks up the html it’s contained in

Ivan Herman: is it so horrible to say, if I put json-ld in a script tag I’m supposed to escape anything that html would need to have escaped
… thus a json-ld parser would have to do the unescaping
… but you are in HTML regardless.. so

Gregg Kellogg: for someone who’s actually looking at the source, those entities become rather annoying

Ivan Herman: realistically, I don’t know how often this would happen

Benjamin Young: the escaping issue is very similar of putting json-ld inside a text env.

Ivan Herman: I think it’s perfectly reasonable to accept both PRs, close the issue
… and open a new issue on the specific problem

Gregg Kellogg: it’s a editor’s draft not a working draft

Ivan Herman: we would open a issue right away

Benjamin Young: I would only +1 this, if we add a big red AT RISK disclaimer

Ivan Herman: a lot of very important things are pending for now
… I think it’s an edge case

Adam Soroka: I don’t think we should use a phrase like “AT RISK” but more something along the lines of “will be part of the final spec but might undergo some changes”

Ivan Herman: we cannot commit ourselves to having always consistent editor’s drafts

Benjamin Young: I’m not sure we have reached consensus on all the things contained

Gregg Kellogg: I cannot work on other open issues

Pierre-Antoine Champin: what about a parameter on the media type hinting at having to do unescaping? (like application/ld+json;escaped=html)

Proposed resolution: merge open HTML related PRs #93 and #68 and #50 after adding “At Risk” (or similar terminology) to present that things are not finalized (Benjamin Young)

Benjamin Young: +1

Adam Soroka: +1

Ivan Herman: what does “that” mean?

Gregg Kellogg: +1

Benjamin Young: I don’t want to have stuff merged without reaching consensus
… but I could live with having it marked as being “at risk” or similar

Ivan Herman: putting things that are already done “at risk” would be going backwards
… opening a new issue that highlights things that are still being discussed would be ok
… having the feeling that ~90% are done

Adam Soroka: I have to generally agree with ivan

Ivan Herman: +1

Adam Soroka: it seems for me very unlikely that we would stop talking about it

David Newbury: +1

Harold Solbrig: +1

Benjamin Young: I’m fine with merging those

Simon Steyskal: +1

Resolution #2: merge open HTML related PRs #93 and #68 and #50 after adding “At Risk” (or similar terminology) to present that things are not finalized

Pierre-Antoine Champin: +1