Roadmap

The road to 2.0.x

Below are the features which are fully done and tested -- they only lack the final polish and documentation:

Processors, processor chains and selectors

The main interface is Processor<IN, OUT>. This interface is at the core of all the validation process. It has two helper classes: ProcessorChain and ProcessorSelector. This is a sample code showing what you can do with it, and how it actually happens internally:

final Processor<In, Out> choice1 = ProcessorChain.startWith(p1).chainWtih(p2).failOnError().etc().end();
final Predicate<In> predicate1 = somePredicate();

// etc etc. And then:

final ProcessorSelector<In, Out> selector = new ProcessorSelector<In, Out>
    .when(predicate1).then(choice1)
    .when(predicate2).then(choice2)
    .etc().etc()
    .otherwise(defaultProcessor);

final Processor<In, Out> realProcessor = selector.getProcessor();

Voilà! Completely customizable processing chain.

Note that the default class for validation is not a processor itself, but you will be able to get hold of its internal processor and customize your whole chain.

Customizable logging

This API breathes JsonNode and talks JsonNode. Even for its default reports. However, you can customize it yourself.

The base interface for this is ProcessingReport: it contains the ultra classical .debug(), .info(), .warn() and .error() methods. And these can, of course, be implemented the way you wish, along with the log level threshold and exception threshold; which means you can, for instance, stop at the first error without going any further.

Full validation of draft v3 and draft v4

Compared to the previous versions, the logging is now more complete and accurate. And you will be able to get hold of a syntax validator alone, unlike in the previous versions, since syntax validation is one processor among others.

Full customization of URI namespaces, schemes support, format attributes, keywords etc

Like before! Nothing new here, except the classes to implement have changed. All this will be documented before the final 2.0 release, of course -- with sample code.

For 2.0.x final:

The processor and logging infrastructure will eventually have their own package, upon which this library will depend. This is mainly because other processors can be written to completement the validation API. For instance:

• conversion from other JSON libraries (Gson, org.json) to Jackson;
• partial updates validation: given a schema and a pointer into an instance, find the appropriate subschemas; validate only against said subschemas;
• schema generation from annotated POJOs: there is actually a project aiming at doing that (https://github.com/reinert/JJSchema); chain this before the validation chain;
• the reverse (POJO generation from schemas): build a processor for http://code.google.com/p/jsonschema2pojo/, chain it after syntax validation.

Etc etc.