JSON-LD Working Group Telco — Minutes

Date: 2018-12-07

See also the Agenda and the IRC Log

Attendees

Present: Benjamin Young, Gregg Kellogg, Ivan Herman, Adam Soroka, Pierre-Antoine Champin, Tim Cole, David Lehn, David Newbury

Regrets: Rob Sanderson, Jeff Mixter

Guests:

Chair: Benjamin Young

Scribe(s): Tim Cole

Content:

Benjamin Young: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-11-30-json-ld

1. Approve Minutes

Benjamin Young: Any questions or corrections?
… it doesn’t say what group Telco these are, also missing chair name

Ivan Herman: I will take care of it

Benjamin Young: Chair was me last week

2. Announcements

Benjamin Young: 2019 Spring Face-to-Face - February 7-8 (Thursday & Friday) in Washington, DC

Adam Soroka: we have location and rooms, will get that out very soon
… we got a room in the Smithstonian castle
… will get recommendations about hotels, but location is downtown DC on National Mall

Ivan Herman: I have prepared a file for f2f
… so Adam, you can put info in this google doc

Ivan Herman: https://docs.google.com/document/d/11agKfDU1vTjyKBI_ytLBYFChFCqEfFePNVposnmSW_8/edit?usp=sharing -> F2F meeting page

3. Call schedule for the remainder of 2018

Benjamin Young: As far as I know we have 14 Dec., but do we need either of the next 2 weeks (21 & 28)?
… I will be unavailable those 2 weeks
… does anyone need a call on either of those days?

Gregg Kellogg: May not be available either date. Not sure yet.

Benjamin Young: sounds like we should skip 21 & 28 and restart on 4 January

Ivan Herman: do we keep 4 January?
… let’s do 4th, drop 28 dec and not sure about 21 dec

Pierre-Antoine Champin: for what it’s worth, I’ll probably be unavailable on the 21; and surely on the 28

Benjamin Young: will query the list about 21 dec and 4 jan

4. Recent Changes / Merges

Benjamin Young: Greg please summarize these

Gregg Kellogg: https://github.com/w3c/json-ld-syntax/issues/56

Gregg Kellogg: issue 56 - this was looking for examples to indicate unexpected behavior when type is a vocab
… i think ball was in Ivan’s court whether the examples were sufficient
… we are not closing the issue until after the PR, so question is whether we are ready to close
… we added 2 examples
… next issue is 77, disambiguate uses of @type
… Webex seems to have some problems with this meeting, especially if changing focus on my computer
… we discussed adding @datatype, instead decided to add text around different uses of @type
… are people satisfied with wording?

Gregg Kellogg: use of @none regarding language
… in seeming conflict with requirement that language has to be string, @none didn’t specify
… fixed that wording making clear that @none has to be a string

Benjamin Young: these are tagged proposed closing
… we need to decide if ready to close

Adam Soroka: I wanted to mention the @datatype issue - I’m okay with this, but we may need a gitHub tag for whenever issues about @type comes up
… this will be a way to verify that spec wording update is enough to minimize confusion

Gregg Kellogg: https://github.com/w3c/json-ld-wg/issues/24

Gregg Kellogg: I did raise issue 24 about surfacing the minutes on this topic like we did in Community Group
… could we do this?
… was useful in community group

Ivan Herman: minutes cleanup is done by me, and summarizing each meeting may not be a good idea

Gregg Kellogg: there is a scribe tool that builds summaries and indexes automatically

Benjamin Young: it works on issues and action lists at top/bottom of each meeting minutes

Gregg Kellogg: the good thing is it aggregates all minutes on each issue

Benjamin Young: I will take an action to investigate to see if we can build index of minutes by issue
… I think this is a good idea

Gregg Kellogg: will work with bigbluehat on this since I worked on CG

Benjamin Young: can we close these 3 issues
… 56, 77 and 102 ?

Ivan Herman: can we do a resolution to close these 3 issues?

Proposed resolution: close issues 56, 77, and 102 as having been addressed by recent merges (Benjamin Young)

Ivan Herman: +1

Gregg Kellogg: +1

Tim Cole: +1

Benjamin Young: +1

David Newbury: +1

Pierre-Antoine Champin: +1

Resolution #1: close issues 56, 77, and 102 as having been addressed by recent merges

Benjamin Young: one more propose closing to consider, issue 76
… it’s marked as out of scope.

Gregg Kellogg: no editorial work has been done on this

Benjamin Young: we’ll put on agenda for next meeting (dec 14)

4.1. Remove the need for wrapping comment-open/comment-close text in data blocks

Benjamin Young: https://github.com/w3c/json-ld-syntax/pull/97

Gregg Kellogg: most of these are related to PRs just discussed, but not all

Gregg Kellogg: https://github.com/w3c/json-ld-syntax/issues/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

4.2. Text and tests for using HTML base for embedded JSON-LD

Benjamin Young: https://github.com/w3c/json-ld-api/pull/51

Benjamin Young: this one is about how to resolve urls are resolved, e.g., how html base is used

Gregg Kellogg: https://github.com/w3c/json-ld-syntax/issues/23

Gregg Kellogg: the associated issue is 23, which we have closed
… this does not deal with referencing html for context and that should stay a separate issue

Benjamin Young: does anyone want to write up this other issue - Adam volunteered
… any issues about recent merge

4.3. Text and tests for using HTML base for embedded JSON-LD

