JSON-LD Working Group Telco — Minutes

Date: 2019-12-13

See also the Agenda and the IRC Log

Attendees

Present: Gregg Kellogg, Rob Sanderson, Pierre-Antoine Champin, Harold Solbrig, Ivan Herman, Benjamin Young, Tim Cole, David I. Lehn

Regrets: Dave Longley, Adam Soroka

Guests:

Chair: Rob Sanderson

Scribe(s): Pierre-Antoine Champin

Content:

1. Scribe Selection

2. Approve minutes of previous call

Rob Sanderson: PROPOSAL Approve minutes of previous call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-12-06-json-ld

Rob Sanderson: +1

Gregg Kellogg: +1

Benjamin Young: +1

Harold Solbrig: +1

Pierre-Antoine Champin: +1

Ivan Herman: +1

David I. Lehn: +1

Resolution #1: Approve minutes of previous call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-12-06-json-ld

3. Announcements

Rob Sanderson: CR was published!

Rob Sanderson: https://www.w3.org/TR/json-ld11/

Gregg Kellogg: https://www.w3.org/TR/json-ld/ now points to 1.1 CR

Rob Sanderson: thanks to everyone invoved in the process.

Gregg Kellogg: TR/json-ld/ also now points to the CR

Gregg Kellogg: https://www.w3.org/TR/json-ld1/

Gregg Kellogg: TR/json-ld1/ points to the 1.0 REC
… I would have expected TR/json-ld10/, but it does not work

David I. Lehn: we should be careful what json-ld.org points to as “recommendations”
… also TR/json-ld-api/ returns a 404

Ivan Herman: I sent a mail to emphasize how we should process changes now.
… editorial changes are ok, as long as we give the correct flag to echidna.
… gkellogg, you should take care of that, I am not comfortable with changing your configuration.

Gregg Kellogg: - curl “https://labs.w3.org/echidna/api/request” –data “url=$URL” –data “decision=$DECISION” –data “token=$TOKEN”

Ivan Herman: See CR publication with Echidna

Ivan Herman: if we have more substantial changes, we must again submit to the director
… and such changes must be thoroughly documented

Gregg Kellogg: every PR for an issue must refer to a resolution (by email or on a call)

Ivan Herman: we had some discussion offline about writing a blog post;
… I think that this should be done by the chairs

Gregg Kellogg: I have a text ready, I can put it on my blog

Benjamin Young: I am also happy with publishing gkellogg’s text

Action #1: make google doc to co-edit, to be posted next week (Benjamin Young)

Rob Sanderson: let’s copy gkellogg’s text in a google doc and work on it,
… and get it published by monday

4. Issues

4.1. XHTML vs HTML

Rob Sanderson: https://github.com/w3c/json-ld-api/issues/244

Rob Sanderson: gkellogg objected that XHTML is not an active spec
… but the author or the issue noted that application/xhtml+xml is one of the content-types specified for HTML 5.2

Ivan Herman: my initial reaction was the same as gkellogg, but the latest argument is compelling

Rob Sanderson: https://www.w3.org/TR/json-ld11-api/#dfn-html-script-extraction

Ivan Herman: but since both content-types are for the same format,
… all we have to do is add “or ‘application/xhtml+xml’” whenever we mention ‘text/html’
… Also, epub still refers to XHTML.

Gregg Kellogg: my concern was that XHTML 1.0 would use different encoding for scripts.
… If this is just about accepting ‘application/xhtml+xml’ for HTML5, this is not a problem.
… I would rather not wait on this thing. It is easy to get lost.

Ivan Herman: if we want to republish something between now and end of CR,
… this is borderline to substantial change.

Gregg Kellogg: we will have the same problems with other issues.

Ivan Herman: many things that will come up are hopefully editorial.

Rob Sanderson: given the other issues, we will probably want to update the CR.
… considering this is day 1, and we already have a list of issues and associated PRs.

Ivan Herman: we are not talking about going back to WD.
… but we need to go to the director again if we make non-substantial changes.

Gregg Kellogg: last week we resolved that changes in the text of the algorithms
… that does not change the result of any test suite,

Gregg Kellogg: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-12-06-json-ld#resolution3

Gregg Kellogg: would be considered editorial.

