-
Notifications
You must be signed in to change notification settings - Fork 398
Status
ALL of section 6 is for now unsupported. Mainly because the author doesn't understand much about it... I prefer to leave it untouched rather than implementing crap :p
Also, section 5 has three missing keywords:
- default,
- $schema,
- id.
The default keyword is likely never to be supported since this API is about validation only (unless, that is, I decide on doing JSON Patch along with JSON Schema). As to the two other ones, they are important schema metadata which are in the plans. Just not yet, though.
The draft is quite clear that regexes should conform to ECMA 262, even though it doesn't say it explicitly. This rules out java.util.regex entirely. The choice here has been to use Rhino's Javascript engine for regex support -- you can't really get any closer.
Also, even though the draft only implies it (and as the Javadoc points out in several places), please note that the definition of matching is the real one, not the "Java one": a regex can match anywhere in the input! So, remember this when writing your schemas -- if you want your regex to match the whole input, you have to anchor them! This is valid for the pattern keyword, but also for keys in patternProperties, so beware. A JSON Schema implementation which doesn't act this way is broken.
These are two of the format specifications defined by the draft (resp. host-name and email). The fine points:
- nothing in the RFC defining hostnames say they should be fully qualified -- so, non FQDN hostnames will validate;
- nothing in the RFC defining mail addresses say they should have a domain component either -- so, non fully qualified email addresses will validate as well.
This implementation strictly obeys the RFCs. As the draft doesn't specify either of the two points above, the RFCs are enforced by default, and non FQDN hostnames and emails without a domain component are valid.