16:34:51 <RRSAgent> RRSAgent has joined #json-ld
16:34:51 <RRSAgent> logging to https://www.w3.org/2019/02/22-json-ld-irc
16:34:52 <ivan> rrsagent, set log public
16:34:52 <ivan> Meeting: JSON-LD Working Group Telco
16:34:52 <ivan> Chair: azaroth
16:34:52 <ivan> Date: 2019-02-22
16:34:52 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Feb/0023.html
16:34:52 <ivan> ivan has changed the topic to: Meeting Agenda 2019-02-22: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Feb/0023.html
16:44:15 <azaroth> azaroth has joined #json-ld
16:53:03 <simonstey> simonstey has joined #json-ld
16:55:43 <ivan> present+
16:56:04 <pchampin> pchampin has joined #json-ld
16:57:13 <simonstey> present+
16:57:31 <simonstey> scribe: simonstey
16:57:57 <azaroth> present+ Rob_Sanderson
16:58:33 <gkellogg> present+
16:58:58 <bigbluehat> present+
16:59:05 <dlongley> present+
17:00:29 <ivan> chair: bigbluehat, azaroth
17:00:30 <bigbluehat> Topic: Approve minutes of previous call
17:00:33 <simonstey> https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-02-15-json-ld
17:00:59 <ivan> present+ azaroth, pchampin
17:01:35 <bigbluehat> +1
17:01:39 <gkellogg> +1
17:01:42 <dlongley> +1
17:01:43 <pchampin> +1
17:01:43 <ivan> +1
17:01:43 <azaroth> +1
17:01:43 <simonstey> bigbluehat: any objections? if not +1
17:01:45 <simonstey> +1
17:01:52 <bigbluehat> Topic: Announcements / Reminders
17:01:57 <simonstey> bigbluehat: approved!
17:02:03 <azaroth> regrets+ Jeff_Mixter
17:02:07 <ivan> Resolved: minutes of last week accepted
17:02:29 <bigbluehat> Subtopic: Heading to Candidate Recommendation (CR) - Calling all Implementers
17:02:39 <simonstey> bigbluehat: we are heading towards CR
17:02:52 <simonstey> ... consequently we are looking for as many implementers as we can
17:03:04 <simonstey> ... end of march?
17:03:24 <timCole> timCole has joined #json-ld
17:03:28 <simonstey> ivan: I think we started with the start of march but pushed it back to the end
17:03:46 <simonstey> gkellogg: I think we wanted to wait for the next draft to come out before moving to CR
17:04:10 <ivan> present+ timCole
17:04:23 <simonstey> bigbluehat: azaroth and I wanted to do a blog post on that too
17:04:32 <ivan> zakim, who is here?
17:04:32 <Zakim> Present: ivan, simonstey, Rob_Sanderson, gkellogg, bigbluehat, dlongley, azaroth, pchampin, timCole
17:04:34 <gkellogg> https://w3c.github.io/json-ld-api/tests/
17:04:34 <Zakim> On IRC I see timCole, pchampin, simonstey, azaroth, RRSAgent, Zakim, gkellogg, dlongley, ivan, dlehn, cwebber2, ChristopherA, bigbluehat
17:04:45 <simonstey> gkellogg: link to test description
17:05:02 <simonstey> bigbluehat: I guess the API is the one to implement right?
17:05:04 <gkellogg> https://w3c.github.io/json-ld-framing/tests/
17:05:12 <simonstey> gkellogg: there's also one for framing
17:05:28 <simonstey> bigbluehat: we need 2+ implementations for each feature
17:05:52 <simonstey> azaroth: quick question -> for the distinction between api and syntax
17:06:02 <ivan> q+
17:06:12 <simonstey> ... what if you would implement a total diff. api but still use the correct syntax
17:06:48 <simonstey> ... do we allow for that? or do we only accept if you implement the syntax complying to our api spec?
17:07:11 <bigbluehat> q+ to ask about compacted => expanded => compacted as a possible syntax test
17:07:13 <dlongley> q+ to say we're doing something similar with the VC spec
17:07:29 <bigbluehat> ack ivan
17:07:54 <dlehn> present+
17:08:06 <simonstey> ivan: the way I would present it -> the test suite we have is to some extent a test suite for the syntax too
17:08:22 <simonstey> ... so I wouldn't necessarily tie it to the api only
17:08:56 <simonstey> ... I would expect that the test suite has examples for each feature of the syntax
17:09:00 <dlongley> q-
17:09:18 <simonstey> gkellogg: we certainly have to check our test suites
17:09:45 <simonstey> ... other RDF serialization tests usually don't distinguish between processing and syntax tests
17:09:53 <simonstey> ... exception might be NTriples
17:10:21 <simonstey> ... we also have some negative syntax tests if I recall correctly
17:10:39 <simonstey> ivan: just saying that we have to be careful on how to present this
17:11:18 <simonstey> ... we do have to know whether we have deployment plans for the new features
17:11:40 <simonstey> +q
17:12:16 <simonstey> ... we have introduced quite a few features, have to provide proof to some extent that those are really needed and planned to be implemented
17:12:33 <workergnome> workergnome has joined #json-ld
17:12:36 <azaroth> +1 to Ivan and Gregg
17:12:48 <bigbluehat> ack bigbluehat
17:12:48 <Zakim> bigbluehat, you wanted to ask about compacted => expanded => compacted as a possible syntax test
17:13:16 <simonstey> gkellogg: maybe we should go through the issue tracker and document planned implementations of the various features
17:14:17 <simonstey> bigbluehat: if you roundtrip through compacting, you might be able to proof compliance with respective algorithm
17:14:29 <bigbluehat> ack simonstey
17:14:30 <pchampin> can all compaction/expansion text be run backward? :-)
17:14:55 <azaroth> scribenick: azaroth
17:15:19 <azaroth> simonstey: I was wondering, we said that we like there's proof that features will be implemented, and realized this is related to the syntax document.
17:15:57 <azaroth> ... this is why we have tests and implementation requirements, to provide the proof. But we don't have tests for syntax, so is this why we need to do this?
17:16:18 <azaroth> ivan: An implementation looks at the JSON-LD in general and implements those things, is disjoint from whether it will be used
17:16:35 <azaroth> simonstey: Oh, okay. I thought you were fine showing 2 implementations, so not at risk
17:16:53 <azaroth> ivan: Yes, but here we have to show the extensions are needed, as it's from existing spec
17:16:57 <azaroth> gkellogg: e.g. nested
17:17:08 <bigbluehat> q?
17:17:09 <azaroth> ivan: And it might not be needed, I try to understand how the director might reach
17:17:21 <azaroth> gkellogg: We have multiple implementations of nested properties, but why do we have them at all?
17:17:30 <azaroth> ... it comes from uses in the wild, which would be good to document
17:17:35 <azaroth> scribenick: simonstey
17:17:46 <bigbluehat> Subtopic: Upcoming call with TAG members on March 1st
17:18:10 <simonstey> bigbluehat: next week we'll have 2-3 members joining from TAG
17:18:27 <dlongley> +1 to documenting the purpose for each feature (and put it in the introduction for each feature in the spec)
17:18:49 <simonstey> ... esp. for discussing the relation between json-ld <-> HTML
17:19:00 <simonstey> ... how DOM is affected etc.
17:19:21 <bigbluehat> Topic: Issues
17:19:48 <simonstey> azaroth: we got through the vast majority of the issues
17:20:18 <simonstey> ... we should also go through the @base issue in prep. for next week
17:20:18 <simonstey> https://github.com/w3c/json-ld-framing/issues/37
17:20:32 <ivan> Subtopic: Keywords for options
17:20:47 <simonstey> ... ivan asks why there isn't a keyword for all the different options
17:21:36 <simonstey> ivan: i realized by reading through the document that certain options appeared as keywords
17:21:42 <dlongley> q+
17:21:43 <simonstey> ... others don't
17:21:51 <gkellogg> https://w3c.github.io/json-ld-framing/#framing-keywords
17:22:01 <simonstey> gkellogg: I think there are if you look at the syntax tokens
17:22:37 <simonstey> ivan: not sure I remember reading this
17:22:54 <simonstey> gkellogg: we very well may have examples that don't use all the keywords
17:23:14 <azaroth> > Initialize flags embed, explicit, and requireAll from object embed flag, explicit inclusion flag, and require all flag in state overriding from any property values for @embed, @explicit, and @requireAll in frame.
17:23:21 <dlongley> q-
17:23:27 <simonstey> ivan: yeah the examples in the syntax document were way more extensive
17:23:57 <dlongley> was just going to say our implementation has those flags in there (and there may be tests as well... at least i hope so) :)
17:24:01 <simonstey> gkellogg: my thought initially was that framing would eventually be incorporated in the API document
17:24:24 <simonstey> ... but we decided to leave it in a sep. do
17:24:30 <simonstey> s/do/doc
17:24:50 <simonstey> ... so there's a backlog of things that have to happen to the document
17:25:26 <timCole> Does 4.1 include @omit-graph?
17:25:52 <simonstey> ivan: clearly, if we add more examples to the document then this should fix it
17:26:04 <azaroth> PROPOSAL: Close Framing #37, as already fixed
17:26:11 <simonstey> gkellogg: there is an open issue I'm working against
17:26:11 <azaroth> +1
17:26:16 <azaroth> q?
17:26:43 <pchampin> +1
17:26:47 <simonstey> gkellogg: no it's in 4.4.3.3
17:27:05 <bigbluehat> q+
17:27:07 <bigbluehat> ack bigbluehat
17:27:25 <simonstey> bigbluehat: is it a keyword? or an option for the api?
17:28:07 <simonstey> gkellogg: well we have keywords for all the options
17:28:27 <azaroth> PROPOSAL: Actually keep #37 open for `@omit-graph`
17:28:33 <simonstey> +1
17:28:33 <ivan> +1
17:28:36 <azaroth> +1
17:28:38 <timCole> +1
17:28:45 <bigbluehat> +1
17:28:47 <dlongley> +1 ... naming convention appears to be camelCase so @omitGraph
17:29:02 <gkellogg> +1
17:29:03 <simonstey> gkellogg: values can have multiple elements (array) part of the reason why this complicates native json support
17:29:15 <gkellogg> s/`@omit-graph`/`@omitGraph`/
17:29:28 <gkellogg> s/Graph/Default/
17:29:28 <dlehn> +1
17:29:37 <workergnome> +1
17:29:41 <azaroth> RESOLVED: Actually keep #37 open for `@omit-graph`
17:30:23 <simonstey> https://github.com/w3c/json-ld-syntax/issues/134
17:30:38 <simonstey> topic: [syntax] Does HTML’s `<base>` effect `@context` IRI resolution?
17:30:47 <simonstey> https://github.com/w3c/json-ld-syntax/issues/134
17:31:00 <simonstey> azaroth: which we will talk about with TAG next week
17:31:12 <bigbluehat> q+
17:31:17 <gkellogg> q+
17:31:33 <azaroth> ack bigbluehat
17:31:33 <simonstey> azaroth: [explains example in issue]
17:31:50 <simonstey> bigbluehat: the nuance here is related to the potential dynamic nature
17:32:30 <simonstey> ... the URI spec already outlines that base would also be resolved
17:32:40 <simonstey> ... as it's HTML
17:32:48 <azaroth> q?
17:32:50 <azaroth> ack gkellogg
17:33:18 <simonstey> gkellogg: I think we do need to find someone who's more familiar with HTML
17:33:26 <simonstey> ... esp. wrt. dynamic changes
17:33:43 <ivan> q+
17:33:58 <azaroth> q+ to note security HR
17:34:00 <bigbluehat> q+ to clarify this is about curl (et al) vs. JS-enabled browsers
17:34:42 <azaroth> q?
17:34:43 <azaroth> ack ivan
17:34:48 <simonstey> ... when I was going through this, I seem to recall that in 1.0 we discussed how to deal with a remote context which references another remote context, to what shall this context be relative too?
17:34:57 <simonstey> s/too/to
17:35:22 <simonstey> ivan: the interpretation of the json-ld content must be done onload
17:35:33 <simonstey> ... before anything else is done
17:35:56 <azaroth> q?
17:35:58 <azaroth> ack azaroth
17:35:58 <Zakim> azaroth, you wanted to note security HR
17:36:00 <gkellogg> q+
17:36:07 <pchampin> I'm not sure that we can guarantee that nothing is done before onload
17:36:21 <dlongley> q+ to say that script tags can be added later as well
17:36:39 <simonstey> azaroth: wanted to highlight that this is likely to be a security issue
17:36:45 <simonstey> ... should flag it as such
17:37:21 <simonstey> ... e.g. if you could change a verifiable claim
17:37:55 <simonstey> azaroth: not sure how we could enforce the onload stuff
17:38:00 <azaroth> q?
17:38:03 <azaroth> ack bigbluehat
17:38:03 <Zakim> bigbluehat, you wanted to clarify this is about curl (et al) vs. JS-enabled browsers
17:38:07 <simonstey> ... or test it
17:38:23 <bigbluehat> https://w3c.github.io/json-ld-syntax/#example-120-using-the-document-base-url-to-establish-the-default-base-iri
17:38:29 <simonstey> ivan: I'm suprised that this wasn't an issue anywhere else
17:38:30 <bigbluehat> https://html.spec.whatwg.org/multipage/infrastructure.html#dynamic-changes-to-base-urls
17:38:44 <simonstey> bigbluehat: it actually was, see the links I posted
17:39:26 <simonstey> ... embedding the json-ld might be done with JS
17:39:49 <simonstey> ... search engine bots will wait until the page stops moving
17:40:07 <simonstey> ... but if I curl the page, I'll take whatever is in the document
17:40:10 <ivan> q+
17:40:39 <simonstey> ... if both things are in play, I might not be able to tell what data is actually shared then
17:41:08 <azaroth> ack gkellogg
17:41:13 <simonstey> ... pinning down when JSON-LD processing shall be done is the actual question here
17:41:33 <simonstey> gkellogg: many applications use HTML as a syntax rather than a processing model
17:42:22 <simonstey> ... what if someone does depend on dynamic state changes
17:42:27 <azaroth> q?
17:42:39 <simonstey> ... were different timings make things undecidable
17:43:17 <simonstey> ... if you look at pre-respec times for example
17:43:23 <bigbluehat> https://github.com/w3c/respec/wiki/doJsonLd
17:43:41 <azaroth> ack dlongley
17:43:41 <Zakim> dlongley, you wanted to say that script tags can be added later as well
17:44:01 <azaroth> q?
17:44:11 <simonstey> dlongley: we should probably assume that most pages add json-ld after it has loaded
17:44:32 <simonstey> ... we should provide clear guidance
17:44:57 <simonstey> azaroth: does the signature take also all expanded information into account?
17:45:15 <simonstey> dlongley: yes, the sign. requires expanding and converting to canonicalized RDF
17:45:37 <azaroth> ack ivan
17:45:38 <simonstey> ... if you don't to this you don't pass
17:45:57 <simonstey> ivan: RDFa has a very similar problem
17:46:16 <simonstey> ... it doesn't say a word when processing has to be done
17:46:33 <bigbluehat> q+ to ask if given that <base> can be dynamic, we should ignore it--forcing both `@base` and `@context` URLs to be document URI relative or made absolute
17:46:47 <simonstey> ... although I has the same issues
17:47:00 <azaroth> ack bigbluehat
17:47:00 <Zakim> bigbluehat, you wanted to ask if given that <base> can be dynamic, we should ignore it--forcing both `@base` and `@context` URLs to be document URI relative or made absolute
17:47:02 <simonstey> ... we should provide appropriate warnings
17:47:06 <dlongley> +1 to what ivan said
17:47:14 <simonstey> ... I don't think we can do anything more than that
17:47:19 <timCole> q+
17:47:34 <simonstey> bigbluehat: maybe not relying on the base at all?
17:47:54 <simonstey> gkellogg: no.. that would go against the RFC
17:48:03 <dlongley> -1 to ignoring <base> etc -- i don't think it will fly with anyone (+1 to Gregg)... could be wrong of course.
17:48:17 <ivan> +1 to gregg
17:48:21 <azaroth> q?
17:48:30 <azaroth> ack timCole
17:48:44 <simonstey> timCole: I agree with gkellogg that we have to use base
17:49:30 <gkellogg> +1 to timCole Images don’t reload when base changes.
17:49:46 <azaroth> q?
17:49:49 <bigbluehat> q+
17:49:50 <ivan> +1 ti timCole
17:49:51 <dlongley> i.e. sound like an idea is to "lock in base" on read
17:49:55 <azaroth> ack bigbluehat
17:50:36 <simonstey> bigbluehat: part of the reason they don't change images is because they don't expect things to change
17:50:41 <azaroth> q+ to ask about chromium
17:50:51 <simonstey> timCole: yes maybe we should adapt a similar approach
17:50:53 <azaroth> ack azaroth
17:50:53 <Zakim> azaroth, you wanted to ask about chromium
17:51:04 <dlongley> i suspect we might want to see some use cases to understand expectations with Web Components and things of that nature to make the "right decision" here.
17:51:33 <bigbluehat> q+
17:51:49 <simonstey> azaroth: what would we anticipate the big browsers would do if the json-ld changes
17:51:56 <azaroth> ack bigbluehat
17:52:09 <ivan> +1 to bigbluehat
17:52:18 <simonstey> bigbluehat: we should be careful to be not prescriptive on when and how to run processing
17:52:48 <simonstey> ... but as said, provide guidance/info on what would happen
17:53:25 <dlongley> +1 ... as long as people can understand what will happen when they do processing and can control when to do that processing (there is choice), i think we're ok.
17:53:32 <azaroth> +1
17:53:43 <simonstey> ... you have a lot of options
17:53:56 <azaroth> q?
17:53:58 <simonstey> ... some of it is best practices
17:54:17 <simonstey> ... if you targeting curl then put it directly in the document
17:54:29 <simonstey> ... (for example)
17:54:58 <ivan> q+
17:54:59 <bigbluehat> q+ to ask if we can add a warning or something
17:55:04 <azaroth> ack ivan
17:55:26 <pchampin> +1 to ivan, @base keeps you safe IMO
17:55:42 <dlongley> +1 ... use absolute URIs or @base to get "stable" resolution
17:55:50 <simonstey> azaroth: [providing possible proposals]
17:56:00 <bigbluehat> q-
17:56:26 <simonstey> azaroth: "if you don't do this, this are the possible ramifications"
17:56:54 <simonstey> ... we should explain the different scenarios and what would happen
17:58:21 <azaroth> PROPOSAL: Recommend using absolute URIs or @base within JSON-LD if relative URI resolution is important, and add warnings to the spec for ramifications of using a potentially dynamic DOM for resolution or discovery of JSON-LD blocks
17:58:25 <gkellogg> +1
17:58:31 <ivan> +1
17:58:32 <azaroth> +1
17:58:33 <bigbluehat> +1
17:58:34 <workergnome> +1
17:58:35 <simonstey> +1
17:58:36 <dlongley> +1
17:58:43 <pchampin> +1
17:58:45 <timCole> +1
17:58:51 <dlehn> +1
17:59:17 <simonstey> azaroth: this should be the resolution for issue 134
17:59:19 <azaroth> RESOLVED: Recommend using absolute URIs or @base within JSON-LD if relative URI resolution is important, and add warnings to the spec for ramifications of using a potentially dynamic DOM for resolution or discovery of JSON-LD blocks (staying in #134)
17:59:58 <bigbluehat> q+
18:00:02 <azaroth> ack bigbluehat
18:00:56 <simonstey> zakim, pick a victim
18:00:56 <Zakim> Not knowing who is chairing or who scribed recently, I propose dlehn
18:01:00 <azaroth> TOPIC: Adjourn :)
18:01:10 <ivan> rrsagent, draft minutes
18:01:10 <RRSAgent> I have made the request to generate https://www.w3.org/2019/02/22-json-ld-minutes.html ivan