Rob Sanderson: but surely we were referring the existing test suite

Gregg Kellogg: dlehn proposed to add new tests, to address some corner cases
… I thing resolution3 is about “not changing the result of any existing test”

Proposed resolution: We accept that syntax and api should also refer to XHTML where they refer to text/html (Rob Sanderson)

Gregg Kellogg: +1

Ivan Herman: +1

Rob Sanderson: +1

Harold Solbrig: +1

Pierre-Antoine Champin: +1

David I. Lehn: +1

Benjamin Young: +1

Resolution #2: We accept that syntax and api should also refer to XHTML where they refer to text/html

4.2. JSON-LD featuring JSON featuring JSON-LD test

Rob Sanderson: https://github.com/w3c/json-ld-api/issues/237

David I. Lehn: a literal JSON can contain JSON-LD (e.g. a @context key)
… we need to make sure that processors do not try to process that

Rob Sanderson: this is only editorial; the text already says “do not touch this”

Proposed resolution: Accept test for JSON-LD embedded in JSON to test suite (no editorial action) (Rob Sanderson)

Rob Sanderson: +1

David I. Lehn: how should we process such issues?

Ivan Herman: +1

Tim Cole: +1

Ivan Herman: I don’t think we should use meeting time for this

Harold Solbrig: +1

David I. Lehn: +1

Pierre-Antoine Champin: +1

Resolution #3: Accept test for JSON-LD embedded in JSON to test suite (no editorial action)

Gregg Kellogg: +1

Rob Sanderson: but we need to point to a resolution in the PR solving the issue

4.3. Return of the adding an entry step

Rob Sanderson: https://github.com/w3c/json-ld-api/issues/243

Rob Sanderson: https://w3c.github.io/json-ld-api/#expansion-algorithm

Rob Sanderson: in the expansion algorithm, step 13.4.4.4 and 13.4.4.5
… there is the same text repeated
… looks like a copy-paste error

Proposed resolution: remove repeated text from expansion 13.4.4.4 (Rob Sanderson)

Gregg Kellogg: +1

Harold Solbrig: +1

Rob Sanderson: +1

Tim Cole: +1

David I. Lehn: +1

Pierre-Antoine Champin: +1

Benjamin Young: +!

Benjamin Young: +1

Resolution #4: remove repeated text from expansion 13.4.4.4

4.4. @graph, @set

Rob Sanderson: https://github.com/w3c/json-ld-api/issues/242

Rob Sanderson: "@container": ["@graph", "@set"] is used in a test, but the text of the algorithm implies that it is illegal

Gregg Kellogg: this is an ommision in the algorithm in the list of things allowed with @graph
… the normative section of the syntax does allow this combination

Gregg Kellogg: http://localhost:8000/?specStatus=CR&publishDate=2019-12-12#expanded-term-definition

Pierre-Antoine Champin: https://www.w3.org/TR/json-ld11/#expanded-term-definition

Rob Sanderson: > If the expanded term definition contains the @container keyword, its value MUST be either @list, @set, @language, @index, @id, @graph, @type, or be null or an array containing exactly any one of those keywords, or a combination of @set and any of @index, @id, @graph, @type, @language in any order

Rob Sanderson: so the API and Syntax documents are out of sync

Gregg Kellogg: there was examples specifically added about it

Proposed resolution: Update api Create Term Definition step to allow the set of combinations from syntax 9.15.1 (Rob Sanderson)

Gregg Kellogg: +1

Rob Sanderson: +1

David I. Lehn: +1

Ivan Herman: 0

Tim Cole: +1

Harold Solbrig: +1

Benjamin Young: +1

Pierre-Antoine Champin: +1

Resolution #5: Update api Create Term Definition step to allow the set of combinations from syntax 9.15.1

4.5. Create Term Definition 16.1 needs more indents

Rob Sanderson: https://github.com/w3c/json-ld-api/issues/241

Gregg Kellogg: we added some text in 16.1 to retain the information that @id has value null

Proposed resolution: Add to 16.1 that the following substeps should be skipped (Rob Sanderson)

Gregg Kellogg: in my code, the following substeps are skipped

Proposed resolution: Add to 16.1 that the following substeps should be skipped if the test for null is true (Rob Sanderson)

Gregg Kellogg: +1

