atrisk

[gkellogg]

• Remove atrisk on JSON Canonicallization.
• Remove atrisk div on the use of HTML base. This was resolved in Does HTML's <base> effect @context IRI resolution? json-ld-syntax#134 (comment) which is reflected in the syntax document.

---

Preview | Diff

[iherman]

This issue was discussed in a meeting.

• RESOLVED: approve PR #137

View the transcript

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