-
-
Notifications
You must be signed in to change notification settings - Fork 317
Main updates for Draft 7 #84
Changes from 14 commits
1fa7006
5fc2a94
71e9fcd
e169b1d
1d52aa7
d9e95f2
bb7eaae
715fb5a
29ec90f
fdaeb17
4c68a86
10a54b8
92074e2
40ae42b
d386e5c
e14a693
8606772
043dc0b
f7c1090
34693e2
cb69070
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,161 @@ | ||
.. index:: | ||
single: conditionals | ||
single: conditionals; if | ||
single: conditionals; then | ||
single: conditionals; else | ||
single: if | ||
single: then | ||
single: else | ||
|
||
.. _conditionals: | ||
|
||
Applying subschemas conditionally | ||
================================= | ||
|
||
|draft7| ``if``, ``then`` and ``else`` keywords | ||
|
||
The ``if``, ``then`` and ``else`` keywords allow the application of a subschema | ||
based on the outcome of another schema, much like the ``if/then/else`` | ||
constructs you've probably seen in traditional programming languages. | ||
|
||
If ``if`` is valid, ``then`` must also be valid (and ``else`` is ignored.) If | ||
``if`` is invalid, ``else`` must also be valid (and ``then`` is ignored). | ||
|
||
We can put this in the form of a truth table, showing the combinations of when | ||
``if``, ``then``, and ``else`` are valid and the resulting validity of the | ||
entire schema: | ||
|
||
==== ==== ==== ============ | ||
if then else whole schema | ||
==== ==== ==== ============ | ||
✗ ✗ ✗ ✗ | ||
✗ ✗ ✓ ✓ | ||
✗ ✓ ✗ ✗ | ||
✗ ✓ ✓ ✓ | ||
✓ ✗ ✗ ✗ | ||
✓ ✗ ✓ ✗ | ||
✓ ✓ ✗ ✓ | ||
✓ ✓ ✓ ✓ | ||
==== ==== ==== ============ | ||
|
||
For example, let's say you wanted to write a schema to handle addresses in the | ||
United States and Canada. These countries have different postal code formats, | ||
and we want to select which format to validate against based on the country. If | ||
the address is in the United States, the ``postal_code`` field is a "zipcode": | ||
five numeric digits followed by an optional four digit suffix. If the address is | ||
in Canada, the ``postal_code`` field is a six digit alphanumeric string where | ||
letters and numbers alternate. | ||
|
||
.. schema_example:: | ||
|
||
{ | ||
"type": "object", | ||
"properties": { | ||
"street_address": { | ||
"type": "string" | ||
}, | ||
"country": { | ||
"enum": ["United States of America", "Canada"] | ||
} | ||
}, | ||
"if": { | ||
"properties": { "country": { "const": "United States of America" } } | ||
}, | ||
"then": { | ||
"properties": { "postal_code": { "pattern": "[0-9]{5}(-[0-9]{4})?" } } | ||
}, | ||
"else": { | ||
"properties": { "postal_code": { "pattern": "[A-Z][0-9][A-Z] [0-9][A-Z][0-9]" } } | ||
} | ||
} | ||
-- | ||
{ | ||
"street_address": "1600 Pennsylvania Avenue NW", | ||
"country": "United States of America", | ||
"postal_code": "20500" | ||
} | ||
-- | ||
{ | ||
"street_address": "24 Sussex Drive", | ||
"country": "Canada", | ||
"postal_code": "K1M 1M4" | ||
} | ||
--X | ||
{ | ||
"street_address": "24 Sussex Drive", | ||
"country": "Canada", | ||
"postal_code": "10000" | ||
} | ||
|
||
Unfortunately, this approach above doesn't scale to more than two countries. You | ||
can, however, wrap pairs of ``if`` and ``then`` inside an ``allOf`` to create | ||
something that would scale. In this example, we'll use United States and | ||
Canadian postal codes, but also add Netherlands postal codes, which are 4 digits | ||
followed by two letters. It's left as an exercise to the reader to expand this | ||
to the remaining postal codes of the world. | ||
|
||
.. schema_example:: | ||
|
||
{ | ||
"type": "object", | ||
"properties": { | ||
"street_address": { | ||
"type": "string" | ||
}, | ||
"country": { | ||
"enum": ["United States of America", "Canada", "Netherlands"] | ||
} | ||
}, | ||
"allOf": [ | ||
{ | ||
"if": { | ||
"properties": { "country": { "const": "United States of America" } } | ||
}, | ||
"then": { | ||
"properties": { "postal_code": { "pattern": "[0-9]{5}(-[0-9]{4})?" } } | ||
} | ||
}, | ||
{ | ||
"if": { | ||
"properties": { "country": { "const": "Canada" } } | ||
}, | ||
"then": { | ||
"properties": { "postal_code": { "pattern": "[A-Z][0-9][A-Z] [0-9][A-Z][0-9]" } } | ||
} | ||
}, | ||
{ | ||
"if": { | ||
"properties": { "country": { "const": "Netherlands" } } | ||
}, | ||
"then": { | ||
"properties": { "postal_code": { "pattern": "[0-9]{4} [A-Z]{2}" } } | ||
} | ||
} | ||
] | ||
} | ||
-- | ||
{ | ||
"street_address": "1600 Pennsylvania Avenue NW", | ||
"country": "United States of America", | ||
"postal_code": "20500" | ||
} | ||
-- | ||
{ | ||
"street_address": "24 Sussex Drive", | ||
"country": "Canada", | ||
"postal_code": "K1M 1M4" | ||
} | ||
-- | ||
{ | ||
"street_address": "Adriaan Goekooplaan", | ||
"country": "Netherlands", | ||
"postal_code": "2517 JX" | ||
} | ||
--X | ||
{ | ||
"street_address": "24 Sussex Drive", | ||
"country": "Canada", | ||
"postal_code": "10000" | ||
} | ||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -5,25 +5,33 @@ This chapter lists some miscellaneous properties that are available | |
for all JSON types. | ||
|
||
.. index:: | ||
single: metadata | ||
single: annotation | ||
single: title | ||
single: description | ||
single: default | ||
single: examples | ||
single: $comment | ||
|
||
.. _metadata: | ||
.. _annotation: | ||
|
||
Metadata | ||
-------- | ||
Annotations | ||
----------- | ||
|
||
JSON Schema includes a few keywords, ``title``, ``description``, ``default``, and | ||
``examples`` that aren't strictly used for validation, but are used to describe | ||
parts of a schema. | ||
JSON Schema includes a few keywords, ``title``, ``description``, ``default``, | ||
``examples``, and ``$comment`` that aren't strictly used for validation, but are | ||
used to describe parts of a schema. | ||
|
||
The ``title`` and ``description`` keywords must be strings. A "title" | ||
will preferably be short, whereas a "description" will provide a more | ||
lengthy explanation about the purpose of the data described by the | ||
schema. Neither are required, but they are encouraged for good | ||
practice, and can make your schema "self-documenting". | ||
|draft7| ``$comment`` | ||
|
||
The ``title``, ``description``, and ``$comment`` keywords must be strings. A | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wouldn't put
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is That makes sense about There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh, yeah, Anyway, ignore |
||
"title" will preferably be short, whereas a "description" will provide a more | ||
lengthy explanation about the purpose of the data described by the schema. | ||
``$comment`` is intended for notes to schema maintainers, while ``title`` and | ||
``description`` are meant for display to end users. This is somewhat analogous | ||
to the distinction between comments and docstrings in source code. | ||
|
||
None of these "annotation" keywords are required, but they are encouraged for | ||
good practice, and can make your schema "self-documenting". | ||
|
||
The ``default`` keyword specifies a default value for an item. JSON | ||
processing tools may use this information to provide a default value | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can never figure out whether
allOf
,anyOf
, oroneOf
makes sense here. For mutually exclusive conditions, the effect is the same for all of them. For overlapping conditions, it makes a difference.I don't think you need to change this, I'm just kind of musing on it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. In any case
allOf
/anyOf
/oneOf
are discussed in detail elsewhere -- this is just intended to show the combination of conditionals with the set notation operators. I think I'll not confuse this here now, but we can always revisit later.