Rob Sanderson: +1

Pierre-Antoine Champin: +1

Harold Solbrig: +1

Tim Cole: +1

Ivan Herman: +1

Benjamin Young: +1

David I. Lehn: +1

Resolution #6: Add to 16.1 that the following substeps should be skipped if the test for null is true

4.6. Create Term Definition 16.5 should set defined?

Rob Sanderson: https://github.com/w3c/json-ld-api/issues/245

Gregg Kellogg: when a term has the form of a CURIE, it is possible that the prefix has not yet been defined
… so we recursively call “expand IRI”;
… we keep track of defined terms, this should be updated accordingly
… also, we should have that it should be resolved against the vocabulary

Proposed resolution: Add to Create Term Definition 16.5 that defined should be set to True, and that it should be resolved as vocabulary relative by adding the appropriate parameter (Rob Sanderson)

Gregg Kellogg: +1

Rob Sanderson: +1

Benjamin Young: +1

Pierre-Antoine Champin: +1

Ivan Herman: +1

Harold Solbrig: +1

Tim Cole: +1

Resolution #7: Add to Create Term Definition 16.5 that defined should be set to True, and that it should be resolved as vocabulary relative by adding the appropriate parameter

4.7. Type-scoped context propagation

Rob Sanderson: https://github.com/w3c/json-ld-api/issues/246

Gregg Kellogg: when a typed-scoped context is encountered,
… define context is called; the parameters passed to it are wrong
… the ‘propagate’ parameter should be ‘false’, but the default value ‘true’ is currently used
… The good news is that we do have tests for this corner case.
… The intention is clear.

Proposed resolution: Add to Expansion 11.2 that it should pass false for the propagate option for type-scoped contexts (Rob Sanderson)

Gregg Kellogg: +1

Rob Sanderson: +1

Benjamin Young: +1

Harold Solbrig: +1

Pierre-Antoine Champin: +1

Tim Cole: +1

Resolution #8: Add to Expansion 11.2 that it should pass false for the propagate option for type-scoped contexts

Ivan Herman: +1

5. Recursive contexts (hsolbrig)

Harold Solbrig: we discovered that in our use cases, we have a lot of recursive contexts.
… And I though I read that those were not allowed,
… but couldn’t find it in the syntax document.
… So if context A references context B, and context B references A, what should happen?

Gregg Kellogg: step 5.2.3 explictly says that a context previously dereferenced should not be dereferenced again.

Rob Sanderson: Previous resolution - https://github.com/w3c/json-ld-api/issues/14

Harold Solbrig: the playground complained about it last week. So that’s a bug in the playground?

Gregg Kellogg: yes

David I. Lehn: about the playground, we just updated it to a new version,
… changin how contexts are loaded.
… That’s probably why you saw a change.
… The new version passes all the tests.
… May be some new test is needed here?

Harold Solbrig: we had a very simple example, with a context referencing itself.

Gregg Kellogg: I’ll check if we don’t already have a test for that.

David I. Lehn: can we sum up which URLs should be pointed to in json-ld.org?

Ivan Herman: starting from CR, the “latest” URL points to CR

Gregg Kellogg: I don’t think we should point anyone to 1.0 now

David I. Lehn: https://www.w3.org/TR/json-ld-api/ currently returns a 404

Gregg Kellogg: it probably tries to redirect to https://www.w3.org/TR/json-ld-api11/, but we named it https://www.w3.org/TR/json-ld11-api/

David I. Lehn: what about TR/json-ld-syntax?

Gregg Kellogg: it should not exist…

Ivan Herman: https://www.w3.org/TR/json-ld/ https://www.w3.org/TR/json-ld-api/ https://www.w3.org/TR/json-ld-framing/

Gregg Kellogg: but if it has always been here, we should not mess with it

Gregg Kellogg: https://www.w3.org/TR/json-ld-syntax/

Ivan Herman: the three URLs above should work, right?
… the middle one does not work, which is a bug

Gregg Kellogg: https://www.w3.org/TR/json-ld-api1/

Gregg Kellogg: the link above should not exist either

Gregg Kellogg: https://www.w3.org/TR/json-ld1-api/

Ivan Herman: I’ll contact the webmaster right now

6. Adjourn

7. Resolutions

8. Action Items