'required' in 1.0.0 no longer works as in 0.8.0

[ptallada]

Hi,

In 0.8.0, the None value would validate with the following schema:
{
"type" : "null",
"$schema" : "http://json-schema.org/draft-03/schema",
"required" : true
}

Now, with the same schema, in 1.0.0 it fails with the following error:

SchemaError(u"True is not of type u'array'", u'type', deque([u'required']))

[Julian]

Hi.

This is because your $schema does not match the one predefined by JSON Schema for Draft 3. The one defined for Draft 3 has an empty fragment, so it's http://json-schema.org/draft-03/schema#.

So the behavior there is because it's falling back to Draft 4 since it doesn't know about that $schema. You can try that for yourself by doing Draft3Validator.check_schema(t) and seeing no error (and if you validate with a Draft3Validator you'd have no problems).

Whether or not without the fragment should also be recognized as draft 3 I think revolves around another discussion that has been going on about relative URIs vs JSON References, so I'm not sure: @fge @gazpachoking should http://json-schema.org/draft-03/schema and http://json-schema.org/draft-03/schema# both be accepted for draft 3 schemas?

[fge]

@Julian

should http://json-schema.org/draft-03/schema and http://json-schema.org/draft-03/schema# both be accepted for draft 3 schemas?

Yes, since the first is the URI of the document itself, and the second is the empty pointer into that document -- ie, for all practical purposes, the document itself.

[Julian]

OK, sounds good. Thanks for confirming. I guess to properly implement $schema will require integrating ref resolution to resolve any registered $schemas then.

[gazpachoking]

@Julian Do we really need to resolve the schemas? I was actually wondering about this the other day. @fge The spec says: "this URI MUST be both absolute and normalized." Wouldn't the normalized form either have the # or not, thus making the other way invalid?

[fge]

On Fri, Mar 1, 2013 at 8:22 PM, Chase Sterling notifications@github.com wrote:

@Julian Do we really need to resolve the schemas? I was actually wondering about this the other day. @fge The spec says: "this URI MUST be both absolute and normalized." Wouldn't the normalized form either have the # or not, thus making the other way invalid?

Hold on, "$schema" is not "$ref". You don't need to resolve it. But if
you want to, then this is a JSON Reference, and as far as JSON
Reference is concerned, no fragment or an empty fragment is the same
(they are two different URIs, yes, but they reference exactly the same
content).

And when normalizing a URI, whatever it is, the fragment is always
left intact. Or did I misread your question?

Francis Galiegue, fgaliegue@gmail.com
JSON Schema in Java: http://json-schema-validator.herokuapp.com

[fge]

On Fri, Mar 1, 2013 at 8:28 PM, Francis Galiegue fgaliegue@gmail.com wrote:
[...]

Hold on, "$schema" is not "$ref". You don't need to resolve it. But if
you want to, then this is a JSON Reference, and as far as JSON
Reference is concerned, no fragment or an empty fragment is the same
(they are two different URIs, yes, but they reference exactly the same
content).

FWIW, this is why I have a JsonRef class: it not only normalizes
URIs behind the scene, but "canonicalizes" them so that no fragment is
replaced by an empty fragment. As such, when I .getPointer(), I
always get a JSON Pointer -- even empty. And, of course, "x://y" and
"x://y#" are equal with this implementation.

Francis Galiegue, fgaliegue@gmail.com
JSON Schema in Java: http://json-schema-validator.herokuapp.com

[gazpachoking]

And when normalizing a URI, whatever it is, the fragment is always
left intact. Or did I misread your question?

Yeah, that answers it. I just thought that after normalization there would be one way to refer to the same schema, rather than the # still being optional.

[gazpachoking]

@Julian I think we just need to go with @fge's method, we'll 'canonicalize' the uri (by adding an empty fragment if there isn't one) both when adding to our metaschema dict, and when reading $schema

[gazpachoking]

Fixed in #77

[Julian]

Thanks for reporting this @ptallada . There will be either a bugfix release or a minor release tomorrow so this should hit you soon if you're not on HEAD. Cheers.

[ptallada]

Wow, what a fast response :D

Thank you very much!