@@ -45,46 +45,45 @@ The terms "JSON", "JSON text", "JSON value", "member", "element", "object",
45
45
"array", "number", "string", "boolean", "true", "false", and "null" in this
46
46
document are to be interpreted as defined in [ RFC 8259] ( #rfc8259 ) .
47
47
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.
88
87
89
88
## Definitions
90
89
0 commit comments