Specify "if", "then", and "else"

This addresses #180.

I have intentionally allowed for any combination of these
keywords to be present or absent.  While having a "then" or "else"
without "if" is pointless and/or nonsensical, so are many other
possible JSON Schema keywords.

Author: handrews

hyper-schema.json

@@ -90,6 +90,9 @@
         "properties": {
             "additionalProperties": { "$ref": "#" }
         },
+        "if": {"$ref": "#"},
+        "then": {"$ref": "#"},
+        "else": {"$ref": "#"},
         "allOf": { "$ref": "#/definitions/schemaArray" },
         "anyOf": { "$ref": "#/definitions/schemaArray" },
         "oneOf": { "$ref": "#/definitions/schemaArray" },

jsonschema-hyperschema.xml

@@ -214,9 +214,9 @@
                 <t>
                     Hyper-schemas MUST NOT be applied to an instance if the instance fails to
                     validate against the validation keywords within or containing the hyper-schema.
-                    Hyper-schema keywords in branches of an "anyOf" or "oneOf" that do not validate,
-                    or in a "dependencies" subschema that is not relevant to the instance, MUST be
-                    ignored.
+                    Hyper-schema keywords in branches of an "anyOf", "oneOf", or "if"/"then"/"else"
+                    that do not validate, or in a "dependencies" subschema that is not relevant
+                    to the instance, MUST be ignored.
                 </t>
                 <t>
                     Hyper-schema keywords in a subschema contained within a "not", at any depth,

jsonschema-validation.xml

@@ -635,6 +635,78 @@
                 </section>
             </section>
 
+            <section title="Applying subschemas conditionally">
+                <t>
+                    These keywords work together to implement conditional
+                    application of a subschema based on the outcome of
+                    another subschema.
+                </t>
+                <t>
+                    These keywords MUST NOT interact with each other across
+                    subschema boundaries.  In other words, an "if" in one
+                    branch of an "allOf" MUST NOT have an impact on a "then"
+                    or "else" in another branch.
+                </t>
+                <section title="if">
+                    <t>
+                        This keyword's value MUST be a valid JSON Schema.
+                    </t>
+                    <t>
+                        Instances that successfully validate against this
+                        keyword's subschema MUST also be valid against
+                        the subschema value of the "then" keyword, if
+                        present.
+                    </t>
+                    <t>
+                        Instances that fail to validate against this
+                        keyword's subschema MUST also be valid against
+                        the subschema value of the "else" keyword.
+                    </t>
+                    <t>
+                        Validation of the instance against this keyword
+                        on its own always succeeds, regardless of the
+                        validation outcome of against its subschema.
+                    </t>
+                </section>
+                <section title="then">
+                    <t>
+                        This keyword's value MUST be a valid JSON Schema.
+                    </t>
+                    <t>
+                        When present alongside of "if", the instance
+                        successfully validates against this keyword if
+                        it validates against both the "if"'s subschema
+                        and this keyword's subschema.
+                    </t>
+                    <t>
+                        When "if" is absent, or the instance fails to
+                        validate against its subschema, validation against
+                        this keyword always succeeds.  Implementations
+                        SHOULD avoid attempting to validate against
+                        the subschema in these cases.
+                    </t>
+                </section>
+                <section title="else">
+                    <t>
+                        This keyword's value MUST be a valid JSON Schema.
+                    </t>
+                    <t>
+                        When present alongside of "if", the instance
+                        successfully validates against this keyword if
+                        it fails to validate against the "if"'s
+                        subschema, and successfully validates against
+                        this keyword's subschema.
+                    </t>
+                    <t>
+                        When "if" is absent, or the instance successfully
+                        validates against its subschema, validation against
+                        this keyword always succeeds.  Implementations
+                        SHOULD avoid attempting to validate against
+                        the subschema in these cases.
+                    </t>
+                </section>
+            </section>
+
             <section title="Keywords for applying subschemas with boolean logic">
                 <section title="allOf">
                     <t>

schema.json

@@ -141,6 +141,9 @@
             ]
         },
         "format": { "type": "string" },
+        "if": {"$ref": "#"},
+        "then": {"$ref": "#"},
+        "else": {"$ref": "#"},
         "allOf": { "$ref": "#/definitions/schemaArray" },
         "anyOf": { "$ref": "#/definitions/schemaArray" },
         "oneOf": { "$ref": "#/definitions/schemaArray" },