Skip to content

Commit e49781f

Browse files
DavidBiesackjdesrosiers
authored andcommitted
Fixes #1402: clarify readOnly (applies to any value, not just properties). Format true and false code values
1 parent 25d0109 commit e49781f

File tree

1 file changed

+23
-23
lines changed

1 file changed

+23
-23
lines changed

jsonschema-validation.md

+23-23
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
# JSON Schema Validation: A Vocabulary for Structural Validation of JSON
1+
e# JSON Schema Validation: A Vocabulary for Structural Validation of JSON
22

33
## Abstract
44

@@ -105,7 +105,7 @@ Validation keywords in a schema impose requirements for successful validation of
105105
an instance. These keywords are all assertions without any annotation behavior.
106106

107107
Meta-schemas that do not use `$vocabulary` SHOULD be considered to require this
108-
vocabulary as if its IRI were present with a value of true.
108+
vocabulary as if its IRI were present with a value of `true`.
109109

110110
The current IRI for this vocabulary, known as the Validation vocabulary, is:
111111
`https://json-schema.org/draft/next/vocab/validation`.
@@ -245,11 +245,11 @@ Omitting this keyword has the same behavior as a value of 0.
245245

246246
The value of this keyword MUST be a boolean.
247247

248-
If this keyword has boolean value false, the instance validates successfully. If
249-
it has boolean value true, the instance validates successfully if all of its
248+
If this keyword has boolean value `false`, the instance validates successfully. If
249+
it has boolean value `true`, the instance validates successfully if all of its
250250
elements are unique.
251251

252-
Omitting this keyword has the same behavior as a value of false.
252+
Omitting this keyword has the same behavior as a value of `false`.
253253

254254
### Validation Keywords for Objects
255255

@@ -364,7 +364,7 @@ When the implementation is configured for assertion behavior, it:
364364
- SHOULD provide an implementation-specific best effort validation for each
365365
format attribute defined below;
366366
- MAY choose to implement validation of any or all format attributes as a no-op
367-
by always producing a validation result of true;[^3]
367+
by always producing a validation result of `true`;[^3]
368368

369369
[^3]: This matches the current reality of implementations, which provide widely
370370
varying levels of validation, including no validation at all, for some or all
@@ -374,7 +374,7 @@ is the recommended best practice.
374374

375375
#### Format-Assertion Vocabulary
376376

377-
When the Format-Assertion vocabulary is declared with a value of true,
377+
When the Format-Assertion vocabulary is declared with a value of `true`,
378378
implementations MUST provide full validation support for all of the formats
379379
defined by this specification. Implementations that cannot provide full
380380
validation support MUST refuse to process the schema.
@@ -410,9 +410,9 @@ format, or a well-known regular expression. Implementations SHOULD clearly
410410
document how and to what degree each format attribute is validated.
411411

