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
- 2. Announcements
- 3.
requireAll
does not require@type
and should - 4. TAG discussion
- 5. Resolutions
- 6. Action Items
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
- Resolution #1: Approve minutes of last call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-02-22-json-ld
- Resolution #2: If
requireAll
is present, then all keys in the frame are used to determine a match, including@type
and@id
6. Action Items
- Action #1: Ivan Herman to set up a new repo for the best practices