Add @protected tests and a protectedMode flag.

[davidlehn]

If it's decided to change the naming from @sealed to @protected, here's a patch.
(replaces #68)
(builds upon #70)

• Changes simple naming text as needed.
• Adds a number of tests.
• Adds a protectedMode option that can be error or warn.
  • The default error mode will fail on protection violations.
  • There are two new error strings.
  • The warn mode will not fail but will enforce the protected terms.
• Test both error and warn mode as needed.

A prototype jsonld.js implementation is available.

jsonld.js initially just handled the easier error mode with exceptions. But that was the opposite of what the tests did. The warn mode required some invasive internal passing around of options. But otherwise the @protected changes were not too difficult. (At least once you wrap your head around how the warning mode should work!)

Items todo for this patch:

• Get feedback on this direction, error names, and test coverage.
• Update spec text for how to handle protectedMode.
• Ensure spec text matches what tests are doing.
• Add error strings to spec.
• Ensure there is a test showing behavior of Does @sealed consider order? json-ld-syntax#153

---

Preview | Diff

[gkellogg]

I'm fine with changing @sealed to @protected. I'm not sure sure about adding a new protectedMode flag with behavior to error or warn. Processors, such as my own, may implement their own validation mode to raise errors for different cases (e.g. strict checking of values). Otherwise, we may want to just make it an error, and tacitly allow processors to work in a more forgiving mode. In any case, the WG needs to discuss this, as all we've approved is that a warning should be issued.

I'd suggest separating these concerns and keep this one purely on changing @sealed to @protected, then we can address protectedMode in a separate issue, and consider other things that might be included.

[iherman]

I'd suggest separating these concerns and keep this one purely on changing @Sealed to @Protected, then we can address protectedMode in a separate issue, and consider other things that might be included.

I am in favor of this.

[davidlehn]

I'm making a mess of PRs, sorry! ;-) I made a new PR for just the first commit of this PR that just does the renaming: #70. Can discuss that part there and the extra bits here.

[davidlehn]

I'm in favor of @protected violations causing an error by default. Continuing processing is possible but at that point I'm pretty sure you can/will end up with possible garbage output that didn't match the authors intent? It seems that there are use cases where you may want to process data anyway, hence the idea of a mode flag. I'm unclear if that should be a defined spec mode or just a bonus processor feature.

The spec text as is could be improved. But maybe this is moot if the behavior ends up changing. The current language says that processing is aborted and processors should issue a warning. Does "processing is aborted" mean throw an error and quit? Or just abort that algorithm step and continue? (Based on the tests, you continue.) When it's a warning, what is the behavior? Is that something that should be defined and tested?

Since the tests were written to test against warning mode output, this patch at least tries to improve that test coverage for protected terms and null contexts. Tests were also added for the error cases since I imagine implementors would want something like that. But that does depend on specific error strings and spec text.

Happy to adjust all this as needed.

[gkellogg]

For w3c/json-ld-syntax#137.

[gkellogg]

Closed in favor of #78.