description of readOnly is ambiguous and refers to property when it should be instance

[DavidBiesack]

The 2020-12 validation spec reads

attempts by an application to modify the value of this property
This should be changed to
attempts by an application to modify the value of this instance
since readOnly can apply to an object or array or primitive schema, not just properties on an object.

(I'd also like more clarity here when readOnly: true appears on a container instance - i.e. explicitly state whether this constraint does or does not extend to containers within the container. I believe it is local and only applies to the container)

[Julian]

(I haven't read the description here carefully to see if I agree, but this belongs on the spec repo regardless, so going to move this there).

[gregsdennis]

Since readOnly is merely an annotation, JSON Schema is intentionally non-prescriptive on what its meaning is. That is for the consuming application to decide.

If two applications are sharing a schema that contains readOnly, then they need to agree on its usage.

[jdesrosiers]

@DavidBiesack I agree that this wording is awkward at best. The current wording makes it sound like the keyword is only allowed on schemas that describe properties, which is not true. I'd approve a PR with the proposed change.

(I'd also like more clarity here when readOnly: true appears on a container instance - i.e. explicitly state whether this constraint does or does not extend to containers within the container. I believe it is local and only applies to the container)

I've always thought of it as extending to the entire value. For example, you could put it at the root of your schema to indicate that the entire document is read only.

[DavidBiesack]

PR submitted

[DavidBiesack]

The PR build failed though I don't know what that rule is, what it means, or how to correct it.

[gregsdennis]

We have a two-week minimum open time for spec changes. That GH Action just keeps us from violating it.