Ideas on JSON Schema
Posted by david, Fri Feb 01 00:18:00 UTC 2008
So I have a selfish desire for some form of JSON schema, as the types used within the system would greatly help in parsing JSON into Java objects. I’m trying to limit my current thinking to the fundamentals:
- JSON has several types of values: string, number, boolean, array, object, and the value null
- JSON schema would allow you to define which types of values, and which values themselves, are legal for a particular object, object member, or array
- As declared, those declared legal values would have schemas themselves
- For reuse, schemas should be able to be referenced by URI, with a strong recommendation to have that URI resolvable to the authoritative schema document
- For security and Denial-of-service resistance, it is strongly recommended to not resolve URIs looking for referenced schemas, at least as part of message processing.
- There are three classifications of schema types
- Native types
- Types which are unable to be expressed within JSON schema themselves. This includes the core schema types, described later
- Derived types
- A type, based on another type either in a subclass relationship or merely as a starting point, defining restrictions on what values are considered legal.
- Union types
- A choice between two or more other types, such as
"either a boolean or a string"
- Derived types should only define further restrictions of their base type for simplicity. They should not allow values which are considered legal by their base type.
- Further schema can be declared dynamically within a document, although it only can specify the schema in place or further restrict the document further than any existing schema. A processor may choose to ignore the specified schema and go with preexisting validation rules.
- Union types can specify one or more schema types which overlap, in which case the first valid match ‘wins’
- A Union type of
'URI or String'would thus cause the value"http://www.blog.alkaline-solutions.com"to always be accepted by the URL rule, even if it was a ‘string’ value in the base document. If special processing occurs based on type, this needs to be taken into account - A union type of
'http-url or string'would thus not have a clean derived relationship from the above'URI or String'- a value accepted before by the URI rule would now be interpreted by a completely different rule instead of being rejected. - For that reason, and for simplicity, union types can only be derived as a whole, with restrictions being applied to every member
- Because a schema valid value could be one of several JSON types, it makes sense to have restrictions be specific to each kind of JSON value, rather than (for example) having maximum apply to numerical value, array element count, and string length