Allow boolean schemas everywhere (root and subschemas)

[handrews]

This implements issue #101, including root schemas.

@awwright requested this form of the solution to compare against PR #128,
which only defines booleans for subschemas. The idea is that it is sometimes
useful to have an entire schema which always passes or always fails, and
the idiom should be the same everywhere.

Note that with RFC 7159,
the restriction that JSON documents could only be arrays or objects
was removed, so a single boolean value is a valid JSON document.

I slightly prefer this to PR #128, myself.

Also add JSON Reference objects as legal schemas in the meta-schema.

Since "$ref" is now only allowed as a JSON Reference where a schema
is acceptable, it can now be described in JSON Schema and included
in the "anyOf" that defines legal subschemas.

[awwright]

Why is this PR so much bigger than #128? All it really needs to do is add "boolean" to the list of of "type"s

[handrews]

@awwright LOL you're right, I'll fix it.

[handrews]

@awwright Actually, that will fix the "bool" part, but not the "$ref" part, which still needs the reorganization of schemas. But I will simplify the bool part with types.

[handrews]

@awwright if you want to see the meta-schema changes step-by-step take a look at json-schema-org/json-schema-org.github.io#57

[handrews]

@awwright I put the already-necessary schema reorganization for "$ref" (plus other changes) in PR #168 in a series of easy-to-review commits. I'll add the meta-schema changes back to this after PR #168 is approved, since it will at that point just be adding "boolean" to the type like you suggest.

[epoberezkin]

I prefer #128. I think allowing root schemas to be booleans is a bad idea.

[handrews]

I prefer #128. I think allowing root schemas to be booleans is a bad idea.

Why?

You may have a schema that starts out with some constraints, but looses them as the API (or whatever) evolves. There is no functional difference here, except for enabling some slight optimizations in implementation.

[epoberezkin]

One reason is that schema should have id. Another is that root schema is JSON-document while subschema is not.

[handrews]

A single boolean is a valid JSON document per RFC 7159 (this was a change from the previous RFC, recognizing that in practice, any JSON value is acceptable as a JSON document to most implementations).

I think it is important to look at booleans-as-JSON Schema-documents not as a generally recommended practice, but as a consistency feature that is useful in evolving JSON Schema ecosystems. I would not write a standalone boolean schema when designing a new system, but I might end up with one.

In particular, being able to declare a schema of false in hypermedia indicates that a resource is no longer supported. This is very useful.