JSON-LD Working Group Telco — Minutes
Date: 2018-11-30
See also the Agenda and the IRC Log
Attendees
Present: Gregg Kellogg, Benjamin Young, Tim Cole, Pierre-Antoine Champin, Rob Sanderson, Ivan Herman, Jeff Mixter, David Lehn
Regrets: Adam Soroka
Guests:
Chair: Benjamin Young
Scribe(s): Pierre-Antoine Champin, Benjamin Young
Content:
- 1. approval of last week’s minutes
- 2. Announcements
- 3. Work mode overview: Editorial Drafts, Pull Requests, Discussions, and Resolutions
- 4. Additional Editor(s)?
- 5. Recent Changes/Merges (by way of quick explanation and awareness)
- 6. Pending PRs
- 7. Issues
- 8. Resolutions
1. approval of last week’s minutes
Benjamin Young: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-11-16-json-ld
Proposed resolution: approve last weeks minutes (Benjamin Young)
Benjamin Young: +1
Gregg Kellogg: +1
Pierre-Antoine Champin: +1
Rob Sanderson: +0 (Absent)
Ivan Herman: +1
Resolution #1: approve last weeks minutes
2. Announcements
Benjamin Young: 2019 Spring Face-to-Face - February 7-8 (Thursday & Friday) in Washington, DC
Benjamin Young: we have a F2F meeting scheduled in Washington DC, at the Smithonian
Rob Sanderson: Thanks in absentia to Adam :)
Benjamin Young: Adam has confirmed the building
Ivan Herman: how final is that? can we book tickets already?
Benjamin Young: I will check with Adam today
Gregg Kellogg: please also ask him for recommendations for lodging
Rob Sanderson: is there a wikipage for registering for the F2F?
Ivan Herman: I will set up a google doc
3. Work mode overview: Editorial Drafts, Pull Requests, Discussions, and Resolutions
Benjamin Young: there was an email from Greg about how we should handle the changes in the ED
… any PR with apparent consensus on github is merged,
… marking some of them as “at risk” if they need more discussion.
Gregg Kellogg: as an editor’s draft, it reflects my understanding of the consensus of the group.
… So my merging PR does not make those changes official,
Rob Sanderson: +1
Gregg Kellogg: so it should not automatically close the issue (which is what Github does).
Rob Sanderson: Sounds good to me. Connection is super terrible, apologies
4. Additional Editor(s)?
Benjamin Young: As the only editor, Gregg has difficulties to keep track with all the issues.
Pierre-Antoine Champin: that’s a task I would be interested in
… that being said, I’ve only recently joined the group
… so I’m afraid I may not be the most relevant person at the moment to do that
… but if you think I’d be “better than nothing” than I’m happy to help
… I do have experience as an editor
… it was a document that was in the LDP WG
… and have been a member of several WG’s before
Benjamin Young: +1 to pchampin’s offer to help!
Ivan Herman: +1 to PA
Gregg Kellogg: we need to discuss offline the technical specificities and editorial issues,
… but github is a great help for collaborating on these things.
Jeff Mixter: I do not mind helping out either but I have to admit that I have 0 experience with this type of thing
5. Recent Changes/Merges (by way of quick explanation and awareness)
Benjamin Young: there were 3 PRs merged between the codes
Benjamin Young: Mark blank node property labels as obsolete - https://github.com/w3c/json-ld-syntax/pull/90
Benjamin Young: Improve keyword descriptions - https://github.com/w3c/json-ld-syntax/pull/92
Benjamin Young: Html base - https://github.com/w3c/json-ld-syntax/pull/93
Gregg Kellogg: aside note: there has been some heated debate on the SemWeb mailing list about bnodes as properties
… but I think we should stick to strict RDF 1.1 and see what happens
6. Pending PRs
6.1. Add example and description for issue #56
Benjamin Young: https://github.com/w3c/json-ld-syntax/pull/95
Gregg Kellogg: this one is just addressing a request from ivan,
… to add examples about unexpected behavior of term expansion
… regarding vocab vs. document’s IRI
6.2. Remove the need for wrapping comment-open/comment-close text in data blocks
Benjamin Young: https://github.com/w3c/json-ld-syntax/pull/97
Benjamin Young: I submitted that one: the goal is to force the content of the script tag to be valid JSON.
… So we don’t recommend to embed the content in XML comments,
… but avoid strings in the JSON that would break the HTML parsing.
7. Issues
7.1. Base used to resolve relative URIs to absolute URIs in HTML5 data-blocks (TAG issue)
Benjamin Young: https://github.com/w3ctag/design-reviews/issues/312
Benjamin Young: this one does have merged text already; but this issue with the TAG is still open.
… We don’t need to discuss it today, but the TAG wants to discuss this with us eventually.
… The idea would be to better integrate JSON-LD into the DOM.
Gregg Kellogg: I think the main topic of our issue is addressed: use the DOM base to resolve relative IRIs.
Benjamin Young: are there other issues? we have to give feedback to the TAG.
Gregg Kellogg: https://github.com/w3ctag/design-reviews/issues/312
Rob Sanderson: +1 to close and make new at-risk-ness issue
Gregg Kellogg: we should close this and open a new one to track the risk aspects in the text we have.
Benjamin Young: we need to have the call with the TAG, that’s a rare thing.
Rob Sanderson: As then they can see what our solution is, rather than what we propose it will be
Rob Sanderson: And have something concrete to react to
Benjamin Young: I will check the process about WD, but I would not want to wait for that to meet them.
7.2. JSON-LD script elements (data blocks) MUST only contain valid JSON
Benjamin Young: https://github.com/w3c/json-ld-syntax/issues/96
Benjamin Young: issue related to https://github.com/w3c/json-ld-syntax/pull/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": "<!--"}</script>
?
… No, thankfully, but I see the point
… And then the pain of double and quadruple escaping
… Thanks for the explanation. Result = :(
Gregg Kellogg: I want to be able to copy-paste the content of the script tag into, e.g., the JSON-LD playground.
Ivan Herman: the schema.org pages is full of examples, but none of them has “pathological” examples re. content tags
… we could try to test their tools and see if they break.
… We could decide this is an author’s problem. JSON-LD in HTML is optional.
… If authors want to do that, they should know they are not on neutral ground,
Rob Sanderson: Related to what ivan said, and I agree with his opinion … Can we ask DanBri to find out what about this in current schema.org usage? There’s doubtless instances of this sort of thing (<!--
etc) in the wild, that they might be able to find (or not) with relative ease?
… and take precautions.
… Someone must have tried to put <script>
in a json-ld block in some attempt to mess with Google :)
Gregg Kellogg: my tool will handle the comments; I don’t think they will render the entity escaping correctly
… We has to check with the structured data tools, and talk with danbri about it.
Benjamin Young: we need to be sure that the authors understand what happens
… and why JSON-LD from an HTML script tag does not behave differently from JSON-LD from a file
Pierre-Antoine Champin: I’m not sure about a detail: what if I put an entity in a script tag?
… from JS code, do I get the entity? or is it unescaped?
Ivan Herman:
"name" : ["my name is <in this>", "<lll>"]
works in the structural testing tool
Ivan Herman: both these thinks work as expected
… both the “<” and the “<” appear as “<”
Benjamin Young: that’s what you see, but the raw result may be different
Gregg Kellogg: A better test might be
”name”: [“</script>”]
Ivan Herman: exploring how https://search.google.com/structured-data/testing-tool handles things
Gregg Kellogg: I think you’re right that they’re unescaping them
… but these are such rare cases
Rob Sanderson: +1 to “It hurts when I do this” … “Don’t do that then”
Gregg Kellogg: maybe we get rid of this whole notation, by saying you MUST only embed text which can be extracted via the HTML DOM
Benjamin Young: doesn’t that place the constraint on all of JSON-LD that it could never contain </script>
Gregg Kellogg: yes. that
David I. Lehn: i’d like to note you are furthering the difficulty in writing obfuscated json-ld.
Rob Sanderson: Potentially also removing an attack vector, security wise
… But not HTML in JSON(-LD or not) in HTML
… +1 to it being addressed
Rob Sanderson: Bye!
8. Resolutions
- Resolution #1: approve last weeks minutes