JSON-LD Working Group Telco — Minutes

Date: 2019-08-23

See also the Agenda and the IRC Log

Attendees

Present: Rob Sanderson, Adam Soroka, Dave Longley, Ruben Taelman, Ivan Herman, Pierre-Antoine Champin, David I. Lehn, Benjamin Young

Regrets: Gregg Kellogg, Tim Cole

Guests:

Chair: Rob Sanderson, Benjamin Young

Scribe(s): Dave Longley

Content:

1. Approve previous minutes

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

Rob Sanderson: +1

Dave Longley: +1

Ruben Taelman: +1

Pierre-Antoine Champin: +0

Ivan Herman: +1

Resolution #1: Approve minutes of previous call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-08-16-json-ld

2. Announcements / Reminders

Rob Sanderson: If you have not registered for TPAC and intend to come please do so sooner rather than later.
… The block w3c has reserved at the hotel has run out but rooms available at the regular rate as of last week.

3. Horizontal Review Updates

Rob Sanderson: My updates … I put the information in for the security review.

Rob Sanderson: security review: https://github.com/w3c/json-ld-wg/issues/89

Rob Sanderson: This is from the questionnaire that Ivan circulated last week on the call which has been linked in the issue. I don’t think there’s anything. The only thing that has come up for us is 2.6 which is the privacy/security question which is about the request for contexts for tracking who is doing what.
… That is more privacy than security.
… Seems 2.14 talks about incognito/private web browsing as well.
… Do we now re-request review from the security group or just get them to say “if you disagree with our responses otherwise we’ll keep going”…

Ivan Herman: The latter is probably better.

Rob Sanderson: I will then alert Security as to the issue.

Action #1: alert security as to the questionnaire responses (#89) and intend to keep going (Rob Sanderson)

Rob Sanderson: The only other one from me was privacy. Which I have emailed the PING folks to say here’s the answers we’ve come up to about your question about state. We’re not introducing a new thing so no new privacy concerns.
… I think we should do the same for security. I’ll take another action.

Action #2: alert privacy as to response and intend to keep going (Rob Sanderson)

Rob Sanderson: The other two – i18n, a11y – are there any updates on either of those?

Ivan Herman: Nothing happened on i18n. I pinged them … back in August, no reply. We should leave it as is and then when we get to CR we can show we did what we did and that’s all we can do.
… I haven’t looked at a11y.

Rob Sanderson: Should we assign Benjamin for that in his absence?

Ivan Herman: Always a good tactic.

Action #3: chase a11y HR (Benjamin Young)

Rob Sanderson: Those are the horizontal reviews – mostly in a holding pattern. Any questions about HR or anything else I’ve forgotten?
… Moving on.

4. Issues

4.1. Encapsulate HTML processing

Rob Sanderson: See Syntax #214

Rob Sanderson: See API #135

Rob Sanderson: Discussion from last week has resulted in some PRs.

Ivan Herman: Gregg not here this week.

Pierre-Antoine Champin: dlongley: PRs are moving in a direction I would agree with

Rob Sanderson: I would agree as well, pushing things into the document loader as discussed last week.
… I guess the issue to discuss is – is there anyone who is not comfortable yet otherwise we should accept those PRs.

Pierre-Antoine Champin: scribeassist: pchampin

Rob Sanderson: Any objections to the approach?

Ivan Herman: I read through the documents and we have done the work.

Pierre-Antoine Champin: dlongley: I would like to wait for other reviews before minerging (including mine)

Proposed resolution: gkellogg to merge #135 and #214 after reviewers have approved (Rob Sanderson)

Proposed resolution: gkellogg to merge #135 and #214 after reviewers have approved and close the relevant issues (Rob Sanderson)

Dave Longley: +1

Ruben Taelman: +1

Rob Sanderson: +1

Benjamin Young: +1

Pierre-Antoine Champin: +1

Ivan Herman: +1

David I. Lehn: +1

Resolution #2: gkellogg to merge #135 and #214 after reviewers have approved and close the relevant issues

Rob Sanderson: Benjamin anything to discuss on the processing levels issue?

Benjamin Young: Nope, I think the last one entails this one.

4.2. Should rel=”alternate” keep the base IRI of the original document?

Rob Sanderson: API issue #139

Pierre-Antoine Champin: In the current API spec, it says whenever a rel="alternate" link is followed the base URL is set to the original URL. Meaning that relative URLs in a context document should be resolved as if found in the HTML document that is the source of the link.
… I see this partly as content negotiation which would advocate for this but also as a redirection because the client has to explicitly follow a link. I don’t know of such a situation that causes this to happen. I understand the rationale but it has no precedent.
… And it creates a strange exception and that’s my concern.

Pierre-Antoine Champin: dlongley: as I understand, Gregg thought that was consistent with how things work elsewhere.

Pierre-Antoine Champin: … And what we are already doing.

Pierre-Antoine Champin: … My position would be: let’s not do something that is exceptional.

Pierre-Antoine Champin: … But let’s not break what we are doing now either.