412412
The [standard core and validation meta-schema](#meta-schema) includes this
413-
vocabulary in its `$vocabulary` keyword with a value of false, since by default
413+
vocabulary in its `$vocabulary` keyword with a value of `false`, since by default
414414
implementations are not required to support this keyword as an assertion.
415-
Supporting the format vocabulary with a value of true is understood to greatly
415+
Supporting the format vocabulary with a value of `true` is understood to greatly
416416
increase code size and in some cases execution time, and will not be appropriate
417417
for all implementations.
418418

@@ -574,7 +574,7 @@ assertions; a malformed string-encoded document MUST NOT cause the containing
574574
instance to be considered invalid.
575575

576576
Meta-schemas that do not use `$vocabulary` SHOULD be considered to require this
577-
vocabulary as if its IRI were present with a value of true.
577+
vocabulary as if its IRI were present with a value of `true`.
578578

579579
The current IRI for this vocabulary, known as the Content vocabulary, is:
580580
`https://json-schema.org/draft/next/vocab/content`.
@@ -717,7 +717,7 @@ Rather, additional vocabularies can be defined for more complex annotation-based
717717
applications.
718718

719719
Meta-schemas that do not use `$vocabulary` SHOULD be considered to require this
720-
vocabulary as if its IRI were present with a value of true.
720+
vocabulary as if its IRI were present with a value of `true`.
721721

722722
The current IRI for this vocabulary, known as the Meta-Data vocabulary, is:
723723
`https://json-schema.org/draft/next/vocab/meta-data`.
@@ -748,39 +748,39 @@ associated schema.
748748

749749
The value of this keyword MUST be a boolean. When multiple occurrences of this
750750
keyword are applicable to a single sub-instance, applications SHOULD consider
751-
the instance location to be deprecated if any occurrence specifies a true value.
751+
the instance location to be deprecated if any occurrence specifies a `true` value.
752752

753-
If `deprecated` has a value of boolean true, it indicates that applications
753+
If `deprecated` has a value of boolean `true`, it indicates that applications
754754
SHOULD refrain from usage of the declared property. It MAY mean the property is
755755
going to be removed in the future.
756756

757-
A root schema containing `deprecated` with a value of true indicates that the
757+
A root schema containing `deprecated` with a value of `true` indicates that the
758758
entire resource being described MAY be removed in the future.
759759

760760
The `deprecated` keyword applies to each instance location to which the schema
761761
object containing the keyword successfully applies. This can result in scenarios
762762
where every array item or object property is deprecated even though the
763763
containing array or object is not.
764764

765-
Omitting this keyword has the same behavior as a value of false.
765+
Omitting this keyword has the same behavior as a value of `false`.
766766

767767
### `readOnly` and `writeOnly`
768768

769769
The value of these keywords MUST be a boolean. When multiple occurrences of
770770
these keywords are applicable to a single sub-instance, the resulting behavior
771-
SHOULD be as for a true value if any occurrence specifies a true value, and
772-
SHOULD be as for a false value otherwise.
771+
SHOULD be as for a `true` value if any occurrence specifies a `true` value, and
772+
SHOULD be as for a `false` value otherwise.
773773

774-
If `readOnly` has a value of boolean true, it indicates that the value of the
774+
If `readOnly` has a value of boolean `true`, it indicates that the value of the
775775
instance is managed exclusively by the owning authority, and attempts by an
776-
application to modify the value of this property are expected to be ignored or
776+
application to modify the value of an instance are expected to be ignored or
777777
rejected by that owning authority.
778778

779779
An instance document that is marked as `readOnly` for the entire document MAY be
780780
ignored if sent to the owning authority, or MAY result in an error, at the
781781
authority's discretion.
782782

783-
If `writeOnly` has a value of boolean true, it indicates that the value is never
783+
If `writeOnly` has a value of boolean `true`, it indicates that the value is never
784784
present when the instance is retrieved from the owning authority. It can be
785785
present when sent to the owning authority to update or create the document (or
786786
the resource it represents), but it will not be included in any updated or newly
@@ -797,7 +797,7 @@ These keywords can be used to assist in user interface instance generation. In
797797
particular, an application MAY choose to use a widget that hides input values as
798798
they are typed for write-only fields.
799799

800-
Omitting these keywords has the same behavior as values of false.
800+
Omitting these keywords has the same behavior as values of `false`.
801801

802802
### `examples`
803803

@@ -988,8 +988,8 @@ keywords:
988988
`patternProperties`, `additionalProperties`* All of these keywords apply
989989
subschemas to the instance and combine their results, without asserting any
990990
conditions of their own. Without assertion keywords, these applicators can
991-
only cause assertion failures by using the false boolean schema, or by
992-
inverting the result of the true boolean schema (or equivalent schema
991+
only cause assertion failures by using the `false` boolean schema, or by
992+
inverting the result of the `true` boolean schema (or equivalent schema
993993
objects). For this reason, they are better defined as a generic mechanism on
994994
which validation, hyper-schema, and extension vocabularies can all be based.
995995
- *`maxContains`, `minContains`* These keywords modify the behavior of

0 commit comments

Comments
 (0)