- From: Pierre-Antoine Champin <pierre-antoine.champin@univ-lyon1.fr>
- Date: Thu, 31 Jan 2019 08:54:02 +0100
- To: public-json-ld-wg@w3.org
- Message-ID: <CA+OuRR9a=7_sKSRkKrp-u_RcGNTTwJHUrm08YMken9PzMy4WmQ@mail.gmail.com>
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 Thursday, 31 January 2019 07:54:38 UTC