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
- 2. Additional restriction to
@sealed
term clearing - 3. pushing to WD for
@protected
; other open issues before feature freeze - 4. Resolutions
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 aprotectedMode
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
- Resolution #1: approve minutes from last weeks call
- Resolution #2: Allow
@protected
terms to be changed only via property scoped contexts, and not via setting the active context to null - Resolution #3: Any attempt to change or clear a
@protected
term results in an error being raised, other than as provided for already - Resolution #4: Defer Framing #38 until a future version