Skip to content

Allow override of a protected term that uses the same definition. #316

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 11 commits into from
May 21, 2019

Conversation

dlongley
Copy link
Member

@dlongley dlongley commented May 13, 2019

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.

- The only caveat to the "same definition" is that if the new
  definition does not include `@protected`, this flag is carried
  forward to maintain the protection status.
@dlongley dlongley force-pushed the improve-protected-ergonomics branch 2 times, most recently from afd8547 to ad9c3e4 Compare May 20, 2019 15:58
@dlongley dlongley force-pushed the improve-protected-ergonomics branch from ad9c3e4 to 1c00ec3 Compare May 20, 2019 16:16
@dlongley dlongley marked this pull request as ready for review May 20, 2019 19:22
@dlongley dlongley force-pushed the improve-protected-ergonomics branch from e04987e to 2636300 Compare May 21, 2019 17:10
@dlongley dlongley force-pushed the improve-protected-ergonomics branch from 2636300 to 55d013d Compare May 21, 2019 17:23
@dlongley dlongley force-pushed the improve-protected-ergonomics branch from 8589701 to e445d1d Compare May 21, 2019 18:29
@dlongley dlongley merged commit fdb27a0 into master May 21, 2019
@dlongley dlongley deleted the improve-protected-ergonomics branch May 21, 2019 18:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants