Validation conflict for "id" property

[vearutop]

According to spec https://github.com/json-schema-org/json-schema-spec/blob/master/archive/draft-04/schema.json#L32

        "id": {
            "type": "string",
            "format": "uri"
        },

Format uri is invalid for local references (https://github.com/json-schema-org/JSON-Schema-Test-Suite/blob/master/tests/draft4/optional/format.json#L44):

            {
                "description": "an invalid URI though valid URI reference",
                "data": "abc",
                "valid": false
            }

Which makes test data invalid for id property here https://github.com/json-schema-org/JSON-Schema-Test-Suite/blob/master/tests/draft4/refRemote.json#L57

            "items": {
                "id": "folder/",
                "items": {"$ref": "folderInteger.json"}
            }

[handrews]

@vearutop The draft-04 meta-schema corresponds to draft-zyp-json-schema-04 and draft-fge-json-schema-validation-00. In those drafts, the "uri" format was unclearly specified and broadly interpreted to mean both URI and URI Reference.

This was not fixed until draft-wright-json-schema-validation-00 with "uriref" (which becomes "uri-ref" in the next draft for consistency with "date-time" and other compound names).

So I believe this test is correct against the draft-04 meta-schema. Or at least it enforces the way that the majority of implementations interpreted an unclear specification.

[vearutop]

@handrews Which test you consider correct: format.json or refRemote.json?

I see inconsistency in these three code snippets that could be resolved in one of three ways:

• id should not have "format":"uri", possibly it could have "format":"uri-reference" as in latest schema revision (not draft-04 though)
• change test to allow "format:"uri" for local references (which does not make much sense for all other uri use-cases).
• remove base URI change tests from refRemote.json

So my end-user problem is how to pass both tests gracefully in this unclear situation. Could you advice a solution?

Is format.json test marked as optional because of this?

[handrews]

@vearutop ugh, I see what you mean now, my apologies.

format.json is marked optional because supporting the "format" keyword is optional: Conforming implementations are allowed to ignore it.

As for which is correct, I'm going to defer to others on that. I suspect many users of draft-04 expect "format": "uri" to accept URI References, but I'll leave it to @Julian (who owns the test suite), @epoberezkin (who I think added base URI test) and/or @awwright (who clarified how it all worked in the following draft) to make the call here. @Julian and @epoberezkin both maintain implementations and probably know what their users expect.

[Julian]

I've just gotten back from London, and now will be a bit tied up until Thursday, but basically the way I wrote the tests, and the way I think most implementers ended up going, was to call "format": "url" a mistake in the meta-schema for id -- i.e. to interpret url as being only URLs, but to indeed allow url references for the id validator.

Some of the tests have changed recently though, in an effort to make them more consistent, but clearly we're not all the way there yet.

If anyone has a chance to weigh in here, would love to hear it, otherwise I'll try to have a look later in the week.

[erayd]

...was to call "format": "url" a mistake in the meta-schema...

@Julian Does that also apply to $ref for draft-03?

[handrews]

@Julian @vearutop @erayd my inclination is to leave things as they are here:

• I don't think there's a whole lot of activity with draft-03 these days, beyond migrating off of it. I'm certainly not inclined spend time on fixing anything about it.
• I agree with @Julian's view of there being a bug in the draft-04 meta-schema. I'll note that the draft-04 meta-schema doesn't actually even include the format keyword :-P It uses it, but does not describe it!

If we "fix" anything, I'd be inclined to re-publish the draft-04 schema with bugs fixed since it's not a normative part of the I-D. @awwright any thoughts on that?

I think that means we can close this, as the test case is correct.

[handrews]

The draft-04 meta-schemas have been fixed and re-published, so there is no longer a conflict here.