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 22:10:47 +0100
Message-ID: <CA+OuRR_egvq42nKkRfXmikhfbf8FLWH5u_NB=o5C35i-oAyXyg@mail.gmail.com>
To: Gregg Kellogg <gregg@greggkellogg.net>
Cc: "public-json-ld-wg@w3.org" <public-json-ld-wg@w3.org>
Sorry, small rectification:

On Wed, 6 Feb 2019 at 18:35, Pierre-Antoine Champin <
pierre-antoine.champin@univ-lyon1.fr> wrote:

> 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;

what I meant here was actually "in the whole subtree starting where the
sealed context was activated"

> 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" .
>   pa
> 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 21:11:23 UTC

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