uri reference is invalid

why is a uri reference invalid? The rfc says they are valid uris
and the json schema spec does not forbid them afaict: http://json-schema.org/latest/json-schema-validation.html#anchor123

but this test exists:
https://github.com/json-schema/JSON-Schema-Test-Suite/blob/468fa788ca2053a69815c43abc500e044086120c/tests/draft4/optional/format.json#L39

so I'm curious to find out why

This is indeed a bug; this test should be removed.

Or at least it should be modified so that this test passes.

Uh, yeah, I remember this -- I forgot if we got to a conclusion (obviously not if we didn't change the test back again) but I think you're right -- the draft 3 and draft 4 specs are very confusing, but they allow this (unfortunately). We need to fix it in draft 5 though, having URI references be valid is extremely surprising to people.

See http://tools.ietf.org/html/rfc3986#section-5.4.1 or just verify with any well tested library code, e.g. Qt's QUrl in strict parsing mode. The test is plain wrong.

I'm not sure what you're pointing out with that (that's not a relevant section) or what you mean by checking Qt. The spec is contradictory, we'll address it in draft 5. I'm not sure what to do about the test in the meantime, I have no issue either dropping or leaving it but we've flip flopped twice now, so I'm inclined to leave it given how long it's been in, until draft 5 is out.

👍 . So change to Absolute URI? This is not an "absolute URI" either -

JSON-Schema-Test-Suite/tests/draft4/optional/format.json

Line 33 in 9723c8f

"description": "a valid protocol-relative URI",

. That should be update too.

@casualjim Note: this was fixed in draft 5 by adding the "uriref" format and reserving "uri" for non-references only.

Closing this, should be addressed properly now in Draft 6