JSON-LD Working Group Telco — Minutes

Date: 2019-04-12

See also the Agenda and the IRC Log

Attendees

Present: Benjamin Young, Adam Soroka, Rob Sanderson, Ruben Taelman, Pierre-Antoine Champin, Gregg Kellogg, Ivan Herman, David Newbury, Dave Longley, David I. Lehn, Tim Cole, Jeff Mixter

Regrets: Simon Steyskal

Guests:

Chair: Benjamin Young

Scribe(s): Adam Soroka

Content:

1. Approve minutes of previous call - https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-04-05-json-ld

Benjamin Young: +1

Ivan Herman: +1

Pierre-Antoine Champin: +1

Ruben Taelman: +1

Proposed resolution: approve minutes from last weeks call (Benjamin Young)

Adam Soroka: +1

Gregg Kellogg: +0

Rob Sanderson: +1

Ivan Herman: +1

Resolution #1: approve minutes from last weeks call

2. Additional restriction to @sealed term clearing

Ivan Herman: link: https://github.com/w3c/json-ld-syntax/issues/136

Benjamin Young: Protected Term Definition - https://w3c.github.io/json-ld-syntax/#protected-term-definitions

Benjamin Young: we’re discussing 136. There are some already-merged PRs and there are some tests
… this topic is our exclusive focus for today
… because this would really help VCWG
… this piece of work is valuable to support them NOT taking JSON-LD out of the spec
… let’s start with a summary of the editorial work

Gregg Kellogg: I think there are some PRs that have been completed on the syntax side

Pierre-Antoine Champin: all related PRs have been merged

Gregg Kellogg: I think we still need to add the mechanism that would disallow unsealing via @context:null

Dave Longley: we’re just looking exactly what gkellogg said
… what’s currently there would allow for the protection to be removed merely via @context:null anywhere in the doc
… which doesn’t do what we actually need from the feature
… the point is to be able to call out terms so that people using the context can be minimal with processing on those terms
… with but one little change, we can accomplish that
… just by restricting to a scoped context
… that will provide the needed assurance

Pierre-Antoine Champin: to be clear, the @context:null could be on any protected definition?

Dave Longley: correct
… should not complicate implementations

Rob Sanderson: if a @context:null is encountered elsewhere than in a property-scoped context, it changes from wiping out everything to just wiping out non-protected terms?

Dave Longley: no, that should be an error under our change
… because that would be trying to remove protection illegally

Rob Sanderson: that seems backwards-incompatible
… it changes the meaning of @context:null

Dave Longley: well, no, because there were never protected terms before

Rob Sanderson: 2nd opinion would be desirable

Gregg Kellogg: what we had done before was not throw errors but issue warnings

David I. Lehn: protectedMode and tests here: https://github.com/w3c/json-ld-api/pull/69

Gregg Kellogg: dlehn has an issue for a “protected mode” flag which would switch between errors and warnings
… are you putting those together or something totally new?

Dave Longley: we’ve implemented both, and we’re okay with either, but we think that throwing an error would be cleaner, but we can default to the warning
… and in that case, the protected terms would just not be redefined
… we have tests for either case
… but we thought that defaulting to error would be cleaner

Pierre-Antoine Champin: just wanted to point out that property-scoped context aren’t in 1.0
… @context:null in a property-scoped definitions simply doesn’t exist now,
… so we can’t break extant JSON-LD
… [then changes his mind]

Gregg Kellogg: the only way to provoke this is via a protected term, which didn’t exist in 1.0
… so you couldn’t produce this error that way
… I think that adding flags to the API is waffling
… we should choose a party to go to
… in my own processor I run testing in a “validation” mode which is strict
… this might be such a thing
… but for conformance, maybe we should just pick a road here

Rob Sanderson: Here’s when it breaks 1.0: { @context: [ "1.1-context-with-protected", "existing-´1.0-context-with-null"] ... }

Rob Sanderson: if the intent is that extant 1.0 contexts work as written
… then adding “protected” that can’t be reset via @context:null
… won’t work if a 1.0 context began with @context:null but is used at a point where protected terms are in scope

Gregg Kellogg: it used to be that we run in 1.0 until we see a marker for 1.1, but we now start in 1.1

Benjamin Young: current processing model triggering definition https://w3c.github.io/json-ld-syntax/#dfn-processing-mode

Rob Sanderson: so 1.0 contexts still work as expected and danbri won’t come gunning for us?
… or not?
… are we going to get objections from Google or MS ?
… if we can put this into the set of allowable incompatibilities
… I won’t stand in the way

Ivan Herman: to prepare for a possible objection, is it worth to add a note to the document making that clear?

Rob Sanderson: +1 from me to calling it out specifically

Gregg Kellogg: to say that this is a 1.1 feature?

Ivan Herman: question may come up, and we can preempt them in this case
… either in the spec or the best practices doc

Benjamin Young: if it risks a formal objection we should put it in the docs

