Skip to content

JSON-LD script elements (data blocks) MUST only contain valid JSON #96

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
BigBlueHat opened this issue Nov 28, 2018 · 4 comments
Closed

Comments

@BigBlueHat
Copy link
Member

The current editor's draft suggests wrapping JSON-LD in a data block with <!-- and --> to avoid some HTML parsing situations. Ultimately, that means that we're suggesting that the contents of an embedded JSON-LD data block is legally invalid JSON-LD...which seems bad...

Consequently, I'd like to propose that we only specify the entity encoding of certain strings within the JSON-LD contents to avoid the potential HTML parsing mishaps described in HTML's Restrictions on contents of script elements section.

Doing that avoids encouraging invalid JSON-LD and removes the additional unique parsing steps for cleaning out the wrapping <!-- and -->.

PR forthcoming.

@gkellogg
Copy link
Member

I can support this, but we need to have some rule for dealing with comment inside of strings that could cause DOM problems, specifically <!--, -->, <script and </script. Using either or both of the current escape sequences and character references will keep the content legal JSON, but it will not be interpreted properly unless unescaping or resolving character references is performed.

Surrounding script contents with XML comments is a common practice, but may be obsolete now with HTML5, along with CDATA.

@iherman
Copy link
Member

iherman commented Dec 1, 2018

This issue was discussed in a meeting.

  • No actions or resolutions
View the transcript JSON-LD script elements (data blocks) MUST only contain valid JSON
Benjamin Young: #96
Benjamin Young: issue related to #97
Gregg Kellogg: what I pushed up there addresses the different aspects of the HTML script content.
… HTML provides 2 mechanisms: specific backslash escapes in HTML comments, or HTML entities
… Benjamin proposed to remove the comments, to keep it valid JSON, consistently with the declared content-type.
Benjamin Young: it’s similar to injecting HTML tags in a <textarea>, without breaking the textarea.
Rob Sanderson: to be sure i understand, the issue is if you have: <script>{"label": "

@iherman
Copy link
Member

iherman commented Dec 8, 2018

This issue was discussed in a meeting.

  • RESOLVED: close #97 as fixed with recent merges; other issues raised in #100
View the transcript 4.1. Remove the need for wrapping comment-open/comment-close text in data blocks
Benjamin Young: #97
Gregg Kellogg: most of these are related to PRs just discussed, but not all
Gregg Kellogg: #96
Benjamin Young: current draft talks now about html entities for escaping
Gregg Kellogg: given that it has to be valid json-ld, how do we deal with escaped entities
… leaves us with problem of how to represent <script> tags and comments in json?
… so we could close 97 and leave 100 for further discussion
Benjamin Young: one option is to mark propose closing and discuss more later
Gregg Kellogg: DanBri involved and noted in discussion (of this or another related issue 100)
Proposed resolution: close #97 as fixed with recent merges; other issues raised in #100 (Benjamin Young)
Gregg Kellogg: +1
David Newbury: +1
Tim Cole: +1
Benjamin Young: +1
Ivan Herman: +1
Resolution #2: close #97 as fixed with recent merges; other issues raised in #100

@BigBlueHat
Copy link
Member Author

Think I missed referencing this issue in the resolution we used last week. I believe the current text in https://w3c.github.io/json-ld-syntax/#restrictions-for-contents-of-json-ld-script-elements settles this nicely, fwiw, so closing as I believe it's both fixed and we had consensus to match. 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants