Skip to content

Commit 2e25d2e

Browse files
committed
Add/update some info on why format works the way it does.
Closes: #653
1 parent 2ab84f8 commit 2e25d2e

File tree

2 files changed

+68
-0
lines changed

2 files changed

+68
-0
lines changed

docs/faq.rst

Lines changed: 66 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -3,6 +3,72 @@ Frequently Asked Questions
33
==========================
44

55

6+
My schema specifies format validation. Why do invalid instances seem valid?
7+
---------------------------------------------------------------------------
8+
9+
The :validator:`format` validator can be a bit of a stumbling block for new
10+
users working with JSON Schema.
11+
12+
In a schema such as:
13+
14+
.. code-block:: json
15+
16+
{"type": "string", "format": "date"}
17+
18+
JSON Schema specifications have historically differentiated between the
19+
:validator:`format` validator and other validators. In particular, the
20+
:validator:`format` validator was specified to be *informational* as much
21+
as it may be used for validation.
22+
23+
In other words, for many use cases, schema authors may wish to use
24+
values for the :validator:`format` validator but have no expectation
25+
they be validated alongside other required assertions in a schema.
26+
27+
Of course this does not represent all or even most use cases -- many
28+
schema authors *do* wish to assert that instances conform fully, even to
29+
the specific format mentioned.
30+
31+
In drafts prior to ``draft2019-09``, the decision on whether to
32+
automatically enable :validator:`format` validation was left up to
33+
validation implementations such as this one.
34+
35+
This library made the choice to leave it off by default, for two reasons:
36+
37+
* for forward compatibility and implementation complexity reasons
38+
-- if :validator:`format` validation were on by default, and a
39+
future draft of JSON Schema introduced a hard-to-implement format,
40+
either the implementation of that format would block releases of
41+
this library until it were implemented, or the behavior surrounding
42+
:validator:`format` would need to be even more complex than simply
43+
defaulting to be on. It therefore was safer to start with it off,
44+
and defend against the expectation that a given format would always
45+
automatically work.
46+
47+
* given that a common use of JSON Schema is for portability across
48+
languages (and therefore implementations of JSON Schema), so that
49+
users be aware of this point itself regarding :validator:`format`
50+
validation, and therefore remember to check any *other*
51+
implementations they were using to ensure they too were explicitly
52+
enabled for :validator:`format` validation.
53+
54+
As of ``draft2019-09`` however, the opt-out by default behavior
55+
mentioned here is now *required* for all validators.
56+
57+
Difficult as this may sound for new users, at this point it at least
58+
means they should expect the same behavior that has always been
59+
implemented here, across any other implementation they encounter.
60+
61+
.. seealso::
62+
63+
`validating formats`
64+
65+
for details on how to enable format validation
66+
67+
`FormatChecker`
68+
69+
the object which implements format validation
70+
71+
672
Why doesn't my schema's default property set the default on my instance?
773
------------------------------------------------------------------------
874

docs/validate.rst

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -264,6 +264,8 @@ Draft 6 meta-schema, you could use:
264264
Draft6Validator.check_schema(schema)
265265
266266
267+
.. _validating formats:
268+
267269
Validating Formats
268270
------------------
269271

0 commit comments

Comments
 (0)