Gregg Kellogg: it’s not necessary to qualify generating an error if the attempt to clear out the context with a protected-mode term in scope for 1.1.

Adam Soroka: [and I lost the end of the thought]

Gregg Kellogg: that might be a point at which we could add a note
… that this error cannot be generated from a proc running in 1.0 mode

David Newbury: when we’re talking about 1.0 v 1.1 mode for compatibility

Adam Soroka: .. we’re talking about the doc being processed

David Newbury: not the context of the context

Gregg Kellogg: documents aren’t 1.0 or 1.1
… the processing is 1.0 or 1.1
… contriolled by @version in the context

Benjamin Young: the @version definition https://w3c.github.io/json-ld-syntax/#h-note-1

Gregg Kellogg: but that can happen in any context

David Newbury: right, but that doesn’t change the context, right, just its interpretation in the context (different use of the word) in which it is being processed?

Rob Sanderson: I understand the pattern of restricting to property-scoped contexts
… but is that the limit?

Dave Longley: it’s acceptable to put protected type-scoped definition
… but you can’t clear terms there
… that would lead to multiple inheritance
… think of protected terms as a “base class” for anything in the doc
… appending a type to any node would change the semantics
… which misses the whole point, which is to make processing easier

Rob Sanderson: we can’t limit the types assigned to a resource
… and type-scoped defns in this way could lead to collisions.

Gregg Kellogg: I implied something like this in an earlier version
… what would happen is
… when you expand based on a property which is a protected term
… that is when you look for embedded context associated with that term
… . that is when you could see @contxt:null
… you detect that by calling expansion with some option that includes the term at hand

Dave Longley: we ran into no gotchas
… we did it with both warning and error
… it was simple, the hardest part was the warning
… tracking when you can clear protection or not was actually fairly simple

Gregg Kellogg: ready with a Pull Request?

Dave Longley: not quite, but quite close

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

Benjamin Young: Add @protected tests and a protectedMode flag.

Dave Longley: yeah, that looks like the right PR

David I. Lehn: the related is implementation PR is here: https://github.com/digitalbazaar/jsonld.js/pull/289

Pierre-Antoine Champin: I can edit the current section on “protected” in the syntax document, to reflect those changes

Dave Longley: that PR should cover all the bases
… clearing things when you should be bale to, when you shouldn’t…

Gregg Kellogg: some updates look to be needed
… some test are failing and it’s coming from Digital Bazaar’s repo

Dave Longley: we can move the PR, np

Benjamin Young: this PR has the protected mode warning/error flag on the API
… we can massage that independent of the PR

Ivan Herman: firstly we should formally resolve the issue in a very clear way
… but also we need a statement or something from this WG making it clear that this is a feature that is frozen and will not be removed

Dave Longley: yes, we need that reassurance

Ivan Herman: we have to produce that
… a similar situation (JSON-LD being behind) can happen with WoT WG as well
… they will need the same kind of things
… we could produce a blog
… saying that all features in the document are stable in the sense that
… we don’t expect to remove them
… would that work for you?

Dave Longley: my understanding is that it would

Gregg Kellogg: when we talked about freezing before, I said then that we need to get out a WD
… I don’t think we can point at an editor’s draft for such an assurance
… so what’s the timing for that?

Ivan Herman: for a CR, for which you are running right now
… having a fresh WD from JSON-LD WG should be enough
… but getting to Rec would mean that isn’t enough
… we have a publishing process through which to go, and it could take 2-3 weeks

Dave Longley: We’re already in CR
… 2-3 weeks doesn’t change anything
… we prefer sooner rather than later
… this will help us get through a number of issues

Ivan Herman: and helps you with the discussion you are having with commenters

Rob Sanderson: let’s say we have a WD within 1-2 weeks
… and get the feedback
… then write the blog post saying “No more new features”
… would be 3-4 weeks

Dave Longley: yes, but TBC all we need is “these features won’t be taken out”, not “no new features”

Rob Sanderson: if we do hit timeline issues, we could offer something more than a blog post for VCWG in particular

Dave Longley: a simple statement would be acceptable

Gregg Kellogg: we do need to resolve “warnings vs. errors”

Rob Sanderson: we need to discuss that beforehand

Dave Longley: I don’t want to prevent people from writing nonstandard implementations that use warnings,
… I was concerned by not having this behavior be configurable

Proposed resolution: attempts to override @protected terms will throw an error during processing in 1.1 mode (Benjamin Young)

Adam Soroka: +1

Adam Soroka: me oh, good point

Adam Soroka: [general discussion about how to advance the wording of this propsoal]

Dave Longley: don’t want to confuse people with wording about when you can use @context:null

Gregg Kellogg: also, terms aren’t really changed by that action, they are cleared
… @context:null doesn’t change terms, it clears them

Rob Sanderson: I thought you didn’t need to set @context:null to alter a term

Gregg Kellogg: what if you set a term defintion to null?

Rob Sanderson: we can put that off until later