Rob Sanderson: also +1 to dlongley

Rob Sanderson: and to pchampin / bigbluehat about setting default @base

Benjamin Young: +1 to what Dave just said but it’s also about setting the default base. Maybe we can follow this up with a note around it. Context authors should be explicit about setting their own base or using URLs for their contexts because there are a host of situations where base is flaky.
… Publishing a context where you’re not being explicit is dangerous anyway already – and these things, certainly both of them combined, make it much less dependable. It could come with a declaration that context authors need to be explicit about their base or use full URLs.

Adam Soroka: +1 to what Dave and Ben said. If I understand correctly we’re talking about a link between two resources, such that you traverse that link you’re going to interpret base with the original document. You could in theory interpret with a different base – that’s not some kind of world is going to fall, but it opens the door to a lot of potential confusion. Especially in complex systems where you get a lot of reuse.

Ivan Herman: I come back to what Benjamin said – if there is an @base in the @context document doesn’t that set the base that refers to the document.
… If it does, then we shouldn’t do that.

Benjamin Young: The @base only works for the document it’s in, not in the @context, only works in an inline context, not for a remote context.

Ivan Herman: Ok.

Benjamin Young: It’s not about removing rel="alternate" it’s about not setting base to the original request URI but setting it to the redirect meaning rather than the original one.

Pierre-Antoine Champin: dlongley: in schema.org, I think that all the URLs are explicit. I’m pretty sure they would want their base URL be http://schema.org, not any URL they redirect to.

Pierre-Antoine Champin: … Let’s make sure we are not shooting ourselves in the foot.

Ivan Herman: schema.org uses only absolute URLs.

Benjamin Young: Part of this closing proposal – should we add something in the NOTE or something … that context authors should always be explicit with their URLs because it’s risky at best.

Ivan Herman: Whomever is the editor of the best practices document should make a note.

Action #4: add use absolute URIs to BPs (Benjamin Young)

Action #5: add use absolute URIs to BPs (Adam Soroka)

Proposed resolution: Agree with the issue and by default associate base with the redirected URL not the original (Rob Sanderson)

Rob Sanderson: +1

Ivan Herman: +1

Ruben Taelman: +1

Dave Longley: +1 (hopes this is the right decision)

Pierre-Antoine Champin: +1

Benjamin Young: +1

Resolution #3: Agree with the issue and by default associate base with the redirected URL not the original

Adam Soroka: +1

4.3. Removing “at risk” declarations on inline issues and <base> handling

Benjamin Young: See API #137

Benjamin Young: The at-riskness has been removed where it didn’t match the w3c semantics of “at risk” … and saying these are open issues instead.
… By removing at-risk for these other features, these will be in CR without question.
… My only hesitation is around the base tag one – all the vagueness around base calculation is a little dodgy and it’s a new feature. We don’t yet have multiple implementers of this.
… The use of base as we have it now does map to RFC3986. That it goes through the mechanics of any wrapping documents which is the HTML base tag at this point, but it does presume that you are operating within HTML and not pulling things out and passing it off to another processor.
… So I think this is a fairly significant shift but it is only setting the base default.

Adam Soroka: I’m comfortable with this change. To follow on – it’s oddly similar to what we just discussed, how much context does a processor have to consider about where the content came from.
… I don’t think we can say that no processor is in a vacuum but at the same time we don’t want people to have to drag the whole Web after them.
… And we want to do something reasonable to meet the use cases, etc. I think you’re talking about a piece of data to resolve URIs and we’re hedging/moving in that direction and you have to know a little more than what’s directly being processed in that moment.

Ivan Herman: The usage of the base, and how to use it is an issue we’ve discussed and we’ve closed it.
… The only question is whether it creates implementation issues – I don’t think it does because in practice, if you use the HTML parser, getting base is a piece of cake. Now we have a separation with document loader doing HTML or not, and that’s all clear.

Pierre-Antoine Champin: dlongley: Ivan covered most of what I was about to say.

Pierre-Antoine Champin: … If you have an HTML parser, it is easy to get the base at the time you are doing the processing.

Benjamin Young: The main reason I wanted to leave this open was to get feedback from Dave – and that works for me.

Adam Soroka: I said a real question about conformance – in a situation where we’re headed, with at least two flavors of document loaders. Do we need to see two different implementations of that more powerful document loader?

Ivan Herman: Yes.

Benjamin Young: A quick note to highlight about “when the processing happens” that becomes a really important aspect for authors. Base can change, JSON-LD can be injected, so on – it’s a timing question. All bets are off on a lot of Web apps on what you’re actually encoding based on timing.

Proposed resolution: approve PR #137 (Benjamin Young)

Benjamin Young: +1

Dave Longley: +1

Ivan Herman: +1

Adam Soroka: +1

David I. Lehn: +1

Ruben Taelman: +1

Pierre-Antoine Champin: +1

Benjamin Young: +1

Resolution #4: approve PR #137

5. Resolutions

6. Action Items