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

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>", "&lt;lll&gt;"] 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