-
Notifications
You must be signed in to change notification settings - Fork 398
Roadmap
Support both canonical addressing and inline schema addressing.
DONE: an addressing mode has to be specified when building a JsonSchemaFactory, and SchemaContainer has become an abstract class; one implementation does id lookup. What is more, it is up to this class to resolve references and tell whether a given reference is contained within it.
RFC 3522 seems to require that emails have a domain part. RFC 1034 is unclear as to whether this is the case for hostnames.
Done: hostnames do not require more than one component, emails should have a domain part.
The $schema keyword is not limited to what the draft defines, a custom URI can be provided to one's own schema (whether it be the core schema, the hyper schema etc).
Provide a means to support such custom schemas, starting with draft v4.
DONE: the implementation now has draft v4 support. It is still draft v3 by default. Format attributes defined by draft v3 have been re-integrated.
The library can do quite a lot; however, documentation is not up to snuff. Provide detailed examples.
DONE
The definition of numeric value equality is that the mathematical value of numbers should be equal. But then it means 1.0 is equal to 1.
Right now, the code considers these two as being unequal. Also, the type should be preserved: 1.0 is a number but not an integer.
DONE
No processing, but at least syntax checking.
DONE, but sketchy.
It only has one method remaining. It'd be better to just use a custom ObjectNode implementation, which can
be optimized for our use cases.
Especially, the .emptySchema() hack is particularly ugly.
DONE
Not necessarily in order!
Right now, the .addRedirection() method of JsonSchemaFactory only knows how to redirect fully qualified
URIs to schemas. Allow to redirect full paths as well.
Right now, only the "current level" of the schema is checked. That is, with:
{
"properties": {
"p": { "type": "string" }
}
}when starting from the root, only the correctness of properties is checked, but the schema for p is not.
Validating all of the schema at once instead unfortunately requires quite a lot of changes.
When reporting error messages, right now we only mention the keyword causing the failure. JSON Schema has title and description, but right now these are completely ignored (except at the syntax checking level).
On the other hand, since the implementation is purely server side, this feature may be done without. And the problem would then be to transmit these informations down the path (in ValidationContext?), and insert them in messages.