Proposal: opt-in opinionated mode

[handrews]

jschon includes three sensible but technically non-compliant checks:

• restricting $dynamicRef to plain name fragments (issue "$dynamicRef" to non-dynamic URI #64)
• forbidding unnormalized $id values (issue "$id" is (slightly) non-compliant (hidden by errors in JSON Schema Test Suite) #69)
• forbidding even empty fragments in $id in 2019-09 and 2020-12 (also issue "$id" is (slightly) non-compliant (hidden by errors in JSON Schema Test Suite) #69)

PR #66 simply removes the $dynamicRef check, but the check is only non-compliant if it is on by default. An alternative could be to offer an opt-in "opinionated mode" that can be configured on the Catalog instance.

I'm suggesting "opinionated mode" rather than "strict mode" because AJV's "strict mode" is problematic and confusing, and I'd advise against anything that sounds like it. Although I'm not particularly attached to "opinionated mode", it just feels like truth in advertising :-)

I considered referring to this as linting, but because of how references are resolved and loaded, it's difficult to check everything up front as one would expect from a linter. A mode that raises runtime errors for things that are compliant but viewed by jschon (a.k.a. @marksparkza 😉) as worth excluding would fit the current architecture quite easily.

I don't feel at all strongly about this, it just occurred to me as an alternative to simply removing the checks that the spec technically forbids.

[marksparkza]

Any global switch for non-compliant behaviour is potentially problematic, because (a) it requires digging into code or documentation to find out exactly what an enabled switch entails, (b) what it entails can change from one release to the next, and (c) it forces non-compliance across multiple spec requirements even if only one such adaptation is needed.

I think any point of divergence between spec and implementation should be addressed on its own merits. In cases where non-compliant behaviour makes sense, this could be enabled with a specific switch (probably a kwarg to create_catalog). This way, application code is explicit about enabling any non-compliant behaviour, and that behaviour can be clearly documented along with the switch that enables it.

We can look at specific switches as part of the above issues/PRs.

[handrews]

@marksparkza sounds good to me - I'd actually prefer not to have such switches for exactly this reason:

Any global switch for non-compliant behaviour is potentially problematic, because (a) it requires digging into code or documentation to find out exactly what an enabled switch entails, (b) what it entails can change from one release to the next, and (c) it forces non-compliance across multiple spec requirements even if only one such adaptation is needed.

I was just sympathetic with some of the technically non-compliant choices and exploring options. I'm plenty happy to not do anything about it!