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
- Resolution #1: minutes of last week accepted
- Resolution #2: Keep #37 open for
@omit-graph
- 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)