Rob Sanderson: {"@context": {"protected": {"@id": "something", "@protected": True}, "extension": {"@context": {"protected": {"@id": "something else"}}}

Rob Sanderson: I believe that given our current definitions, that ^^^ would be acceptable
… you should be able to set a term directly to something else

Dave Longley: as long as you are property-scoped, you can wipe out everything, but yes, you could go at only a single term

Gregg Kellogg: and 1.0 does allow setting a single term to null

Proposed resolution: Allow @protected terms to be changed only via property scoped contexts, and not via setting the active context to null (Benjamin Young)

Dave Longley: +1 (of course, setting the context to null within a property scoped context is also allowed)

Gregg Kellogg: +1

Rob Sanderson: +1

Rob Sanderson: we could make that a bit clearer as pointed out by dlongely

Jeff Mixter: +1

Benjamin Young: +1

David Newbury: +1

Ivan Herman: +1

Pierre-Antoine Champin: +1

Tim Cole: +1

Ruben Taelman: +1

David I. Lehn: +1

Adam Soroka: +1

Resolution #2: Allow @protected terms to be changed only via property scoped contexts, and not via setting the active context to null

Adam Soroka: the proposal, just the text; I am on board with the idea

Gregg Kellogg: other than as previously provided

Dave Longley: +1 to Gregg

Dave Longley: +1 to the proposal

Benjamin Young: what we’re saying is that it is indeed an error, not a warning

Ivan Herman: +1

Proposed resolution: Any attempt to change or clear a @protected term results in an error being raised, other than as provided for already (Rob Sanderson)

David Newbury: +1

Gregg Kellogg: +1

Jeff Mixter: +1

Rob Sanderson: +1

Adam Soroka: +1

Dave Longley: +1

Ivan Herman: +1

Tim Cole: +1

Pierre-Antoine Champin: +1

Ruben Taelman: +1

Benjamin Young: +1

David I. Lehn: +1

Resolution #3: Any attempt to change or clear a @protected term results in an error being raised, other than as provided for already

Gregg Kellogg: for the purpose of best time use we should look at issues on the GitHub management console to find what we need to do to get to a new WD

Ivan Herman: different topic?

Benjamin Young: yeah, I have no other issues

3. pushing to WD for @protected; other open issues before feature freeze

Rob Sanderson: link: https://github.com/orgs/w3c/projects/4

Ivan Herman: the only new feature is

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

Rob Sanderson: link: https://github.com/w3c/json-ld-syntax/issues/19

Rob Sanderson: link” https://github.com/w3c/json-ld-framing/issues/29

Adam Soroka: [people work to find tickets]

Rob Sanderson: link: https://github.com/w3c/json-ld-framing/issues/38

Ivan Herman: I think I said that if it gets too complicated, we can forget it

Rob Sanderson: link: https://github.com/w3c/json-ld-syntax/issues/103

Ivan Herman: #38 was discussed and resolved: what happened there?

Benjamin Young: the resolution sonuds editorial

Gregg Kellogg: these can be open issues in a WD
… . feels like too much work

Rob Sanderson: we can say that no more open issue will come

Ivan Herman: we would need a nontrivial extension
… and I am find with closing

Ivan Herman: I will close it after a resolution, just to be correct

Rob Sanderson: propose won’t-fix

Proposed resolution: Defer Framing #38 until a future version (Rob Sanderson)

Rob Sanderson: +1

Ivan Herman: +1

Ivan Herman: wasn’t there some label for deferring to a future version>?

Adam Soroka: +1

Ruben Taelman: +1

Benjamin Young: +1

Jeff Mixter: +1

Pierre-Antoine Champin: +1

Dave Longley: +1

David I. Lehn: +1

Gregg Kellogg: +1

David Newbury: +1

Resolution #4: Defer Framing #38 until a future version

Tim Cole: +1

Ivan Herman: +1

Adam Soroka: [discussion of potential issues to discuss]

Gregg Kellogg: i’d like to defer the issues mentioned in that discussions

Rob Sanderson: bigbluehat: agreed

Benjamin Young: do we need to list all these issues?

Rob Sanderson: don’t think we need to

Pierre-Antoine Champin: I was thinking about property-based indexing
… if the WD is meant to reassure VCWG and WoTWG then shouldn’t that feature be included in it?

Adam Soroka: ivan_ yes, but isn’t it already in?

Gregg Kellogg: is it an open PR?

Pierre-Antoine Champin: yes, but you suggested a significant syntax change

Gregg Kellogg: hopefully we can discuss and decide those on the issue itself, or we will need to discuss it next week

Gregg Kellogg: can we reocrd the specific remaining issues and PRs that merit our attention this week?

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

Gregg Kellogg: what pchampin described as needing discussion

Gregg Kellogg: I see that I approved it

Pierre-Antoine Champin: I think you implemented it!

Gregg Kellogg: let’s keep discussion on that PR

Ivan Herman: there should be a clear list of issues and PRs that are still pending

4. Resolutions