JSON-LD Working Group Telco — Minutes

Date: 2019-03-01

See also the Agenda and the IRC Log

Attendees

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

Regrets:

Guests: Theresa O’Connor, Travis Leithead

Chair: Rob Sanderson, Benjamin Young

Scribe(s): Jeff Mixter

Content:

1. minutes of last week

Proposed resolution: Approve minutes of last call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-02-22-json-ld (Rob Sanderson)

Benjamin Young: +1

Rob Sanderson: +1

Dave Longley: +1

Simon Steyskal: +1

Gregg Kellogg: +1

Jeff Mixter: +0

Resolution #1: Approve minutes of last call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-02-22-json-ld

2. Announcements

Pierre-Antoine Champin: +present

Rob Sanderson: feature freeze is coming up — you should play around with framing if you have not just to test assumptions and use cases

Rob Sanderson: questions about the feature freeze?

Ivan Herman: Web of Things have raised some issues and will be reaching out to us

Benjamin Young: for the best practices document — should we provide a dedicated repo for it so we can add dedicated tasks to it?

Ivan Herman: so I will create a new repo

Benjamin Young: https://json-ld.org/spec/latest/json-ld-api-best-practices/

Action #1: Ivan Herman to set up a new repo for the best practices

Gregg Kellogg: we need to make sure things are hooked together correctly

Benjamin Young: how about? https://json-ld.org/primer/latest/

Ivan Herman: any preference for the name of the repo?

Benjamin Young: what about the primer document — which is more important to work on

Ivan Herman: the best practices is more important right now

3. requireAll does not require @type and should

Rob Sanderson: https://github.com/w3c/json-ld-framing/issues/40

Gregg Kellogg: we added require all flag that does not work the way people expect. People expected it to literally mean ‘require all’ not a combination of if/or

Ivan Herman: can we close the issue?

Gregg Kellogg: not close but we agree to move to approve it

Proposed resolution: IF requireAll is present, then all keys in the frame are used to determine a match, including @type and @id (Rob Sanderson)

Gregg Kellogg: seems logical to be if require all is present then all keys in the frame are used to determine that

Gregg Kellogg: +1

Dave Longley: +1

Rob Sanderson: +1

Benjamin Young: +1

Jeff Mixter: +1

Ivan Herman: +1

Tim Cole: +1

Harold Solbrig: +1

Simon Steyskal: +1

David Newbury: +1

David I. Lehn: +1

Resolution #2: If requireAll is present, then all keys in the frame are used to determine a match, including @type and @id

4. TAG discussion

Theresa O’Connor: https://github.com/w3ctag/design-reviews/issues/312

Theresa O’Connor: the issues are account for in the 2 git issues. We do not want to encourage people to do clever things without using an HTML parser

Benjamin Young: the 2 issues are that the <base> tag being processed by none-html parsers is a pain and problematic

Benjamin Young: https://github.com/w3ctag/design-reviews/issues/312#issuecomment-434689623

Benjamin Young: if you are parsing JSON-ld in the context of HTML you would have to resolve it against the base. What we ran into last week was that this interaction with the DOM is that the state can change. Could break with if you are working with a single page web app
… people parsing JSON-ld out of HTML you need to be thinking about the potential for stuff changing

Theresa O’Connor: the base tag effects a lot of html issues but it is a place where we want consistency
… it is rare for people to rely on this part of the html platform — I have not seen base used in a recent html created — based on not hearing complaints about it.
… most people will be using regular expressions to find stuff in HTML
… just noting the potential pitfalls is really the best you can do

Ivan Herman: do you know spec wise how css deals with his?

Theresa O’Connor: re: how does CSS define its interaction with <base>, see §4.4.1 Relative URLs of CSS Values Level 4: https://drafts.csswg.org/css-values-4/#relative-urls

“For CSS style sheets, the base URL is that of the style sheet itself, not that of the styled source document. Style sheets embedded within a document have the base URL associated with their container.”

