Undefined behavior for writeOnly and readOnly

[relu91]

Currently, TD specification leverages on JSONSchema when explaining the semantics of writeOnly and readOnly. However, it is not clear what would happen if both writeOnly and readOnly are set to true. Even JSONSchema RFC does not mention this possibility (see here). As @danielpeintner suggested offline we need a statement similar the following (taken from here):

One or more properties in the schema you have defined has both writeOnly and readOnly properties set to true. You can define a property to be either "write only" or "read only", but not both.

@egekorkan also had an idea about how this condition could be verified using JSONSchema.

[egekorkan]

Yes below is the idea I have with JSON Schema. It is a bit too weird but well :) . Also, playground has checks for it but uses custom scripts. The code is at https://github.com/thingweb/thingweb-playground/blob/0ada6862b0d0d7eba3c05c40f605a89084570c50/packages/playground-core/index.js#L316

JSON Schema solution

Let's have the following array as the JSON input to validate:

[
  {
    "readOnly": true,
    "writeOnly": true
  },
  {
    "readOnly": true,
    "writeOnly": false
  },
  {
    "readOnly": false,
    "writeOnly": true
  },
  {
    "readOnly": false,
    "writeOnly": false
  }
]

We want the first items to be invalid, while the others being valid.

Currently, we have a schema like the following:

{
    "type": "array",
    "items": {
        "type":"object",
        "properties":{
            "readOnly": {
              "type":"boolean"
            },
            "writeOnly": {
              "type":"boolean"
            }
        }
    }
}

This schema says that the above input is valid.

If we however have the following schema, the first is shown invalid while the rest still be valid:

{
    "type": "array",
    "items": {
        "type":"object",
        "properties":{
            "readOnly": {
              "type":"boolean"
            },
            "writeOnly": {
              "type":"boolean"
            }
        },
        "if":{
            "properties":{
                "readOnly": {
                    "const":true
                }
            }
        },
        "then":{
            "properties":{
                "writeOnly": {
                    "not":{
                        "const":true
                    }
                }
            }
        }
    }
}

I can provide this as a fix to the TD spec but this would technically be a breaking change since we actually allow this to happen and suddenly stop allowing it.

P.S.: I have tested using https://www.jsonschemavalidator.net/

[sebastiankb]

Technical it does not make sense to have both true. Maybe for access policy reason this kind of information can be shared via different TDs for specific user: E.g., only admin is allowed to do read/write, other user have no read/write access to the some property.

[sebastiankb]

From today's TD call:

• no blocking point yet
• should be also discussed with the JSON Schema authors (@handrews) + SDF (@mjkoster)
• we should consider that issue in the TD 2.0 version

[handrews]

@sebastiankb @Relequestual has largely taken over JSON Schema leadership with my enthusiastic blessing, and should have the next draft out (fixing some notable problems with 2019-09 but nowhere near as huge of a jump as draft-07 to 2019-09) in the next month or so. I am still available to answer questions as needed, just got a bit burnt out (because 2020) and needed to step back.

[sebastiankb]

@handrews many thanks for the clarification. Take care

[egekorkan]

Just small comment regarding the following:

Maybe for access policy reason this kind of information can be shared via different TDs for specific user: E.g., only admin is allowed to do read/write, other user have no read/write access to the some property.

I think this should be done via security in the forms level where forms with op value of writeproperty would have another security definition that is linked