Skip to content

Roadmap

Jump to bottom
fge edited this page Jan 7, 2013 · 127 revisions

In 1.5

Draft v4 hyper schema validation

Not that simple. There are a few one-one relationships, but href, for instance, is another matter. RFC 6570 is not an easy beast, and the current v4 hyper-schema draft expands upon it even more...

Recursive schema validation

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.

Better "metaschema" encapsulation (in progress)

Right now, there is SchemaURIs, KeywordRegistries and even BuiltinSchemas. This is rather messy. Unify all this in a nicer way.

Nearly there. Just need to make the code a little nicer.

Candidate features

Not necessarily in order!

Better URI handling

  • Right now, the .addRedirection() method of JsonSchemaFactory only knows how to redirect fully qualified URIs to schemas. Allow to redirect full paths as well.
  • Revamp URI handling in general by introducing the notion of a scope.

Include title and description in error messages

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.

Cache entries with expiry

Right now, when a schema is fetched from any URI, it is cached permanently until the application shuts down. This is inappropriate in a good number of usage scenarios (for instance, HTTP with an expiry time of 0).

Extend/replace URIDownloader to account for this.

ehcache seems to be the most likely candidate, however it is far from being simple: ideally, both keys and values would have to implement Serializable. Ugh.

Clone this wiki locally