Re: General proposal for sealec context processing

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

> On Jan 30, 2019, at 11:54 PM, Pierre-Antoine Champin <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?

Received on Saturday, 2 February 2019 21:13:50 UTC