Skip to content

Commit ba821f5

Browse files
committed
resubmission of @awwright's #1370 overview change
1 parent 258d721 commit ba821f5

File tree

1 file changed

+39
-40
lines changed

1 file changed

+39
-40
lines changed

specs/jsonschema-core.md

+39-40
Original file line numberDiff line numberDiff line change
@@ -45,46 +45,45 @@ The terms "JSON", "JSON text", "JSON value", "member", "element", "object",
4545
"array", "number", "string", "boolean", "true", "false", and "null" in this
4646
document are to be interpreted as defined in [RFC 8259](#rfc8259).
4747

48-
## Overview
49-
50-
This document proposes a new media type `application/schema+json` to identify a
51-
JSON Schema for describing JSON data. It also proposes a further optional media
52-
type, `application/schema-instance+json`, to provide additional integration
53-
features. JSON Schemas are themselves JSON documents. This, and related
54-
specifications, define keywords allowing authors to describe JSON data in
55-
several ways.
56-
57-
JSON Schema uses keywords to assert constraints on JSON instances or annotate
58-
those instances with additional information. Additional keywords are used to
59-
apply assertions and annotations to more complex JSON data structures, or based
60-
on some sort of condition.
61-
62-
To facilitate re-use, keywords can be organized into vocabularies. A vocabulary
63-
consists of a list of keywords, together with their syntax and semantics. A
64-
dialect is defined as a set of vocabularies and their required support
65-
identified in a meta-schema.
66-
67-
JSON Schema can be extended either by defining additional vocabularies, or less
68-
formally by defining additional keywords outside of any vocabulary. Unrecognized
69-
individual keywords are not supported.
70-
71-
This document defines a set of core keywords that MUST be supported by any
72-
implementation, and cannot be disabled. These keywords are each prefixed with a
73-
"$" character to emphasize their required nature. These keywords are essential
74-
to the functioning of the `application/schema+json` media type.
75-
76-
Additionally, this document defines a RECOMMENDED set of keywords for
77-
applying subschemas conditionally, and for applying subschemas to the contents
78-
of objects and arrays. These keywords, or a set very much like them, are
79-
required to write schemas for non-trivial JSON instances, whether those schemas
80-
are intended for assertion validation, annotation, or both. While not part of
81-
the required core set, for maximum interoperability this additional
82-
set is included in this document and its use is strongly encouraged.
83-
84-
Further keywords for purposes such as structural validation or hypermedia
85-
annotation are defined in other documents. These other documents each define a
86-
dialect collecting the standard sets of keywords needed to write schemas for
87-
that document's purpose.
48+
## Validation
49+
50+
A JSON Schema document describes a validator (also known as a "recognizer" or
51+
"acceptor") which classifies a provided JSON document as "accepted" or
52+
"rejected."
53+
54+
It supports "structural validation" (context-free grammars), and certain more
55+
complicated conditions. Validation follows JSON semantics, so two documents that
56+
are value-equal, but vary only by character escapes, property ordering, or
57+
whitespace, will validate with the same result.
58+
59+
A condition for accepting a document is called an "assertion". Assertions impose
60+
constraints that instances must conform to. Given a schema and an instance, the
61+
schema "accepts" an input whenever all the assertions are met, and the schema
62+
"rejects" when any of the assertions fail. Schemas without any assertions accept
63+
all JSON documents.
64+
65+
Assertions are encoded into a JSON Schema using "keywords," described below.
66+
67+
## Annotations
68+
69+
A schema may also describe an "annotator," a way to read an instance and output
70+
a set of "annotations." Annotations can be any output metadata about that
71+
instance.
72+
73+
For example, you can document the meaning of a property, suggest a default value
74+
for new instances, generate a list of hyperlinks from the instance, or declare
75+
relationships between data. Applications may make use of annotations to query
76+
for arbitrary information; for example, to extract a list of names from a
77+
document with a known structure. Annotations may also describe values within the
78+
instance in a standard way; for example, extracting a common type of hyperlink
79+
from many different types of documents, using a different
80+
81+
Like assertions, the instructions for producing annotations are encoded in a
82+
schema using keywords. Output is only defined over valid instances, so
83+
annotations are not returned until the input has been validated. However, not
84+
all valid input is meaningful or true to a given application. That is, if you
85+
process an arbitrary instance with nonsense data, the resulting annotations may
86+
not necessarily be true, even though the input is valid.
8887

8988
## Definitions
9089

0 commit comments

Comments
 (0)