Benjamin Young: https://github.com/w3c/json-ld-api/pull/51

4.4. Clarify IRI compaction

Benjamin Young: https://github.com/w3c/json-ld-api/pull/52

Gregg Kellogg: PR 52 resolves issue 75
… based on previous discussion, I did use autoclose on this

Benjamin Young: last chance for anyone to raise questions about this PR

5. Pending PRs

5.1. Clarify that language map values of @none are strings

Benjamin Young: https://github.com/w3c/json-ld-syntax/pull/104

Benjamin Young: hearing none, we will move on

Benjamin Young: 104 is about clarifying the language map and use of @none

Gregg Kellogg: this is like the one discussed earlier
… giving Rob a chance to comment

Benjamin Young: would love people raising questions / comments between calls, but want to provide opportunity on calls as needed
… we need to better relate PRs and issues being closed

6. Issues to be closed

6.1. Handling HTML character references in embedded JSON-LD

Benjamin Young: https://github.com/w3c/json-ld-syntax/issues/100

Benjamin Young: so far most of work has been Greg and Dan

Gregg Kellogg: this is a relatively narrow issue - we should solve by not resolving html entities in the API
… the narrow use case is script tags and comments
… so we should document by clarifying in spec language but not resolving the html entities
… if an html embedded in json (which is inside a script tag) closes the script tag, then rest of json will be treated as body
… in theory you can end up embedding javascript
… I suggest we document and say don’t do this
… and leave browser to defend against this

Benjamin Young: agree this seems not our problem
… people who put end script tag in their json-ld will find that they’ve broken their html
… if people need to escape character entities, they’ll do, but it will become an html issue not our problem
… while we don’t want to avoid edge cases, this still doesn’t seem to be our issue
… but would love to her back from Dan on this
… just add note that you could disrupt html parsing by doing this and leave it at that

Adam Soroka: I don’t want to minimize the security concern, but since this is coming from server side, it seems not as threatening
… not as bad from accepting user input

Gregg Kellogg: I would propose that we close this issue and remove all except a non-normative caution note
… that data block should remain valid
… I don’t anticipate anything different on this from schema.org
… this removes some text from API doc and maybe some changes in syntax document where we currently talk about how to escape

Proposed resolution: close #100 with note about authoring concern related to HTML characters and </script> and remove existingtext on JSON-LD processors handling character encodings (Benjamin Young)

Gregg Kellogg: +1

Tim Cole: +1

Benjamin Young: +1

Ivan Herman: +1

Adam Soroka: +1

David Newbury: +1

Pierre-Antoine Champin: +1

Resolution #3: close #100 with note about authoring concern related to HTML characters and </script> and remove existing text on JSON-LD processors handling character encodings

6.2. Introduce concept of “sealed” contexts

Benjamin Young: https://github.com/w3c/json-ld-syntax/issues/20

Benjamin Young: Digital Bazar has weighed in with more of their use cases that break

Adam Soroka: A meta comment - Digital Bazar has been producing interesting and valuable use cases
… can we get someone from Digital Bazar to join an upcoming call

David I. Lehn: I’m here but not ready to volunteer on this issue

Benjamin Young: We need to get some more time and get additional folks from Digital Bazar
… other thoughts?
… hearing nothing now, please keep working on this issue on GitHub

6.3. Allow @type for @none in Language Maps

Benjamin Young: https://github.com/w3c/json-ld-syntax/issues/91

Benjamin Young: Idea with 91 is that there is no way to fall back to HTML, which international has suggested is best way to deal with language issues

Gregg Kellogg: issue is to allow non-string values, for which a value object without type might be one option, and opening that door allows almost anything
… that ruins the normality, and not sure it helps the use case
… seems you’d be more likely to use either all language tags or all html literals

Ivan Herman: i think you should either close or defer - this issue did come up in pub wg
… their concern is a bit convoluted to talk about
… when I wrote it down, I got a private message that they didn’t really like this solution (right after TPAC)
… pinged them 2 days ago.
… the result may be that in JSON and JSON-LD this issue can not be done perfectly, and we should be cognizant of perfect is the enemy of the good
… title element seems one place where this could come up, but title doesn’t allow html text
… we should avoid being more catholic than the pope

Adam Soroka: mostly agreeing with what’s been said
… a pattern of string, string, string, complex stuff, string, string is not good

Adam Soroka: +1

David Newbury: +1

Adam Soroka: goes against trying to keep json-ld in line with expectations

Pierre-Antoine Champin: I agree that this is a strange use case, but regardless i posted a solution that works in dev playground
… having 2 distinct properties, one accept a string, one a language map

Benjamin Young: similar to Annotation and Social WG for some of their specs

Pierre-Antoine Champin: a little more cumbersome

Proposed resolution: close #91 as wrong solution for the right problem (Benjamin Young)

Adam Soroka: the kind of thing pchampin is offering seems a good option, can we open an issue to generate examples

Ivan Herman: +1

Benjamin Young: +1

Gregg Kellogg: +1

Pierre-Antoine Champin: +1

Adam Soroka: this is a pattern that could be confusing, we should offer best practices

Tim Cole: +1

David Newbury: +1

Adam Soroka: +1

Resolution #4: close #91 as wrong solution for the right problem

Ivan Herman: can I close after transferring comments to issue?

Benjamin Young: yes

Benjamin Young: adjourn

7. Resolutions