Roadmap

Introduction

This page documents the features of upcoming versions 2.0.x.

This version fixes some shortcomings of the current stable versions while retaining all of its features. Its internal rearchitecturing, also documented in this page, will bring entirely new possibilites currently very hard to achieve with 1.x.

Shortcomings addressed

Schema addressing rework

While the current stable version does a good job in general, it is not really in line with the specification; in particular, it does not define URI scopes as per the current specification (draft v4).

Version 2.0.x removes that limitation. It still retains the ability to redefine URI scopes, preload schemas, support arbitrary schemes etc.

Separate syntax validation

Versions 1.x did not allow for separate syntax validation, this version will do. Moreover, schema syntax validation is recursive (note that the last 1.x version, 1.6.x, will also do this, but less efficiently).

Customized logging/validation behaviour

Versions 1.x never threw exceptions when validating, save for unchecked exceptions. With 2.0.x, this becomes an option, along with the ability to stop at the first validation error.

The new logging system will also allow to log messages at different levels, while 1.x really had only one level -- error.

New architecture

Here is a preview of the new core architecture of this library. For 2.0.x, these will be split into a separate package, which this library will depend upon.

Processors, processor chains and selectors

All steps of the validation process (JSON Reference resolution, syntax checking, schema digesting, keyword building, validation) are now separate processors. The existence of these processors is why 2.0.x allows separate syntax validation whereas 1.x could not.

The main interface is Processor. It has two helper classes: ProcessorChain and ProcessorSelector. The first allows to chain processors together, provided their inputs and outputs are compatible; the second one allows to "dispatch" processing to different processors according to a truth value (this truth value uses Guava's Predicate interface).

Here is a sample code showing what is possible:

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();

The validation itself uses such a combination of chained and selected processors, and is itself a processor. You will therefore be able to use it in your own, customized chains.

Logging

The base interface for this is ProcessingReport. It contains logging methods with familiar names like .debug(), .info(), .warn() and .error(). As it is an interface, the way to handle messages passed as arguments (which are always ProcessingMessages) is entirely up to implementations.

The bast abstract class implementing this interface allows you to set the logging threshold and exception threshold as well, which is how you can tell the validation process to stop at the first error.

Future plans

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.