Should "readOnly" (and "writeOnly") be an array like "required"?

[handrews]

In the discussions for "deprecated", @awwright brought up that rather than make it a boolean in subschemas, it probably makes more sense to follow the pattern of "required" and make it an array or object alongside of "properties". Similar to #117 ("patternRequired") we would need an analogous "patternReadOnly" (and "additionalReadOnly"?)

Despite the likely need to add separate pattern/additional support, it feels like we should have a consistent design pattern of either specifying these things at the object level, or at the subschema level. Having worked with object level "required" for several years, I feel that it is the better approach.

[handrews]

I just thought of a pretty compelling reason to move "readOnly" to an array keyword at the object levell:

Validation schemas fundamentally describe a type, in the form of an acceptable set of values. "readOnly" not only does not impact that, but is highly context-dependent. It is likely to vary for the same type depending on where and how it is used.

This is part of why "readOnly" is given as a justification for "$use". With "allOf", it's not clear how to turn read-only-ness off. If any branch is of an "allOf" is read-only, then the result would have to be read-only.

Making "readOnly" an array removes that problem, and removes the most substantial justification (for me) when it comes to "$use". Letting applications decide how to handle conflicting titles, descriptions, and even defaults is at least plausible. But there was no other way I could think of to handle "readOnly" and re-use. Except now this.

[handrews]

@geemus this would affect PRMD if you were to move it to (or add support for) draft-07.

[jdesrosiers]

This exact thing occurred to me recently as well while writing hyper-schemas. I think making readOnly a single array like required would be nice.

However, there is one use case I would loose. I sometimes use readOnly at the top level of a hyper-schema to indicate to a client that the entire resource is managed by the server. The client would know that it shouldn't expect any requests that modifies the resource to be successful. I'm willing to lose this use case in order to make the more general case easier to work with.

[handrews]

@jdesrosiers

I sometimes use readOnly at the top level of a hyper-schema to indicate to a client that the entire resource is managed by the server.

This use case occurred to me, but I think in most cases it is better handled at the link level (including "self" links) with "targetHints" #383. For HTTP, that would be {"targetHints": {"allow": ["GET"]}} or similar.

Recommending a hyper-schema approach while we're moving readOnly to annotation/validation is a bit odd, so there is a gap still left that a readOnly array would not cover either.

I've also considered the unusual but possible case of making some but not all array elements read-only. This would mostly be fore the tuple form of items. Should the readOnly array allow integers when applied to an array instance? Obviously, to make the entire array read-only, one would apply readOnly to its parent property.

I still like this idea, but there are definitely some odd corner cases to smooth out.

[geemus]

@handrews sounds reasonable, thanks for the heads up.

[handrews]

See also PR #424 which delves more into the nature of annotation keywords. It might help us decide which way to go on this (although I'm still waffling back and forth myself for readOnly).