Theresa O’Connor: I think it would make sense for CSS to also have a non-normative “there be dragons here” note and will file an issue on CSS Values to reflect that. See also https://github.com/w3c/csswg-drafts/issues/3696

Benjamin Young: do you have an info on the web components stuff — like json modules or html modules?
… there was a idea that json-ld could be more integrated with web components

Theresa O’Connor: the idea of html modules is a definition for how to parse data and how to determine dependencies
… we tried this in the past but it did not go far. But it is a huge problem
… for HTML modules we can rely on the work of JavaScript modules work
… all of the scripts in the module are evaluated as modules. all of these module will be evaluated with relation to the base url

Theresa O’Connor: https://github.com/w3c/webcomponents/blob/gh-pages/proposals/html-modules-explainer.md

Rob Sanderson: last week on a call we discussed this topic and noted that we should be consistent with the current specs and usage. and at this point we would be inconsistent.
… if the base tag changes then processing the json-ld would produce inconsistent URIs. Whenever the json-ld is processed make sure that you are aware of this

Travis Leithead: that seems about right and how other things work
… in cases where a thing is being imported we are leaning toward the master importer’s state taking precedence — this is a security issue
… doc type is an example of there is can happen

Benjamin Young: https://github.com/w3ctag/design-reviews/issues/312#issuecomment-434689623

Benjamin Young: around processsing json-ld — is the json being parsed on import based on the response of the server?

Rob Sanderson: Notably from Hadley: Now that we have JavaScript modules… it would be useful to define the static export of a JSON-LD processor, for use as a module. @travisleithead has been working on an HTML modules proposal.

Travis Leithead: we are still early in the work — but at this point we are parsing and processing the data that is imported and we are scanning for additional modules

Benjamin Young: and: “We should make it possible to identify the module typing of all of our resource types: imaging, types, scripts, CSS, etc. – and it would be ideal to include JSON-LD in that list, and treat it like we treat all of our other resources. We should bring this in from the cold; it’s too important not to use with the rest of the Web.”

Travis Leithead: there is certainly the opportunity to do that for json-ld
… not sure what would be returned when you process a json-ld doc

Theresa O’Connor: there will be a new media type for html modules
… you will need to know the difference and how to process them accordingly

Travis Leithead: the idea for html modules has been kicking around for a few years but it is still very early. We want to get some sort of code out to test this year. Closing issues etc. would then be 6 moths to a year after that
… I would suggest not taking the risk of drawing too heavily from the work right now
… but you could see how it could be used in the future

Gregg Kellogg: the use case for json-ld is that is can be used like json so it seems to make sense to follow/process json-ld the same way
… RDF could be another way to look at it

Gregg Kellogg: what is the interaction between CSS selectors and JSON-ld?

Rob Sanderson: Most recently: https://twitter.com/jdevalk/status/1100783974002147328

Travis Leithead: I do no think that is something we have talk about

Benjamin Young: schema.org has added a cssSelector property

David Newbury: do we assume that if we have an in-memory json-ld doc and we amend the base does the in-memory doc get reprocessed?

Travis Leithead: it would require some special type of hook. In general no it would not get reprocessed

Dave Longley: i’d say no, you’d have to do it explicitly (agree with Travis)

Benjamin Young: you get what you get when you process it and then it become business logic to figure out what to do in the future

David Newbury: is this the same behavior as other objects that are updated with base?

David Newbury: does css get restyled if the base changes?

Rob Sanderson: some things do but some do not — images do not but events bound to the dom do I think

Theresa O’Connor: style recalc happens for a variety of reasons — we do not specify when a recalc should occur — the timing is left to implementations

Ivan Herman: so this means we do have an action to note about the dragons being around

Theresa O’Connor: also need a non-normative note about this being a mess

Theresa O’Connor: I have shared the css note so we are consistent across the board (see above)

5. Resolutions

6. Action Items