Re: General proposal for sealec context processing

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" .

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