15:52:57 <RRSAgent> RRSAgent has joined #json-ld
15:52:57 <RRSAgent> logging to https://www.w3.org/2019/04/12-json-ld-irc
15:52:58 <ivan> rrsagent, set log public
15:52:58 <ivan> Meeting: JSON-LD Working Group Telco
15:52:58 <ivan> Chair: bigbluehat
15:52:58 <ivan> Date: 2019-04-12
15:52:58 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Apr/0023.html
15:52:59 <ivan> ivan has changed the topic to: Meeting Agenda 2019-04-12: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Apr/0023.html
15:53:03 <ajs6f> ajs6f has joined #json-ld
15:57:00 <bigbluehat> present+
15:57:12 <rubensworks> rubensworks has joined #json-ld
15:57:49 <ajs6f> prsent+
15:57:53 <ajs6f> present+
15:58:51 <azaroth> present+ Rob_Sanderson
15:59:06 <rubensworks> +present
15:59:10 <rubensworks> present+
15:59:32 <pchampin> present+
16:00:05 <gkellogg> present+
16:00:42 <bigbluehat> scribenick: ajs6f
16:01:15 <ivan_> ivan_ has joined #json-ld
16:01:18 <workergnome> workergnome has joined #json-ld
16:01:42 <ivan_> zakim, who is here?
16:01:42 <Zakim> Present: bigbluehat, ajs6f, Rob_Sanderson, present, rubensworks, pchampin, gkellogg
16:01:45 <Zakim> On IRC I see workergnome, ivan_, rubensworks, ajs6f, RRSAgent, Zakim, azaroth, pchampin, gkellogg, ivan, cwebber2, dlehn_, dlongley, ChristopherA, bigbluehat
16:02:11 <ivan_> Meeting: JSON-LD Working Group Telco
16:02:11 <ivan_> Chair: bigbluehat
16:02:11 <ivan_> Date: 2019-04-12
16:02:11 <ivan_> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Apr/0023.html
16:02:36 <bigbluehat> Topic: Approve minutes of previous call - https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-04-05-json-ld
16:02:48 <bigbluehat> +1
16:02:53 <ivan_> +1
16:02:54 <dlongley2> dlongley2 has joined #json-ld
16:02:56 <pchampin> +1
16:02:57 <rubensworks> +1
16:02:58 <bigbluehat> PROPOSAL: approve minutes from last weeks call
16:03:00 <ajs6f> +1
16:03:00 <gkellogg> +0
16:03:01 <azaroth> +1
16:03:04 <ivan_> +1
16:03:13 <ivan_> resolved:  approve minutes from last weeks call
16:03:14 <bigbluehat> RESOLVED: approve minutes from last weeks call
16:03:23 <bigbluehat> Topic: Announcements / Reminders
16:03:33 <dlehn_> present+
16:03:43 <dlehn> present+
16:03:48 <timCole> timCole has joined #json-ld
16:04:04 <bigbluehat> Topic: Issues
16:04:18 <bigbluehat> Subtopic: Additional restriction to `@sealed` term clearing - https://github.com/w3c/json-ld-syntax/issues/136
16:04:22 <workergnome> present+
16:04:49 <ivan_> link: https://github.com/w3c/json-ld-syntax/issues/136
16:05:21 <ivan_> present+ dlongley
16:05:48 <ajs6f> bigbluehat: we're discussing 136. There are some already-merged PRs and there are some tests
16:05:48 <timCole> present+ Tim_Cole
16:06:00 <ajs6f> ... this topic is our exclusive focus for today
16:06:08 <ajs6f> ... because this would really help VCWG
16:06:31 <ajs6f> ... this piece of work is valuable to support them _NOT_ taking JSON-LD out of the spec
16:06:46 <ajs6f> ... let's start with a summary of the editorial work
16:07:26 <ajs6f> gkellogg: I think there are some PRs that have been completed on the syntax side
16:07:45 <ajs6f> pchampin: all related PRs have been merged
16:08:11 <ajs6f> gkellogg: I think we still need to add the mechanism that would disallow unsealing via @context:null
16:08:15 <bigbluehat> Protected Term Definition - https://w3c.github.io/json-ld-syntax/#protected-term-definitions
16:08:33 <ajs6f> dlongley: we're just looking exactly what gkellogg said
16:08:58 <ajs6f> ... what's currently there would allow for the protection to be removed merely via @context:null anywhere in the doc
16:09:06 <ajs6f> ... which doesn't do what we actually need from the feature
16:09:32 <ajs6f> ... the point is to be able to call out terms so that people using the context can be minimal with processing on those terms
16:09:43 <ajs6f> ... with but one little change, we can accomplish that
16:09:54 <ajs6f> ... just by restricting to a scoped context
16:10:05 <pchampin> q+
16:10:10 <bigbluehat> ack pchampin
16:10:13 <ajs6f> ... that will provide the needed assurane
16:10:39 <ajs6f> pchampin: to be clear, the @context:null could be on any protected definintion?
16:10:42 <ajs6f> dlongley: correct
16:10:49 <ivan_> regrets+ simonstay
16:10:55 <azaroth> q+ to ask about the effects of null
16:11:00 <bigbluehat> ack ajs6f
16:11:02 <bigbluehat> ack azaroth
16:11:02 <Zakim> azaroth, you wanted to ask about the effects of null
16:11:07 <ajs6f> ... should not complicate impls
16:11:19 <bigbluehat> q+
16:11:46 <ajs6f> azaroth: if a @context:null is encountered elsewhere than in a property-scoped context, it changes from wiping out everything to just wiping out nonprtected terms?
16:11:48 <pchampin> q+
16:11:54 <ajs6f> dlongley: no, that should be an error under our change
16:12:04 <ajs6f> ... because that would be trying to remove protection illegally
16:12:05 <gkellogg> q+ to ask about error generation vs warning generation
16:12:12 <ajs6f> azaroth: that seems backwards-incompatible
16:12:12 <bigbluehat> q-
16:12:31 <ajs6f> ... it changes the meaning of @contet:null
16:12:36 <bigbluehat> ack pchampin
16:12:42 <ajs6f> dlongley: well, no, because there were never protected terms before
16:12:59 <ajs6f> azaroth: 2nd opinion would be desirable
16:13:13 <bigbluehat> ack gkellogg
16:13:13 <Zakim> gkellogg, you wanted to ask about error generation vs warning generation
16:13:17 <bigbluehat> q+ pchampin
16:13:32 <ajs6f> gkellogg: what we had done before was not throw errors but issue warnings
16:13:41 <azaroth> regrets+ simon
16:13:48 <dlehn> protectedMode and tests here: https://github.com/w3c/json-ld-api/pull/69
16:13:59 <ajs6f> ... dlehn has an issue for a "protected mode" flag which would switch between errros and warnings
16:14:19 <ajs6f> ... are you putting those together or something totally new?
16:14:45 <ajs6f> dlongley: we've impled both, and we're okay with either, but we think that throwing an error would be cleaner, but we can default to the warning
16:14:59 <ajs6f> ... and in that case, the protected terms would just not be redefined
16:15:04 <bigbluehat> q?
16:15:07 <ajs6f> ... we have tests for either case
16:15:21 <bigbluehat> ack pchampin
16:15:24 <ajs6f> ... but we thought that defaulting to error would be cleaner
16:15:36 <jeff_mixter> jeff_mixter has joined #json-ld
16:15:40 <ajs6f> pchampin: just wanted to point out that property-scoped context aren't in 1.0
16:15:40 <jeff_mixter> present+
16:15:55 <ajs6f> ... @context:null in a property-scoped defn simply doesn't exist now,
16:16:03 <ajs6f> ... so we can't break extant JSON-LD
16:16:05 <azaroth> q+ re null
16:16:09 <azaroth> q-
16:16:13 <ajs6f> ... [then changes his mind]
16:16:22 <gkellogg> q+
16:16:26 <bigbluehat> ack gkellogg
16:16:47 <ajs6f> gkellogg: the only way to provoke this is via a protected term, which didn't wexist in 1.0
16:16:49 <azaroth> q+
16:17:00 <ajs6f> ... so you couldn't produce this error that way
16:17:09 <ajs6f> ... I think that adding flags to the API is waffling
16:17:18 <ajs6f> ... we should choose a party to go to
16:17:34 <ajs6f> ... in my own processor I run testing in a "validation" mode which is strict
16:17:37 <ajs6f> ... this might be such a thing
16:17:49 <ajs6f> ... but for conformance, maybe we should just pick a road here
16:17:56 <bigbluehat> ack azaroth
16:17:59 <azaroth> Here's when it breaks 1.0:   { @context: [ "1.1-context-with-protected", "existing-´1.0-context-with-null"] ... }
16:18:19 <ajs6f> azaroth: if the intent is that extant 1.0 contaxts work as written
16:18:38 <ajs6f> ... then adding "protected" that can't be reset via @context:null
16:19:05 <ajs6f> ... won't work if a 1.0 context began with @context:null but is used at a point where protected terms are in scope
16:19:39 <ajs6f> gkellogg: 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
16:19:59 <ajs6f> azaroth: so 1.0 contexts still work as expected and danbri won't come guning for us?
16:20:16 <ajs6f> ... or not?
16:20:28 <ajs6f> ... are we going to get objections from Google or MS ?
16:20:39 <ivan_> q+
16:20:47 <workergnome> q+
16:20:49 <bigbluehat> ack ivan_
16:20:52 <ajs6f> ... if we can put this into the set of allowable incompatibiblities
16:20:56 <ajs6f> ... I won't stand in the way
16:21:11 <ajs6f> ivan: to prepare for a possible objection, is it worse to add a note to the document making that clear?
16:21:19 <azaroth> +1 from me to calling it out specifically
16:21:21 <ajs6f> gkellogg: to say that this is a 1.1 feature?
16:21:28 <bigbluehat> current processing model triggering definition https://w3c.github.io/json-ld-syntax/#dfn-processing-mode
16:21:38 <ajs6f> ivan: question may come up, and we can preempt them in this case
16:21:49 <ajs6f> ... either in the spec or the best practices doc
16:21:53 <pchampin> q+
16:22:06 <ajs6f> bigbluehat: if it risks a formal objection we should put it in the docs
16:22:37 <ajs6f> gkellogg: it's not neccessary to qualify generating an error if the attempt to clear out the context with a protected-mode term in scope for 1.1.
16:22:48 <ajs6f> [and I lost the end of the thought]
16:23:00 <ajs6f> ... that might be a point at which we could add a note
16:23:11 <ajs6f> ... that this error cannot be generated from a proc running in 1.0 mode
16:23:13 <bigbluehat> ack workergnome
16:23:32 <ajs6f> workergnome: when we're talking about 1.0 v 1.1 mode for compatiility
16:23:41 <ajs6f> .. we're talking about the doc being processed
16:24:04 <ajs6f> ... not the context of the context
16:24:06 <pchampin> q-
16:24:16 <ajs6f> gkellogg: documents aren't 1.0 or 1.1
16:24:21 <ajs6f> ... the processing is 1.0 or 1.1
16:24:31 <ajs6f> ... contriolled by @version in the context
16:24:32 <bigbluehat> the `@version` definition https://w3c.github.io/json-ld-syntax/#h-note-1
16:24:38 <ajs6f> ... but that can hapen in any context
16:25:05 <bigbluehat> q?
16:25:13 <azaroth> q+
16:25:14 <ivan_> q+
16:25:17 <ajs6f> workergnome: right, but that doesn't chnnage the contet, right, just its interpretation in the context (different use of the word) in which it is being preocessed
16:25:17 <bigbluehat> ack ajs6f
16:25:20 <bigbluehat> ack azaroth
16:25:44 <ajs6f> azaroth: I understand the pattern of restricting to property-scoped contexts
16:25:49 <ajs6f> ... but is that the limi?
16:25:54 <ajs6f> s/limi/limit
16:26:06 <ivan_> q-
16:26:21 <ajs6f> dlongley: it's acceptible to put proteced type-scoped defn
16:26:28 <ajs6f> ... but you can't _clear_ terms there
16:26:50 <ajs6f> ... that would lead to multiple inheritance
16:27:06 <ajs6f> ... think of protected terms as a "base class" for anything in the doc
16:27:17 <gkellogg> q+
16:27:18 <ajs6f> ... appending a type to any node would change the semantics
16:27:31 <ajs6f> ... which misses the whole point, which is to make processing easier
16:27:41 <ajs6f> azaroth: we can't limit the types assigned to a resource
16:27:52 <bigbluehat> ack gkellogg
16:27:58 <ajs6f> ... and type-scoped defns in this way could lead to collisions.
16:28:07 <ajs6f> gkellogg: I impled something like this in an earlier version
16:28:11 <ajs6f> ... what would happen is
16:28:21 <ajs6f> ... when you expand based on a property which is a protected term
16:28:33 <ajs6f> ... that is when you look for embedded contxt associated with that term
16:28:39 <ajs6f> .... that is when you could see @contxt:null
16:28:54 <ajs6f> ... you detect that by calling expansion with some option that includes the term at hand
16:29:13 <ajs6f> dlongley: we ran into no gotchas
16:29:27 <ajs6f> ... we did it with both warning and error
16:29:36 <ajs6f> ... it was simple, the hardest part was the warning
16:29:44 <bigbluehat> q?
16:29:50 <ajs6f> ... tracking when you can clear protection or not was actually fairly simple
16:29:57 <ajs6f> gkellogg: ready with a PR?
16:30:03 <ajs6f> dlongley: not quite, but quite close
16:30:12 <bigbluehat> https://github.com/w3c/json-ld-api/pull/69
16:30:24 <bigbluehat> Add `@protected` tests and a `protectedMode` flag.
16:30:29 <ajs6f> dlongley: yeah, that looks like the right PR
16:30:38 <pchampin> I can edit the current section on "protected" in the syntax document, to reflect those changes
16:30:48 <ajs6f> dlongley: that PR shold cover all the bases
16:30:57 <dlehn> the related js implementation PR is here: https://github.com/digitalbazaar/jsonld.js/pull/289
16:31:02 <ajs6f> ... clearing things when you should be bale to, when you shouldn't...
16:31:10 <ajs6f> gkellogg: some updates look to be needed
16:31:21 <ajs6f> ... some test are failing and it's coming from Digital Bazaar's repo
16:31:26 <bigbluehat> q?
16:31:29 <ajs6f> dlongley: we can move the PR, np
16:31:42 <ivan_> q+
16:31:51 <ajs6f> bigbluehat: this PR has the protected mode warning/error flag on the API
16:31:52 <bigbluehat> ack ivan_
16:32:02 <ajs6f> ... we can massage that independent of the PR
16:32:29 <ajs6f> ivan_: firstly we should formally resolve the issue in a very clear way
16:32:46 <ajs6f> ... 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
16:33:01 <ajs6f> dlongley: yes, we need that reassurance
16:33:06 <ajs6f> ivan_: we have to produce that
16:33:31 <ajs6f> ... a similar situation (JSON-LD being behind) can happen with WoT WG as well
16:33:36 <ajs6f> ... they will need the same kind of things
16:33:56 <ajs6f> ... we could [roduce a blog
16:34:00 <gkellogg> q+
16:34:10 <ajs6f> ... saying that all features in the document are stable in the sense that
16:34:13 <bigbluehat> s/[roduce/produce
16:34:14 <ajs6f> ... we don't expect to remove them
16:34:24 <ajs6f> ... would that work for you?
16:34:27 <azaroth> q+ to ask about timing
16:34:32 <ajs6f> dlongley: my understanding is that it would
16:34:45 <bigbluehat> ack gkellogg
16:34:59 <azaroth> q- :)
16:35:03 <ajs6f> gkellogg: when we talked about freezing before, I said then that we need to get out a WD
16:35:21 <ajs6f> ... I don't think we can point at an editior's draft for such an assurance
16:35:26 <ajs6f> ... so wht's the timing for that?
16:35:38 <bigbluehat> s/wht's/what's
16:35:41 <ajs6f> ivan_: for a CR, for which you are running right now
16:35:52 <ajs6f> ... having a fresh WD from JSON-LD WG should be enough
16:36:06 <ajs6f> ... but getting to Rec would mean that isn't enough
16:36:36 <ajs6f> ... we have a publishing process through which to go, and it could take 2-3 weeks
16:36:41 <ajs6f> dlongely: We're already in CR
16:36:56 <ajs6f> ... 2-3 weeks doesn't change anything
16:37:02 <azaroth> q+ to enumerate the time line
16:37:03 <ajs6f> we prefer sooner rather than later
16:37:15 <ajs6f> ... this will help us get through a number of issues
16:37:27 <bigbluehat> ack azaroth
16:37:27 <Zakim> azaroth, you wanted to enumerate the time line
16:37:34 <ajs6f> ivan_: and helps you with the dicsussion you are ahaving with some mysteriously unnamed big comaines
16:37:46 <ajs6f> azaroth: let's say we have a WD within 1-2 weeks
16:37:53 <ajs6f> ... and get the feedback
16:38:03 <ajs6f> ... then write the blog post saying "No more new features"
16:38:14 <ajs6f> ... would be 3-4 weeks
16:38:37 <ajs6f> dlongley: yes, but TBC all we need is "these faetures won't be taken out", not "no new features"
16:38:59 <ajs6f> azaroth: if we do hit timeline issues, we could offer something more than a blog post for VCWG in partocular
16:39:12 <ajs6f> dlongely: a simple statement would be acceptible
16:39:50 <ajs6f> gkellogg: we do need to resolve "warnings vs. errors"
16:40:09 <ajs6f> azaroth: we need to discuss that beforehand
16:41:15 <ajs6f> dlongley: I don't want to prevent people from writing nonstandard impls that use warnings,
16:41:32 <ajs6f> ... I was concerned by not having this behavior be configurable
16:41:35 <bigbluehat> PROPOSAL: attempts to override `@protected` terms will throw an error during processing in 1.1 mode
16:41:43 <ajs6f> +1
16:41:49 <pchampin> q?
16:42:01 <ajs6f> me oh, good point
16:42:56 <ajs6f> [general discussion about how to advnace the wording of this propsoal]
16:44:24 <ajs6f> dlongely: don't want to confuse people with wording about when you can use @context:null
16:44:37 <ajs6f> gkellogg: also, terms aren't really changed by that action, they are cleared
16:44:51 <ajs6f> ... @context:nulll doesn't change terms, it clears them
16:45:15 <ajs6f> azaroth: I thought you didn't need to set @context:null to alter a term
16:45:44 <ajs6f> gkellogg: wht if you set a term defn to null?
16:46:19 <ajs6f> azaroth: we can put that off until ater
16:46:24 <ajs6f> s/ater/later
16:46:33 <azaroth> {"@context": {"protected": {"@id": "something", "@protected": True}, "extension": {"@context": {"protected": {"@id": "something else"}}}
16:46:54 <ajs6f> azaroth: I believe that given our current defns, that ^^^ would be acceptible
16:47:09 <ajs6f> ... you should be able to set a term directly to something else
16:47:31 <ajs6f> dlongely: as long as you are proerpty-scoped, you can wipe out everything, but yes, you could go at only a single term
16:47:41 <ajs6f> gkellogg: and 1.0 does allow setting a single term to null
16:47:42 <bigbluehat> PROPOSAL: Allow @protected terms to be changed only via property scoped contexts, and not via setting the active context to null
16:48:05 <dlongley2> +1 (of course, setting the context to null within a property scoped context is also allowed)
16:48:14 <gkellogg> +1
16:48:21 <azaroth> +1
16:48:21 <ajs6f> azaroth: we could make that a bit clearer as pointed out by dlongely
16:48:23 <jeff_mixter> +1
16:48:25 <bigbluehat> +1
16:48:25 <workergnome> +1
16:48:26 <ivan_> +1
16:48:28 <pchampin> +1
16:48:30 <timCole> +1
16:48:30 <rubensworks> +1
16:48:30 <dlehn> +1
16:48:31 <ajs6f> +1
16:48:38 <bigbluehat> RESOLVED: Allow @protected terms to be changed only via property scoped contexts, and not via setting the active context to null
16:48:58 <ajs6f> the propsoal
16:49:02 <ajs6f> just the text
16:49:06 <ajs6f> I am on board with the idea
16:49:53 <ajs6f> gkellogg: other than as previously provided
16:50:00 <dlongley2> +1 to Gregg
16:50:05 <dlongley2> +1 to the proposal
16:50:08 <ajs6f> bigbluehat: what we're saying is that it is indeed an error, not a warning
16:50:08 <ivan_> +1
16:50:16 <azaroth> PROPOSAL: Any attempt to change or clear a `@protected` term results in an error being raised, other than as provided for already
16:50:18 <workergnome> +1
16:50:19 <gkellogg> +1
16:50:20 <jeff_mixter> +1
16:50:21 <azaroth> +1
16:50:21 <ajs6f> +1
16:50:22 <dlongley2> +1
16:50:22 <ivan_> +1
16:50:23 <timCole> +1
16:50:24 <pchampin> +1
16:50:24 <rubensworks> +1
16:50:25 <bigbluehat> +1
16:50:28 <dlehn> +1
16:50:37 <azaroth> RESOLVED: Any attempt to change or clear a `@protected` term results in an error being raised, other than as provided for already
16:50:50 <gkellogg> q+
16:50:58 <bigbluehat> ack gkellogg
16:51:27 <ajs6f> gkellogg: 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
16:51:34 <ajs6f> ivan_: different topic?
16:51:41 <ivan_> q+
16:51:44 <ajs6f> bigbluehat: yeah, I have no other issues
16:51:48 <bigbluehat> Subtopic: pushing to WD for `@protected`
16:51:49 <azaroth> link: https://github.com/orgs/w3c/projects/4
16:51:52 <bigbluehat> ack ivan_
16:52:12 <ajs6f> ivan_: the only new feature is
16:52:56 <bigbluehat> https://github.com/w3c/json-ld-syntax/issues/19
16:53:14 <ajs6f> ivan_: I think I said that if it gets too complicated, we can forget it
16:53:22 <azaroth> link: https://github.com/w3c/json-ld-syntax/issues/19
16:53:30 <azaroth> link" https://github.com/w3c/json-ld-framing/issues/29
16:53:38 <ajs6f> [people work to find tickets]
16:53:38 <azaroth> link: https://github.com/w3c/json-ld-framing/issues/38
16:53:51 <azaroth> link: https://github.com/w3c/json-ld-syntax/issues/103
16:54:06 <ajs6f> ivan_: #38 was discusssed and resolved: what happened there?
16:54:15 <ajs6f> bigbluehat: the resolution sonds editorial
16:54:39 <ajs6f> gkellogg: these can be open issues in a WD
16:54:46 <ajs6f> .... feels like too much work
16:54:58 <ajs6f> azaroth: we can say that no _more_ open issue will come
16:55:12 <ajs6f> ivan_: we would need a nontrivial extension
16:55:16 <ajs6f> ... and I am find with closing
16:55:36 <ajs6f> ivan_: I will close it after a resolution, just to be correect
16:55:47 <ajs6f> azaroth: propose won't-fix
16:55:47 <azaroth> PROPOSAL: Defer Framing #38 until a future version
16:55:53 <azaroth> +1
16:56:01 <ivan_> +1
16:56:02 <ajs6f> ivan_: wasn't there somelabel for deferring to a future version>?
16:56:04 <ajs6f> +1
16:56:05 <rubensworks> +1
16:56:06 <bigbluehat> +1
16:56:06 <jeff_mixter> +1
16:56:06 <pchampin> +1
16:56:07 <dlongley2> +1
16:56:13 <dlehn> +1
16:56:17 <gkellogg> +1
16:56:21 <workergnome> +1
16:56:31 <azaroth> RESOLVED: Defer Framing #38 until a future version
16:56:32 <timCole> +1
16:56:35 <ivan_> +1
16:57:48 <ajs6f> [discussion of potential issues to discuss]
16:58:20 <ajs6f> gkellogg: i'd like to defer the issues mentioned in that discussions
16:58:31 <ajs6f> azaroth:bigbluehat: agreed
16:58:36 <pchampin> q+
16:58:41 <ajs6f> bigbluehat: do we need to list all these issues?
16:58:46 <bigbluehat> ack pchampin
16:58:47 <ajs6f> azaroth: don't think we need to
16:59:05 <ajs6f> pchampin: I was thinking about property-based indexing
16:59:23 <ajs6f> ... if the WD is meant to reassure VCWG and WoTWG then shouldn't that feature be included in it?
16:59:33 <ajs6f> ivan_ yes, but isn't it already in?
16:59:43 <ajs6f> gkellogg: is it an open PR?
16:59:59 <ajs6f> pchampin: yes, but you suggseted a significant syntax change
17:00:20 <ajs6f> gkellogg: hopefully we can discss and decide those on the issue itself, or we will need to discuss it next week
17:00:45 <ajs6f> gkellogg: can we reocrd the specific remaining issues and PRs that merit our attention this week?
17:00:58 <bigbluehat> https://github.com/w3c/json-ld-syntax/pull/145
17:01:00 <ajs6f> ... what pchampin described as needing discussion
17:01:27 <ajs6f> gkellogg: I see that I approved it
17:01:44 <ajs6f> pchampin: I think you impld it!
17:01:53 <ajs6f> gkellogg: let's keep discssion on that PR
17:02:10 <ajs6f> ivan_: there should be a clear list of issues and PRs that are still pending
17:02:30 <ivan_> rrsagent, draft minutes
17:02:30 <RRSAgent> I have made the request to generate https://www.w3.org/2019/04/12-json-ld-minutes.html ivan_
17:02:30 <ivan_> zakim, bye
17:02:30 <ivan_> rrsagent, bye
17:02:30 <RRSAgent> I see no action items
17:02:30 <Zakim> leaving.  As of this point the attendees have been bigbluehat, ajs6f, Rob_Sanderson, present, rubensworks, pchampin, gkellogg, dlehn_, dlehn, workergnome, dlongley, Tim_Cole,
17:02:30 <Zakim> Zakim has left #json-ld
17:02:33 <Zakim> ... jeff_mixter