JSON-LD Working Group Telco — Minutes

Date: 2019-02-22

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Simon Steyskal, Rob Sanderson, Gregg Kellogg, Benjamin Young, Dave Longley, Pierre-Antoine Champin, Tim Cole, David I. Lehn

Regrets: Jeff Mixter

Guests:

Chair: Rob Sanderson, Benjamin Young

Scribe(s): Simon Steyskal, Rob Sanderson

Content:

1. Approve minutes of previous call

Simon Steyskal: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-02-15-json-ld

Benjamin Young: +1

Gregg Kellogg: +1

Dave Longley: +1

Pierre-Antoine Champin: +1

Ivan Herman: +1

Rob Sanderson: +1

Benjamin Young: any objections? if not +1

Simon Steyskal: +1

Benjamin Young: approved!

Resolution #1: minutes of last week accepted

2. Announcements / Reminders

2.1. Heading to Candidate Recommendation (CR) - Calling all Implementers

Benjamin Young: we are heading towards CR
… consequently we are looking for as many implementers as we can
… end of march?

Ivan Herman: I think we started with the start of march but pushed it back to the end

Gregg Kellogg: I think we wanted to wait for the next draft to come out before moving to CR

Benjamin Young: azaroth and I wanted to do a blog post on that too

Gregg Kellogg: Test suite for the API -> https://w3c.github.io/json-ld-api/tests/

Gregg Kellogg: Test suite for the Framing -> https://w3c.github.io/json-ld-framing/tests/

Gregg Kellogg: link to test description

Benjamin Young: I guess the API is the one to implement right?

Gregg Kellogg: there’s also one for framing

Benjamin Young: we need 2+ implementations for each feature

Rob Sanderson: quick question -> for the distinction between api and syntax
… what if you would implement a total diff. api but still use the correct syntax
… do we allow for that? or do we only accept if you implement the syntax complying to our api spec?

Ivan Herman: the way I would present it -> the test suite we have is to some extent a test suite for the syntax, too
… so I wouldn’t necessarily tie it to the api only
… I would expect that the test suite has examples for each feature of the syntax

Gregg Kellogg: we certainly have to check our test suites
… other RDF serialization tests usually don’t distinguish between processing and syntax tests
… exception might be NTriples
… we also have some negative syntax tests if I recall correctly

Ivan Herman: just saying that we have to be careful on how to present this
… also, we do have to know whether we have deployment plans for the new features
… we have introduced quite a few features, have to provide proof to some extent that those are really needed and planned to be implemented

Rob Sanderson: +1 to Ivan and Gregg

Gregg Kellogg: maybe we should go through the issue tracker and document planned implementations of the various features

Benjamin Young: if you round-trip through compacting, you might be able to proof compliance with respective algorithm

Simon Steyskal: 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.
… 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?

Ivan Herman: An implementation looks at the JSON-LD in general and implements those things, is disjoint from whether it will be used

Simon Steyskal: Oh, okay. I thought you were fine showing 2 implementations, so not at risk

Ivan Herman: Yes, but here we have to show the extensions are needed, as it’s from existing spec

Gregg Kellogg: e.g. nested

Ivan Herman: And it might not be needed, I try to understand how the director might react

Gregg Kellogg: We have multiple implementations of nested properties, but why do we have them at all?
… it comes from uses in the wild, which would be good to document

2.2. Upcoming call with TAG members on March 1st

Benjamin Young: next week we’ll have 2-3 members joining from TAG

Dave Longley: +1 to documenting the purpose for each feature (and put it in the introduction for each feature in the spec)

Benjamin Young: esp. for discussing the relation between json-ld <-> HTML
… how DOM is affected etc.

3. Issues

Rob Sanderson: we got through the vast majority of the issues
… we should also go through the @base issue in prep. for next week

3.1. Keywords for options

Simon Steyskal: https://github.com/w3c/json-ld-framing/issues/37

Rob Sanderson: ivan asks why there isn’t a keyword for all the different options

Ivan Herman: I realized by reading through the document that certain options appeared as keywords
… others don’t

Gregg Kellogg: I think there are if you look at the syntax tokens

Gregg Kellogg: https://w3c.github.io/json-ld-framing/#framing-keywords

Ivan Herman: not sure I remember reading this

Gregg Kellogg: we very well may have examples that don’t use all the keywords

Rob Sanderson: > 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.

Ivan Herman: yeah the examples in the syntax document were way more extensive

Dave Longley: was just going to say our implementation has those flags in there (and there may be tests as well… at least i hope so) :)

Gregg Kellogg: my thought initially was that framing would eventually be incorporated in the API document
… but we decided to leave it in a sep. doc
… so there’s a backlog of things that have to happen to the document

Tim Cole: Does 4.1 include @omit-graph?

Ivan Herman: clearly, if we add more examples to the document then this should fix it

Proposed resolution: Close Framing #37, as already fixed (Rob Sanderson)

Gregg Kellogg: there is an open issue I’m working against

Rob Sanderson: +1

