Skip to content

Commit 8a76bea

Browse files
committed
Split Overview into Validation, Annotation, and Vocabularies
This better describes the specific uses that JSON Schema supports. The vocabulary-related prose is moved down into the relevant section.
1 parent d29e9c4 commit 8a76bea

File tree

1 file changed

+67
-38
lines changed

1 file changed

+67
-38
lines changed

jsonschema-core.xml

+67-38
Original file line numberDiff line numberDiff line change
@@ -125,57 +125,50 @@
125125
</t>
126126
</section>
127127

128-
<section title="Overview">
128+
<!-- JSON Schema is designed for two broad use cases, which should each get their own section. -->
129+
<section title="Validation">
129130
<t>
130-
This document proposes a new media type "application/schema+json" to identify a JSON
131-
Schema for describing JSON data.
132-
It also proposes a further optional media type, "application/schema-instance+json",
133-
to provide additional integration features.
134-
JSON Schemas are themselves JSON documents.
135-
This, and related specifications, define keywords allowing authors to describe JSON
136-
data in several ways.
131+
A JSON Schema describes a validator (also known as a "recognizer" or "acceptor") that classifies a provided JSON document as "accepted" or "rejected."
132+
It supports "structural validation" (context-free grammars), and certain more complicated conditions.
133+
However validation always follows JSON semantics, so two documents that are value-equal, but vary only by indentation, whitespace, character escapes, and property ordering, will validate with the same result.
137134
</t>
138135
<t>
139-
JSON Schema uses keywords to assert constraints on JSON instances or annotate those
140-
instances with additional information. Additional keywords are used to apply
141-
assertions and annotations to more complex JSON data structures, or based on
142-
some sort of condition.
136+
With respect to a given schema, a document accepted by that schema is called an "instance."
137+
A JSON Schema may be used to specify sets of JSON documents, by referring to the set of all instances of that schema.
143138
</t>
144139
<t>
145-
To facilitate re-use, keywords can be organized into vocabularies. A vocabulary
146-
consists of a list of keywords, together with their syntax and semantics.
147-
A dialect is defined as a set of vocabularies and their required support
148-
identified in a meta-schema.
140+
A condition for accepting a document is called an "assertion".
141+
Assertions add constraints that instances must conform to.
142+
Given a schema and an instance, the schema "accepts" an instance whenever all the assertions are met,
143+
and the schema "rejects" when any of the assertions fail.
144+
In a schema without any assertion keywords, all JSON documents are accepted.
149145
</t>
150146
<t>
151-
JSON Schema can be extended either by defining additional vocabularies,
152-
or less formally by defining additional keywords outside of any vocabulary.
153-
Unrecognized individual keywords simply have their values collected as annotations,
154-
while the behavior with respect to an unrecognized vocabulary can be controlled
155-
when declaring which vocabularies are in use.
147+
Assertions are encoded into a JSON Schema using "keywords," described below.
156148
</t>
149+
</section>
150+
151+
<section title="Annotation">
157152
<t>
158-
This document defines a core vocabulary that MUST be supported by any
159-
implementation, and cannot be disabled. Its keywords are each prefixed
160-
with a "$" character to emphasize their required nature. This vocabulary
161-
is essential to the functioning of the "application/schema+json" media
162-
type, and is used to bootstrap the loading of other vocabularies.
153+
A JSON Schema also describes an "annotator", a way to read an instance and return a set of "annotations."
154+
Annotations can be any metadata describing that instance.
163155
</t>
164156
<t>
165-
Additionally, this document defines a RECOMMENDED vocabulary of keywords
166-
for applying subschemas conditionally, and for applying subschemas to
167-
the contents of objects and arrays. Either this vocabulary or one very
168-
much like it is required to write schemas for non-trivial JSON instances,
169-
whether those schemas are intended for assertion validation, annotation,
170-
or both. While not part of the required core vocabulary, for maximum
171-
interoperability this additional vocabulary is included in this document
172-
and its use is strongly encouraged.
157+
For example, you can document the meaning of a property,
158+
suggest a default value for new instances,
159+
generate a list of hyperlinks from the instance,
160+
or declare relationships between data.
161+
Applications may make use of annotations to query for arbitrary information;
162+
for example, to extract a list of names from a document with a known structure.
163+
Annotations may also describe values within the instance in a standard way;
164+
for example, extracting a common type of hyperlink from many different types of documents, using a different schema for type.
173165
</t>
174166
<t>
175-
Further vocabularies for purposes such as structural validation or
176-
hypermedia annotation are defined in other documents. These other
177-
documents each define a dialect collecting the standard sets of
178-
vocabularies needed to write schemas for that document's purpose.
167+
Like assertions, the rules governing annotations are encoded in a JSON Schema using keywords.
168+
Annotations are only produced from instances (documents accepted by the schema),
169+
and may only be meaningful with instances known by the application to be meaningful.
170+
That is, if you generate an arbitrary instance with nonsense data,
171+
the resulting annotations will not necessarily be true, even though the input is valid.
179172
</t>
180173
</section>
181174

@@ -384,6 +377,42 @@
384377
</t>
385378
</section>
386379
<section title="Schema Vocabularies">
380+
<t>
381+
To facilitate re-use, keywords can be organized into vocabularies. A vocabulary
382+
consists of a list of keywords, together with their syntax and semantics.
383+
A dialect is defined as a set of vocabularies and their required support
384+
identified in a meta-schema.
385+
</t>
386+
<t>
387+
JSON Schema can be extended either by defining additional vocabularies,
388+
or less formally by defining additional keywords outside of any vocabulary.
389+
Unrecognized individual keywords simply have their values collected as annotations,
390+
while the behavior with respect to an unrecognized vocabulary can be controlled
391+
when declaring which vocabularies are in use.
392+
</t>
393+
<t>
394+
This document defines a core vocabulary that MUST be supported by any
395+
implementation, and cannot be disabled. Its keywords are each prefixed
396+
with a "$" character to emphasize their required nature. This vocabulary
397+
is essential to the functioning of the "application/schema+json" media
398+
type, and is used to bootstrap the loading of other vocabularies.
399+
</t>
400+
<t>
401+
Additionally, this document defines a RECOMMENDED vocabulary of keywords
402+
for applying subschemas conditionally, and for applying subschemas to
403+
the contents of objects and arrays. Either this vocabulary or one very
404+
much like it is required to write schemas for non-trivial JSON instances,
405+
whether those schemas are intended for assertion validation, annotation,
406+
or both. While not part of the required core vocabulary, for maximum
407+
interoperability this additional vocabulary is included in this document
408+
and its use is strongly encouraged.
409+
</t>
410+
<t>
411+
Further vocabularies for purposes such as structural validation or
412+
hypermedia annotation are defined in other documents. These other
413+
documents each define a dialect collecting the standard sets of
414+
vocabularies needed to write schemas for that document's purpose.
415+
</t>
387416
<t>
388417
A schema vocabulary, or simply a vocabulary, is a set of keywords,
389418
their syntax, and their semantics. A vocabulary is generally organized

0 commit comments

Comments
 (0)