This PR is for discussion; not to be pulled in yet. This PR would prevent errors from being thrown when overriding protected terms if the override would result in the same definition as before. The only caveat to this is that if the new definition does not include @protected, this flag is carried forward to maintain the protection status. Otherwise, the definitions must match precisely, including any scoped contexts.
This tweak makes it much easier to reuse existing contexts that do not have any conflicting definitions in them with new contexts that use @protected. Without it, any existing @context that defines common things like aliases for @id or @type would be incompatible with contexts that protect those aliases.
The implementation change involved moving the @protected check to the end of the Create Term Definition algorithm and running a definition comparison check. All tests continue to pass with this change.
This change would still be a potentially valid interpretation of the current JSON-LD 1.1 syntax spec's text on @protected:
A protected term definition is a term definition with a member @protected set to true. It generally prevents further contexts from overriding this term definition, either through a new definition of the same term, or through clearing the context with "@context": null.
As there is no "new definition of the same term", but rather, the same definition of the same term. The "same definition" is determined by comparing those things that a "term definition consists of" per the API spec. Again, the only caveat would be carrying forward @protected mode status even if not specified in the new definition.
So, if we want to do this, we may only need the above changes to the JSON-LD API spec, though we might want to add a clarifying sentence or two to the syntax spec to indicate that redefinitions of the same term with the same definition won't raise an error but that @protected status will remain unless the term is redefined without it when protection is not in effect.
This PR is for discussion; not to be pulled in yet. This PR would prevent errors from being thrown when overriding protected terms if the override would result in the same definition as before. The only caveat to this is that if the new definition does not include
@protected, this flag is carried forward to maintain the protection status. Otherwise, the definitions must match precisely, including any scoped contexts.This tweak makes it much easier to reuse existing contexts that do not have any conflicting definitions in them with new contexts that use
@protected. Without it, any existing@contextthat defines common things like aliases for@idor@typewould be incompatible with contexts that protect those aliases.The implementation change involved moving the
@protectedcheck to the end of the Create Term Definition algorithm and running a definition comparison check. All tests continue to pass with this change.This change would still be a potentially valid interpretation of the current JSON-LD 1.1 syntax spec's text on
@protected:As there is no "new definition of the same term", but rather, the same definition of the same term. The "same definition" is determined by comparing those things that a "term definition consists of" per the API spec. Again, the only caveat would be carrying forward
@protectedmode status even if not specified in the new definition.So, if we want to do this, we may only need the above changes to the JSON-LD API spec, though we might want to add a clarifying sentence or two to the syntax spec to indicate that redefinitions of the same term with the same definition won't raise an error but that
@protectedstatus will remain unless the term is redefined without it when protection is not in effect.