-
Notifications
You must be signed in to change notification settings - Fork 398
Roadmap
Support both canonical addressing and inner schema addressing, via a feature. Or an addressing mode?
Mostly done: an addressing mode has been chosen instead, and it can be used to tell a registry to look up id first in schemas. For this, SchemaContainer has become an abstract class and one of its implementations does id lookup. What is more, it is up to this class to resolve references and tell whether a given reference is contained within it. More tests are needed, though.
RFC 3522 seems to require that emails have a domain part. RFC 1034 is unclear as to whether this is the case for hostnames.
The current state of affairs is therefore rather messy, and it is unclear whether I do the right thing. Sort it out and get back in line with what is really expected. The first guess is that both format specifiers should require a domain part by default. It makes sense ultimately, and this is what users will probably expect in the long run.
Of course, when it comes to host names, we DO NOT want to perform hostname lookups. If the underlying OS relies on a network service which happens to be poorly responsive, we are doomed.
Keywords are mostly there. Start to implement them.
Not necessarily in order!
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.
The definition of numeric value equality is that the mathematical value of numbers should be equal. But then it means 1.0 is equal to 1.
Right now, the code considers these two as being unequal.
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.
Android is a platform with many potential uses for such a library. Check compatibility, and see the cost to make the library fully compatible.
It appears that it is already compatible, save for potential differences in delicate parts of the JDK, such as BigDecimal. Jackson and Guava both work for Android and those are the only two dependencies of the core package.
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...
There already exists a toy implementation in test sources which can transform Gson's JsonElement to JsonNode and back, with tests, and it works quite well -- I fail to see how I would integrate that however
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?
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.
Stop at first validation failure, even non fatal; no messages are collected.
Useful if you are only interested in whether your JSON is valid and don't care about what errors crept in.
The problem: disallow.
A neverending work!