Roadmap

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.

"Partial" validation

The idea: to validate only part of an instance. If we are given a schema, a JSON Pointer (into the instance) and a JSON node, validate only that part against the necessary schema(s). Quoting from a mail:

• I have a RESTful API with JSON payloads
• I rely on JSON Schema validation for full payloads (in other words, I am always passing the resource back and forth)
• I have the realities of a mobile environment which is sensitive to battery and bandwidth consumption
• Thus, I have a partial update scenario (as do we all)

So, how do I validate the partial update against the schema itself without having to do something stupid like suck in the resource to be modified, apply the JSON Patcha and run it through the schema as a whole object? How do I do that without partitioning my schema into client-specific sub-schemas?

I love the idea of using JSON Pointer within the schema to validate the particular changes coming from the client AND it seems like that approach actually syncs pretty well with the partial update strategy of JSON Patch.

The idea is seducing. There are, however, a few obstacles:

• when it comes to object instances, one child instance may have to obey more than one schema;
• it is possile to "filter" through what schemas have to be valid, but that means either:
  • the JSON patch tells us about this;
  • the schema tells us that, for a given path, only a certain container type is valid.