Re: General proposal for sealec context processing

> On Feb 5, 2019, at 9:53 AM, Pierre-Antoine Champin <pierre-antoine.champin@univ-lyon1.fr> wrote:
> 
> Thanks a lot Gregg, this is looking good.
> 
> You didn't keep the notion of "effective seals", from my original proposal. I'll try to better explain what its role was. This is also an attemt to address Ivan's concern that the proposal was too implementation-oridented.

The “effective seals” would be necessary for doing what you describe below, where a_p2 would no longer be sealed, because the seal ID would be associated with context_b. I didn’t consider this as important desired behavior, but maintaining that would be straightforward. In my version, the “context ID” created and used for any sealed terms would remain active in the active context in “ effective seals” until a new sealed term is introduced.

In terms of how implementation-oriented either approach might be, I think the context processing algorithm would still need to know the term which is used for parsing a new context (“from term”) to know if “effective seals” would need to change, instead of looking at the “context ID” for the term to know what the “context ID” is. You’d still need to keep track of what terms are associated with which contexts, so storing the “context ID/seal ID” with each term would still be necessary.

There is some other logic for if terms can be individually sealed or not, which I retained. If we choose to dump this feature, some minor simplifications can be made. 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.

> Attached is a PDF describing 2 hypothetical sealed context (context_a.jsonld and context_b.jsonld), and a document using both of them (data.jsonld). The areas in color in data.jsonld represent the parts of the document where each seal is effective. Theoretically, this "area of effectiveness" can be defined as a subtree of the JSON tree, rooted in the node where the sealed context is activated (here, the top-level node), and deprived of the subtrees reachable through "foreign" terms.
> 
> The rationale is that "plain JSON" implementations will only traverse terms they know, so they will ignore foreign terms and everything below them. So "plain JSON" implementations expecting context_a (resp. context_b) will only explore the light-green (resp. light-red) part of the document.
> 
> As a consequence (and this is where Gregg's implementation diverges, IIC, from my mental model), the subtree 37 to 39, is *not* prorected by the seal of context_a. It would be possible for an embeded context to override a_p1, for example…

Yes, we do diverge, but IMHO, because a_p2 was defined in a sealed context, and nothing was done to change its definition, it would retain its sealed nature,and 37-39 would be colored in green. It is the same term, and was defined as sealed, so I don’t see why it wouldn’t keep that nature. We can certainly discuss this.

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.

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

It is certainly possible to redefine things under b_q3 that are not sealed in context_b; and, we could re-define, or re-import context_a.

Gregg

>  best
> 
> On Sat, 2 Feb 2019 at 22:13, Gregg Kellogg <gregg@greggkellogg.net <mailto:gregg@greggkellogg.net>> wrote:
> So, I haven’t completed all tests, but I have an implementation which is close to my original that I think handles the use cases. Note that it still supports `@sealed` on individual terms, but that could be eliminated if we so desire.
> 
> In the Context Processing Algorithm:
> 
> The algorithm now has a `from term` optional parameter, which is either set from the `active property` in the Expansion algorithm, or `null`, depending (as described below).
> 
> When parsing a context from an IRI, the IRI is used as the `context id`, otherwise some new unique value. (Note, we don’t actually use `context id`, so it could be anything, but it might be useful for warning reporting.
> 
> Let `current seal` be the `context id` associated with `from term` in the active context, if any. An attempt to clear the active context by setting to null is ignored and a warning is issued if `current seal` is set.
> 
> Pass `sealed` from the value the `@sealed` member in the local context, if any, `current seal`, and `context id` to the Create Term Definition algorithm.
> 
> In the Create Term Definition algorithm:
> 
> 6) If `current seal` is set, and the active context has an existing term for `term`, and that term is sealed, issue a warning and skip the term definition.
> 
> 12) Set `sealed` in _definition_ to `context id` if the value of the `@sealed` member in _value_ is true, or the value of _sealed_ if there is no such member.
> 
> In the Expansion algorithm:
> 
> 6) pass `active property` as `from term` when calling the Context Processing Algorithm. — prevents overriding sealed terms from the same context
> 
> 7.1)  pass `active property` as `from term` when calling the Context Processing Algorithm. — prevents overriding sealed terms from the same context (for @type scoped contexts)
> 
> 9.5) do not pass `from term` when calling the Context Processing Algorithm. — allows a scoped context for a property to redefine terms
> 
> 9.8.2.1) pass `active property` as `from term` when calling the Context Processing Algorithm. — prevents overriding sealed terms from the same context (for type maps)
> 
> I think this achieves what we want. Expansion is called with the active property, which may be associated with a sealed context, except when processing scoped contexts on property (allows a sealed term to make changes). If the active property is not sealed, the context processing algorithm will allow changes to sealed terms.
> 
> Gregg Kellogg
> gregg@greggkellogg.net <mailto:gregg@greggkellogg.net>
> 
> > On Jan 30, 2019, at 11:54 PM, Pierre-Antoine Champin <pierre-antoine.champin@univ-lyon1.fr <mailto:pierre-antoine.champin@univ-lyon1.fr>> wrote:
> > 
> > Hi all,
> > 
> > before I try myself on the API document, I would rather submit to you the general ideas I have about how we can achieve what I described in the Syntax document. Let me know if that makes sense.
> > 
> > The general idea is to assign a unique *seal ID* to each sealed context. This seal ID will be included, in the active context, on every term definition created by the sealed context. Also, the active context will have an additional attribute, 'effective seals', which is a list of seal IDs.
> > 
> > The context processing algorithms will have an optional 'current seal' input parameter. The rationale of this parameter is to remember that we are "inside" a given sealed context, and as such should be able to override its own term definitions.
> > 
> > More precisely, when we are about to override a term definition, we will fail if :
> > * the previous term definition has a seal ID AND
> > * that seal ID is in the `effective seals` list AND
> > * that seal ID is different from the `current seal`
> > 
> > In other words, a term definition can be overriden if
> > * it is not sealed (it has no seal ID) OR
> > * its seal is not active OR
> > * the overriding originates in the same sealed context
> > 
> > The `effective seals` list is managed that way;
> > - when building the active context, we add to the list the seal ID of every sealed context we encountered.
> > - During expansion, when we traverse a property, we check its term definition and only keep in the list of `effective seals` the seal ID of this property, if any. Otherwise, the list is emptied.
> > 
> > What do you think?
> 
> <2019-02-05-effective-seals.pdf>