Re: General proposal for sealec context processing

> On Feb 6, 2019, at 12:35 PM, Pierre-Antoine Champin <pierre-antoine.champin@univ-lyon1.fr> wrote:
> 
> 
> 
> On Tue, 5 Feb 2019 at 22:32, Gregg Kellogg <gregg@greggkellogg.net <mailto: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*.

Definitely, the syntax document needs to be geared towards people using it.

> 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 <http://example.org/contaxt_a.jsonl>” .

In my view, directly under a property based on a sealed term, the associated context remains sealed, meaning that you cannot redefine terms associated with that context. Once you enter a non-sealed term, or a sealed term with a scoped context that either clears such terms, you can introduce a new context and redefine any terms. When you again descend into a sealed term, the associated context is sealed again.

If this were not the case, then, other than at the top level, there would be no point in having more than one sealed context, as it would be unsealed as soon as you used a sealed term from another context. (Unless I’m missing something).

Basically, as long as you use sealed terms, the associated context remains sealed. As soon as you use an unsealed term, or a sealed term from another context, the previous context becomes effectively unsealed, until you use such a sealed term again.

Gregg

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