-
-
Notifications
You must be signed in to change notification settings - Fork 251
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
description of readOnly is ambiguous and refers to property when it should be instance #1402
Comments
(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). |
Since If two applications are sharing a schema that contains |
@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'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. |
…ot just properties). Format `true` and `false` code values
The PR build failed though I don't know what that rule is, what it means, or how to correct it. |
We have a two-week minimum open time for spec changes. That GH Action just keeps us from violating it. |
The 2020-12 validation spec reads
(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)The text was updated successfully, but these errors were encountered: