Tweak @protected algorithm to allow reuse of existing contexts w/o conflicts

[dlongley]

A PR (digitalbazaar/jsonld.js#316) in jsonld.js 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.

[iherman]

This issue was discussed in a meeting.

• RESOLVED: Assuming the update to the algorithm is not controversial, protected definitions of terms do not raise an error when the term is redefined in exactly the same way, with the potential exception of not being protected

View the transcript

3.2. Tweak @Protected algorithm to allow reuse of existing contexts w/o conflicts
Dave Longley: #90
Dave Longley: so this one is about reusing existing contexts
… the syntax spec says that a protected term definition with @Protected: true
… it prevents it being overridden
… possibly by setting context to null
… what is prohibited is introducing other definitions
… but what happens when new terms come in
… what this change could provide is allowing using 1.0 contexts alongside protected
… so, things that define aliases for id/type
Rob Sanderson: +1 to this issue
Dave Longley: you can’t currently bring those in with protected, because that throws an error
… because you’re trying to redefine terms–even though the result would be the same
… so the only caveat is reusing old contexts won’t come with @Protected set
… so in that case, you just keep @Protected flag to on
… so update the API to switch where we check that protected is set, not update existing terms that are identical–modulo the protected flag
David Newbury: it does seem to make complete sense
… I’d want gkellogg to weigh in
… to get another implementer’s input on this
Dave Longley: so, the only sticky issue is two scoped contexts, then you have to do a full comparison
Rob Sanderson: if they’re by value rather than by reference…yeah…that would be rough
… so with the caveat that the editors are OK
… here’s a proposal
Proposed resolution: Assuming the update to the algorithm is not controversial, protected definitions of terms do not raise an error when the term is redefined in exactly the same way, with the potential exception of not being protected (Rob Sanderson)
David Newbury: +1
Jeff Mixter: +1
Dave Longley: +1
Rob Sanderson: +1
Simon Steyskal: +1
David I. Lehn: +1
Benjamin Young: +1
Resolution #3: Assuming the update to the algorithm is not controversial, protected definitions of terms do not raise an error when the term is redefined in exactly the same way, with the potential exception of not being protected

[gkellogg]

Closed via #92 and w3c/json-ld-syntax#190.