Allow override of a protected term that uses the same definition. #316
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
: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.