Pierre-Antoine Champin: +1

Gregg Kellogg: no it’s in 4.4.3.3

Benjamin Young: is it a keyword? or an option for the api?

Gregg Kellogg: well we have keywords for all the options

Proposed resolution: Keep #37 open for @omit-graph (Rob Sanderson)

Simon Steyskal: +1

Ivan Herman: +1

Rob Sanderson: +1

Tim Cole: +1

Benjamin Young: +1

Dave Longley: +1 … naming convention appears to be camelCase so @omitDefault

Gregg Kellogg: +1

Gregg Kellogg: values can have multiple elements (array) part of the reason why this complicates native json support

David I. Lehn: +1

David Newbury: +1

Resolution #2: Keep #37 open for @omit-graph

3.2. [syntax] Does HTML’s <base> effect @context IRI resolution?

Simon Steyskal: https://github.com/w3c/json-ld-syntax/issues/134

Rob Sanderson: which we will talk about with TAG next week

Rob Sanderson: [explains example in issue]

Benjamin Young: the nuance here is related to the potential dynamic nature
… the URI spec already outlines that base would also be resolved
… as it’s HTML

Gregg Kellogg: I think we do need to find someone who’s more familiar with HTML
… esp. wrt. dynamic changes
… 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 to?

Ivan Herman: the interpretation of the json-ld content must be done on load
… before anything else is done

Pierre-Antoine Champin: I’m not sure that we can guarantee that nothing is done before on load

Rob Sanderson: wanted to highlight that this is likely to be a security issue
… should flag it as such
… e.g. if you could change a verifiable claim

Rob Sanderson: not sure how we could enforce the on load stuff
… or test it

Ivan Herman: I’m surprised that this wasn’t an issue anywhere else

Benjamin Young: https://w3c.github.io/json-ld-syntax/#example-120-using-the-document-base-url-to-establish-the-default-base-iri

Benjamin Young: https://html.spec.whatwg.org/multipage/infrastructure.html#dynamic-changes-to-base-urls

Benjamin Young: it actually was, see the links I posted
… embedding the json-ld might be done with JS
… search engine bots will wait until the page stops moving
… but if I curl the page, I’ll take whatever is in the document
… if both things are in play, I might not be able to tell what data is actually shared then
… pinning down when JSON-LD processing shall be done is the actual question here

Gregg Kellogg: many applications use HTML as a syntax rather than a processing model
… what if someone does depend on dynamic state changes
… were different timings make things undecidable
… if you look at pre-respec times for example

Benjamin Young: https://github.com/w3c/respec/wiki/doJsonLd

Dave Longley: we should probably assume that most pages add json-ld after it has loaded
… we should provide clear guidance

Rob Sanderson: does the signature take also all expanded information into account?

Dave Longley: yes, the sign. requires expanding and converting to canonicalized RDF
… if you don’t to this you don’t pass

Ivan Herman: RDFa has a very similar problem, potentially
… it doesn’t say a word when processing has to be done
… although I has the same issues
… we should provide appropriate warnings

Dave Longley: +1 to what ivan said

Ivan Herman: I don’t think we can do anything more than that

Benjamin Young: maybe not relying on the base at all?

Gregg Kellogg: no.. that would go against the RFC

Dave Longley: -1 to ignoring <base> etc — i don’t think it will fly with anyone (+1 to Gregg)… could be wrong of course.

Ivan Herman: +1 to gregg

Tim Cole: I agree with gkellogg that we have to use base

Gregg Kellogg: +1 to timCole Images don’t reload when base changes.

Ivan Herman: +1 ti timCole

Dave Longley: i.e. sound like an idea is to “lock in base” on read

Benjamin Young: part of the reason they don’t change images is because they don’t expect things to change

Tim Cole: yes maybe we should adapt a similar approach

Dave Longley: 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.

Rob Sanderson: what would we anticipate the big browsers would do if the json-ld changes

Ivan Herman: +1 to bigbluehat

Benjamin Young: we should be careful to be not prescriptive on when and how to run processing
… but as said, provide guidance/info on what would happen

Dave Longley: +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.

Rob Sanderson: +1

Benjamin Young: you have a lot of options
… some of it is best practices
… if you targeting curl then put it directly in the document
… (for example)

Pierre-Antoine Champin: +1 to ivan, @base keeps you safe IMO

Dave Longley: +1 … use absolute URIs or @base to get “stable” resolution

Rob Sanderson: [providing possible proposals]

Rob Sanderson: “if you don’t do this, this are the possible ramifications”
… we should explain the different scenarios and what would happen

Proposed resolution: 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 (Rob Sanderson)

Gregg Kellogg: +1

Ivan Herman: +1

Rob Sanderson: +1

Benjamin Young: +1

David Newbury: +1

Simon Steyskal: +1

Dave Longley: +1

Pierre-Antoine Champin: +1

Tim Cole: +1

David I. Lehn: +1

Rob Sanderson: this should be the resolution for issue 134

Resolution #3: 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)

5. Resolutions