Skip to content

Add tests for location-independent identifiers #225

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 2 commits into from
Jun 30, 2019
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
105 changes: 105 additions & 0 deletions tests/draft4/ref.json
Original file line number Diff line number Diff line change
Expand Up @@ -296,5 +296,110 @@
"valid": false
}
]
},
{
"description": "Location-independent identifier",
"schema": {
"$ref": "#foo",
"definitions": {
"A": {
"id": "#foo",
"type": "integer"
}
}
},
"tests": [
{
"data": 1,
"description": "match",
"valid": true
},
{
"data": "a",
"description": "mismatch",
"valid": false
}
]
},
{
"description": "Canonical location-independent identifier",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to avoid the word "canonical" due to its role in the confusing draft-04 canonical vs inline mess.

I'm not entirely sure it applies to this case even in draft-04 terms, but TBH none of the current spec team really know what the point of that was AFAIK.

Is the point of this test to use a URI (with scheme) rather than a URI reference? If so, that seems like the thing to note in the description.

"schema": {
"$ref": "http://localhost:1234/bar#foo",
"definitions": {
"A": {
"id": "http://localhost:1234/bar#foo",
"type": "integer"
}
}
},
"tests": [
{
"data": 1,
"description": "match",
"valid": true
},
{
"data": "a",
"description": "mismatch",
"valid": false
}
]
},
{
"description": "Location-independent identifier with base URI change in subschema",
"schema": {
"id": "http://localhost:1234/root",
"$ref": "http://localhost:1234/nested.json#foo",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does having id adjacent to $ref work? I'd really rather wrap the $ref in an allOf. I know that within the spec we allow adjacent definitions, and I suppose that argument could be extended to id. But really it's a gray area/bug in the spec and implementations are not consistent about whether it's supported.

"definitions": {
"A": {
"id": "nested.json",
"definitions": {
"B": {
"id": "#foo",
"type": "integer"
}
}
}
}
},
"tests": [
{
"data": 1,
"description": "match",
"valid": true
},
{
"data": "a",
"description": "mismatch",
"valid": false
}
]
},
{
"description": "Location-independent identifiers should take precedent over regular fragments",
"schema": {
"$ref": "#foo",
"definitions": {
"A": {
"id": "#foo",
"type": "integer"
}
},
"foo": {
"type": "string"
}
},
"tests": [
{
"data": 1,
"description": "match",
"valid": true
},
{
"data": "a",
"description": "mismatch",
"valid": false
}
]
}
]
105 changes: 105 additions & 0 deletions tests/draft6/ref.json
Original file line number Diff line number Diff line change
Expand Up @@ -328,5 +328,110 @@
"valid": false
}
]
},
{
"description": "Location-independent identifier",
"schema": {
"$ref": "#foo",
"definitions": {
"A": {
"$id": "#foo",
"type": "integer"
}
}
},
"tests": [
{
"data": 1,
"description": "match",
"valid": true
},
{
"data": "a",
"description": "mismatch",
"valid": false
}
]
},
{
"description": "Canonical location-independent identifier",
"schema": {
"$ref": "http://localhost:1234/bar#foo",
"definitions": {
"A": {
"$id": "http://localhost:1234/bar#foo",
"type": "integer"
}
}
},
"tests": [
{
"data": 1,
"description": "match",
"valid": true
},
{
"data": "a",
"description": "mismatch",
"valid": false
}
]
},
{
"description": "Location-independent identifier with base URI change in subschema",
"schema": {
"$id": "http://localhost:1234/root",
"$ref": "http://localhost:1234/nested.json#foo",
"definitions": {
"A": {
"$id": "nested.json",
"definitions": {
"B": {
"$id": "#foo",
"type": "integer"
}
}
}
}
},
"tests": [
{
"data": 1,
"description": "match",
"valid": true
},
{
"data": "a",
"description": "mismatch",
"valid": false
}
]
},
{
"description": "Location-independent identifiers should take precedent over regular fragments",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm trying to figure out the failure mode of this test case. Is there reason to think that an implementation might insert a / after the # and convert it into a pointer?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At first I didn't notice the difference between JSON pointers which require a / and a regular plain fragment which doesn't. Now on second glance this test makes no sense and I'll remove it as it is only confusing and has no purpose.

"schema": {
"$ref": "#foo",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really want the $refs to all be in allOfs, I've decided. It's such a confusing and underspecified area, when you then start throwing in odd corner cases like an unrecognized "foo" keyword alongside a $ref I have absolutely no idea what should happen, and even less clue what the majority of implementations will do.

Let's avoid gray areas except when explicitly testing around them.

"definitions": {
"A": {
"$id": "#foo",
"type": "integer"
}
},
"foo": {
"type": "string"
}
},
"tests": [
{
"data": 1,
"description": "match",
"valid": true
},
{
"data": "a",
"description": "mismatch",
"valid": false
}
]
}
]
105 changes: 105 additions & 0 deletions tests/draft7/ref.json
Original file line number Diff line number Diff line change
Expand Up @@ -328,5 +328,110 @@
"valid": false
}
]
},
{
"description": "Location-independent identifier",
"schema": {
"$ref": "#foo",
"definitions": {
"A": {
"$id": "#foo",
"type": "integer"
}
}
},
"tests": [
{
"data": 1,
"description": "match",
"valid": true
},
{
"data": "a",
"description": "mismatch",
"valid": false
}
]
},
{
"description": "Canonical location-independent identifier",
"schema": {
"$ref": "http://localhost:1234/bar#foo",
"definitions": {
"A": {
"$id": "http://localhost:1234/bar#foo",
"type": "integer"
}
}
},
"tests": [
{
"data": 1,
"description": "match",
"valid": true
},
{
"data": "a",
"description": "mismatch",
"valid": false
}
]
},
{
"description": "Location-independent identifier with base URI change in subschema",
"schema": {
"$id": "http://localhost:1234/root",
"$ref": "http://localhost:1234/nested.json#foo",
"definitions": {
"A": {
"$id": "nested.json",
"definitions": {
"B": {
"$id": "#foo",
"type": "integer"
}
}
}
}
},
"tests": [
{
"data": 1,
"description": "match",
"valid": true
},
{
"data": "a",
"description": "mismatch",
"valid": false
}
]
},
{
"description": "Location-independent identifiers should take precedent over regular fragments",
"schema": {
"$ref": "#foo",
"definitions": {
"A": {
"$id": "#foo",
"type": "integer"
}
},
"foo": {
"type": "string"
}
},
"tests": [
{
"data": 1,
"description": "match",
"valid": true
},
{
"data": "a",
"description": "mismatch",
"valid": false
}
]
}
]