Skip to content

Roadmap

fge edited this page Sep 8, 2012 · 127 revisions

In 1.1

Make ref resolution failure fatal (done)

Example: in disallow, an unreachable $ref is encountered. This is normally an error, but disallow, as the implementation currently processes it, lets this pass silently.

Nicer user API (done)

Right now, the user API is rather messy, with plenty of methods named *Schema(), not all of which actually return a JsonSchema instance.

Find better names, make it easier to get hold of a schema.

Candidate features

Not necessarily in order!

Include name and description in error messages

When reporting error messages, right now we only mention the keyword causing the failure. JSON Schema has name and description, but right now these are completely ignored.

Try and insert them?

Android support

Android is a platform with many potential uses for such a library. Check compatibility, and see the cost to make the library fully compatible.

Accepting input from other JSON libraries

Jackson is the library to use for anyone wanting to do JSON in Java, but there are plenty others. Design an interface of some sort so that people can transform their existing JSON data to JsonNode.

Probably required for Android support...

Untangle the type/disallow/extends/dependencies mess

These 4 keywords can potentially spawn other validators from within themselves. The draft is written like this... Try and find a more generic way to spawn validators: array and object validation in general also spawn validators.

This potentially requires a complete change of the internals. Also, there is the difficuly that we want to keep the "keyword validators built by reflection" feature, which is the accelerating feature of this library.

Make URIs from various sources

The main problem: exceptions vary. For instance, File's .getCanonicalFile().toURI() throws an IOException, but URL's .toURI() throws a URISyntaxException. All exceptions would need to be wrapped, and it should also be ensured that no unchecked exceptions are thrown.

Also, define "sources". Files and URLs are two obvious candidates. Strings? InputStreams?

Last but not least: how can this integrate nicely and transparently?

Add a main?

Could be nice... That would mean creating a manifest (obviously) and also find a way to create a "complete" jar, ie a jar including all dependencies. TODO: check whether licenses get in the way.

Clone this wiki locally