Do not use definitions sibling to $ref in ref.json for Draft 3#897
Do not use definitions sibling to $ref in ref.json for Draft 3#897
definitions sibling to $ref in ref.json for Draft 3#897Conversation
I'm extending Blaze to support Draft 3. As per the spec (applies to all drafts up to 7), a `$ref` overrides any sibling keyword. This seems to be the only case in the test suite where we do this.
jdesrosiers
left a comment
There was a problem hiding this comment.
a
$refoverrides any sibling keyword
Technically, anything other than $ref in a reference object is ignored. That just means that it's meaningless in that context. However, anything that's referenced can be processed as a schema. So when the reference is followed, there's no problem with the referenced location being evaluated.
The part that's ambiguous is whether a reference object should be treated as a scalar object or a structured value. If it's a scalar, you can't point to it with a JSON Pointer and therefore, the reference can never reach its intended target. Most implementations treat it as structured value and the reference can resolve just fine. Personally, I think it makes more sense for reference objects to be treated as scalars.
Do to that ambiguity, we've decided not to have required tests that depend on resolving pointers into reference objects. However, we've also decided we aren't going to maintain the draft-03 tests anymore. I'm ok with making this change, but I don't think we should be spending a lot of time on draft-03.
|
Awesome. For context, I'm working to allow Draft 3 ingestion in Sourcemeta One to support automated upgrades. Some people do still use Draft 3 and want to auto-upgrade. |
I'm extending Blaze to support Draft 3. As per the spec (applies to all drafts up to 7), a
$refoverrides any sibling keyword. This seems to be the only case in the test suite where we do this.