W3C home > Mailing lists > Public > public-json-ld-wg@w3.org > February 2019

Re: General proposal for sealec context processing

From: Pierre-Antoine Champin <pierre-antoine.champin@univ-lyon1.fr>
Date: Wed, 6 Feb 2019 18:35:14 +0100
Message-ID: <CA+OuRR_OWO2WGCST=eMR_iWbpJO_wy7Gyig8OjNOrHpGhhW6hw@mail.gmail.com>
To: Gregg Kellogg <gregg@greggkellogg.net>
Cc: "public-json-ld-wg@w3.org" <public-json-ld-wg@w3.org>
On Tue, 5 Feb 2019 at 22:32, Gregg Kellogg <gregg@greggkellogg.net> wrote:

> (...)
Otherwise, I don’t really see how to make the algorithm descriptions less
> implementation-specific, but please take a go at it, if you like.

Sorry, I was not trying to say that the *algorithm description* was too
implementation-specific. Ivan's concern, as I understood it, was that the
only way we could find to describe where and when sealing was effective,
were algorithmic; i.e. *how* it works. He thought, and I tend to agree,
that JSON-LD users would not use the feature if tere was no simple way to
explain it, i.e. *what* it does, and *why*.

That's why I tried to describe the "area of effectiveness" in a more
concise way. But your description of the algorithm itself is absolutely
fine by me.

> If you were to imaging that context_a was defined for signing, and
> context_b for credentials, then if you were to enter a property associated
> for signing, I don’t see why that shouldn’t continue to be sealed, unless
> it really is a different term. I think plain JSON developers would have the
> same expectation.

If they do, then we must keep all seals effective in the *whole* document;
that's the only way to guarantee that terms from context_a have their
original meaning in lines 37-39 (as I already pointed out, see below).
I am fine with that, but as I remembered, Dave Longley was the one
suggesting that sealing would become ineffective after traversing "foreign"
terms. If it does, then the only way to make it effective again in a deeper
subtree would be to reactivate it with "@context": "
http://example.org/contaxt_a.jsonl" .


And by the way, it would still be possible to override a_p1 in the
> light-red area (e.g. by inserting an embeded context between lines 35 and
> 36. Unless I'm missing something, Gregg, your implementation currently
> allows that. So "re-sealing" the term line 37 seems rather vain…
Received on Wednesday, 6 February 2019 17:35:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:15:24 UTC