diff --git a/jsonschema-core.xml b/jsonschema-core.xml index cc379a5d..789700a0 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -19,7 +19,7 @@ - + JSON Schema: A Media Type for Describing JSON Documents @@ -185,12 +185,12 @@ depending on the type: - A JSON "null" production - A "true" or "false" value, from the JSON "true" or "false" productions - An unordered set of properties mapping a string to an instance, from the JSON "object" production - An ordered list of instances, from the JSON "array" production - An arbitrary-precision, base-10 decimal number value, from the JSON "number" production - A string of Unicode code points, from the JSON "string" production + A JSON "null" production + A "true" or "false" value, from the JSON "true" or "false" productions + An unordered set of properties mapping a string to an instance, from the JSON "object" production + An ordered list of instances, from the JSON "array" production + An arbitrary-precision, base-10 decimal number value, from the JSON "number" production + A string of Unicode code points, from the JSON "string" production @@ -284,10 +284,10 @@ or schema keywords. Broadly speaking, keywords fall into one or both of two categories: - + produce a boolean result when applied to an instance - + attach information to an instance for application use @@ -303,10 +303,10 @@ in terms of the validation vocabulary, boolean schemas are equivalent to the following behaviors: - + Always passes validation, as if the empty schema {} - + Always fails validation, as if the schema { "not":{} } @@ -1045,7 +1045,7 @@ User-Agent: product-name/5.4.1 so-cool-json-schema/1.0.2 curl/7.43.0 Required parameters: - + A non-empty list of space-separated URIs, each identifying a JSON Schema resource. The instance SHOULD successfully validate against at least one of these schemas. @@ -1110,7 +1110,7 @@ User-Agent: product-name/5.4.1 so-cool-json-schema/1.0.2 curl/7.43.0 - + @@ -1123,7 +1123,7 @@ User-Agent: product-name/5.4.1 so-cool-json-schema/1.0.2 curl/7.43.0 - + @@ -1157,6 +1157,17 @@ User-Agent: product-name/5.4.1 so-cool-json-schema/1.0.2 curl/7.43.0 + + + This draft is purely a clarification with no functional changes + Clarified $id by use cases + Exhaustive schema identification examples + Replaced "external referencing" with how and when an implementation might know of a schema from another doucment + Replaced "internal referencing" with how an implementation should recognized schema identifiers during parsing + Dereferencing the former "internal" or "external" references is always the same process + Minor formatting improvements + + Make the concept of a schema keyword vocabulary more clear diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 46d4b24c..91287b06 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -26,7 +26,7 @@ - + JSON Schema Validation: A Vocabulary for Structural Validation of JSON @@ -686,14 +686,14 @@ <section title="dependencies"> <t> <cref> - Now that "if", "then", and "else" are keywords, it is not clear whether - there is any benefit in keeping the schema form of "dependencies". - It is frequently misunderstood, and having a form that takes a subschema - as well as a form that takes a primitive value is particularly - confusing. And it seems to be rarely used. Depending on feedback - with "if", "then", and "else", the schema form of this keyword may - well be removed in a future draft. Current thought is that the string - form (giving property names in an array) is a useful shortcut. + This keyword may be split into two, with the variation that uses + an array of property names rather than a subschema getting a new + name. The dual behavior is confusing and relatively difficult to + implement. In the previous draft, we proposed dropping the keyword + altogether, or dropping one of its forms, but we received feedback + in support of keeping it. See issues #442 and #528 at + <https://github.com/json-schema-org/json-schema-spec/issues> + for further discussion. Further feedback is encouraged. </cref> </t> <t> @@ -912,15 +912,15 @@ Implementations supporting formats SHOULD implement support for the following attributes: <list style="hanging"> - <t hangText="date-time"> + <t hangText="date-time:"> A string instance is valid against this attribute if it is a valid representation according to the "date-time" production. </t> - <t hangText="date"> + <t hangText="date:"> A string instance is valid against this attribute if it is a valid representation according to the "full-date" production. </t> - <t hangText="time"> + <t hangText="time:"> A string instance is valid against this attribute if it is a valid representation according to the "full-time" production. </t> @@ -953,10 +953,10 @@ A string instance is valid against these attributes if it is a valid Internet email address as follows: <list style="hanging"> - <t hangText="email"> + <t hangText="email:"> As defined by <xref target="RFC5322">RFC 5322, section 3.4.1</xref>. </t> - <t hangText="idn-email"> + <t hangText="idn-email:"> As defined by <xref target="RFC6531">RFC 6531</xref> </t> </list> @@ -972,12 +972,12 @@ A string instance is valid against these attributes if it is a valid representation for an Internet hostname as follows: <list style="hanging"> - <t hangText="hostname"> + <t hangText="hostname:"> As defined by <xref target="RFC1034">RFC 1034, section 3.1</xref>, including host names produced using the Punycode algorithm specified in <xref target="RFC5891">RFC 5891, section 4.4</xref>. </t> - <t hangText="idn-hostname"> + <t hangText="idn-hostname:"> As defined by either RFC 1034 as for hostname, or an internationalized hostname as defined by <xref target="RFC5890">RFC 5890, section 2.3.2.3</xref>. @@ -996,12 +996,12 @@ A string instance is valid against these attributes if it is a valid representation of an IP address as follows: <list style="hanging"> - <t hangText="ipv4"> + <t hangText="ipv4:"> An IPv4 address according to the "dotted-quad" ABNF syntax as defined in <xref target="RFC2673">RFC 2673, section 3.2</xref>. </t> - <t hangText="ipv6"> + <t hangText="ipv6:"> An IPv6 address as defined in <xref target="RFC4291">RFC 4291, section 2.2</xref>. </t> @@ -1015,20 +1015,20 @@ </t> <t> <list style="hanging"> - <t hangText="uri"> + <t hangText="uri:"> A string instance is valid against this attribute if it is a valid URI, according to <xref target="RFC3986"/>. </t> - <t hangText="uri-reference"> + <t hangText="uri-reference:"> A string instance is valid against this attribute if it is a valid URI Reference (either a URI or a relative-reference), according to <xref target="RFC3986"/>. </t> - <t hangText="iri"> + <t hangText="iri:"> A string instance is valid against this attribute if it is a valid IRI, according to <xref target="RFC3987"/>. </t> - <t hangText="iri-reference"> + <t hangText="iri-reference:"> A string instance is valid against this attribute if it is a valid IRI Reference (either an IRI or a relative-reference), according to <xref target="RFC3987"/>. @@ -1059,12 +1059,12 @@ </t> <t> <list style="hanging"> - <t hangText="json-pointer"> + <t hangText="json-pointer:"> A string instance is valid against this attribute if it is a valid JSON string representation of a JSON Pointer, according to <xref target="RFC6901">RFC 6901, section 5</xref>. </t> - <t hangText="relative-json-pointer"> + <t hangText="relative-json-pointer:"> A string instance is valid against this attribute if it is a valid <xref target="relative-json-pointer">Relative JSON Pointer</xref>. </t> @@ -1247,8 +1247,8 @@ <t> Schema validation is a useful mechanism for annotating instance data with additional information. The rules for determining when and how - annotations are associated with an instance are outlined in this specification's - overview. + annotations are associated with an instance are outlined in section + <xref target="annotations" format="counter"></xref>. </t> <t> These general-purpose annotation keywords provide commonly used information @@ -1425,7 +1425,7 @@ </author> <date year="2017" month="November"/> </front> - <seriesInfo name="Internet-Draft" value="draft-handrews-relative-json-pointer-00" /> + <seriesInfo name="Internet-Draft" value="draft-handrews-relative-json-pointer-01" /> </reference> <reference anchor="json-schema"> <front> @@ -1438,7 +1438,7 @@ </author> <date year="2017" month="November"/> </front> - <seriesInfo name="Internet-Draft" value="draft-handrews-json-schema-00" /> + <seriesInfo name="Internet-Draft" value="draft-handrews-json-schema-01" /> </reference> </references> @@ -1477,6 +1477,14 @@ </t> <t> <list style="hanging"> + <t hangText="draft-handrews-json-schema-validation-01"> + <list style="symbols"> + <t>This draft is purely a clarification with no functional changes</t> + <t>Restored ommitted "if present" clause for "else" under "if"</t> + <t>Clarified that when "if" is absent, the results of "then" and "else" are ignored</t> + <t>Minor formatting and cross-referencing improvements</t> + </list> + </t> <t hangText="draft-handrews-json-schema-validation-00"> <list style="symbols"> <t>Added "if"/"then"/"else"</t> @@ -1497,7 +1505,7 @@ </t> <t hangText="draft-wright-json-schema-validation-01"> <list style="symbols"> - <t>Standardized on hyphenated format names ("uriref" becomes "uri-ref")</t> + <t>Standardized on hyphenated format names with full words ("uriref" becomes "uri-reference")</t> <t>Add the formats "uri-template" and "json-pointer"</t> <t>Changed "exclusiveMaximum"/"exclusiveMinimum" from boolean modifiers of "maximum"/"minimum" to independent numeric fields.</t> <t>Split the additionalItems/items into two sections</t>