writeOnly => writeable, readOnly => readable

[nuxodin]

With "writeOnly" and "readOnly" we have two keywords that are mutually exclusive. Also you can't define a value as writeable AND readable.

Would "readable" and "writeable" which are assumed to be true if they are missing be more logical?

[gregsdennis]

The defaults for readOnly and writeOnly are both false, so by default, they are already readable and writable.

Also, false is the default value for booleans in many languages so we prefer that.

[nuxodin]

I am aware of that. But how can I define a value as neither readable nor writable?

{
  "readOnly": true
  "writeOnly":true
}

This does not seem logical to me. If the default should be false, one could use notReadable / notWriteable.

[Relequestual]

I am aware of that. But how can I define a value as neither readable nor writable?

Data might be neither writable or readable based on a set of given permissions. I agree though, it makes little sense, but then there are many many footguns, such as infinite while loops or regular expression logic bombs.

[nuxodin]

My main concern is that I want to define data as neither writable nor readable.
The fact that the foot gun disappears is a nice side effect, isn't it?

What we have:

	is readable	is writeable
both=false (default)	✅	✅
readOnly=true	✅	❌
writeOnly=true	❌	✅
both=true	✅?	✅?

what we could have:

	is readable	is writeable
readable/writeable=true (default)	✅	✅
writeable=false	✅	❌
readable=false	❌	✅
both=false	❌	❌

[Julian]

Since no one said it earlier -- I think you definitely should consider creating a vocabulary and/or keyword which works the way you propose and then publishing it (and if it indeed is more widely useful others are likely to implement it or support increasing its visibility).

I'm personally -1 on practically all keyword changes to the official dialect (though of course I'm just one vote), even though I agree with you that retrospectively it would have been better to define keywords which relate to permissions rather than exclusive permissions.

[nuxodin]

Since json-schema is versioned, such a change would not be disastrous. But I agree that it is tedious to adapt libraries and schemas.

It would be a change that can be made with regard to backward compatibility by marking the old keywords as deprecated and continuing to implement them.

I would change it, but that's up to the standard people.

[Julian]

Since json-schema is versioned, such a change would not be disastrous.

For some value of "disastrous", I disagree, which is why I mentioned the above as a way you might want to proceed if you didn't want to just convince others this change is so important it should be made (-- to be clear, I am not a spec author but I have some form of vote inasmuch as we have an official process there. Just one vote though!)

[nuxodin]

At the moment, this is not of great importance to me. I just wanted to point out that at some point, somewhere, there will be a use case for marking data as neither writable nor readable. That's one of the great advantages of open standards, being able to point out such things as early as possible.

Unfortunately, I do not have the resources or the know-how to define such a vocabulary. :(

However, if the majority feels that the circumstances of a change do not justify the correction, I understand and respect that decision. 👍

[awwright]

This isn't a bad idea, though I'm not sure it's worth the change, first because the current system isn't actually wrong, and two, normally with "flag" keywords like this, the default (all properties are readable and writable) is unflagged, and we flag the exceptions to this default with a value of true (i.e. read-only or write-only... and any value that's neither readable nor writable is simply excluded altogether).

I feel like this also needs to be explored a bit more, because essentially these properties are creating two subsets of the schema, one used for reading and one used for writing... and is that really what we want? It seems like the keywords intend to have the same document be valid or invalid depending on the direction (request or response).

Finally, another way to think about this would be as a key-value map that can accept other properties. For example, what about properties that can only be defined at create-time, or that can only be changed after they've been created... you may want a schema like

{ "flow": { "readable": true, "writable": "true", "create": false } }

I haven't seen anyone clamoring for create-only properties in JSON Schema yet, but I know this exists in APIs in the wild.

[gregsdennis]

I haven't seen anyone clamoring for create-only properties in JSON Schema yet, but I know this exists in APIs in the wild.

C# 9 should be introducing init-only properties that can only be set on object creation. Ordinarily such properties would be passed as constructor arguments, but init-only properties allow the user to optionally set them rather than them being required without the class dev having to create a bunch of constructor overloads.