Re: General proposal for sealec context processing

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