Consider to add one or more validation steps to assure TD consistency

[relu91]

In #231 we simplified the validation algorithm to just one step. This step leverage on the JSONSchema defined in the TD specs. However, to the best of my knowledge, JSONSchema does not handle complex constraints between fields. For example, if a particular value of the field is only admitted if another field as a specific value.

Currently, we do not check if a form of an affordance has the correct op values. For example, a property might have a form with "op": ["invokeAction"] and still be a valid TD for the current JSONSchema. We should look in those use cases (and maybe find some more) and update the validation algorithm consequently.

[danielpeintner]

Currently, we do not check if a form of an affordance has the correct op values. For example, a property might have a form with "op": ["invokeAction"] and still be a valid TD for the current JSONSchema. We should look in those use cases (and maybe find some more) and update the validation algorithm consequently.

I did a quick check with the playground which as far as I know uses JSON schema validation only. The following snippet fails with "op should be equal to one of the allowed values"

{
	"id": "urn:simple",
	"@context": "https://www.w3.org/2019/wot/td/v1",
	"title": "MyLampThing",
	"securityDefinitions": {
		"basic_sc": {
			"scheme": "basic",
			"in": "header"
		}
	},
	"security": [
		"basic_sc"
	],
	"properties": {
		"status": {
			"type": "string",
			"forms": [
				{
					"href": "https://mylamp.example.com/status",
					"op": ["readproperty", "invokeAction"]
				}
			]
		}
	}
}

Note sure if there are other cases that currently are not properly handled....

[relu91]

Correct, I checked and this is properly modeled in the TD JSONSchema:

"form_element_property": {
            "type": "object",
            "properties": {
                "op": {
                    "oneOf": [{
                            "type": "string",
                            "enum": [
                                "readproperty",
                                "writeproperty",
                                "observeproperty",
                                "unobserveproperty"
                            ]
                        },
                        {
                            "type": "array",
                            "items": {
                                "type": "string",
                                "enum": [
                                    "readproperty",
                                    "writeproperty",
                                    "observeproperty",
                                    "unobserveproperty"
                                ]
                            }
                        }
                    ]
                },
                "href": {
                    "$ref": "#/definitions/anyUri"
                },
                "contentType": {
                    "type": "string"
                },
                "contentCoding": {
                    "type": "string"
                },
                "subprotocol": {
                    "$ref": "#/definitions/subprotocol"
                },
                "security": {
                    "$ref": "#/definitions/security"
                },
                "scopes": {
                    "$ref": "#/definitions/scopes"
                },
                "response": {
                    "type": "object",
                    "properties": {
                        "contentType": {
                            "type": "string"
                        }
                    }
                }
            },

Now I am wondering if we can cover also the oAuth validation... which basically constraint some fields only if another has a particular value:

{
//.....
   "flow": "client",
   "authorization": "....", //this field is not allowed
   "token": "...."
}

[relu91]

Now I am wondering if we can cover also the oAuth validation... which basically constraint some fields only if another has a particular value:

It is possible:

{
	"$schema": "https://json-schema.org/draft/2019-09/schema",
    "type": "object",
    "oauth_code":{
      "type": "object",
      "properties":{
      	"flow": {
           "type": "string",
          "enum": [ "code"]
        },
        "authorization":{"type":"string"},
        "token":{"type":"string"},
       
      },
      "required":["authorization","flow","token"]
    	
    },
    "oauth_client":{
      "type": "object",
      "properties":{
      	"flow": {
           "type": "string",
          "enum": [ "client"]
        },
        "token":{"type":"string"},
        "authorization":{"type":"null"}
       
      },
      "required":["token"]
    	
    },
    "properties":{
         "securityScheme": {
            "oneOf": [{"$ref": "#/oauth_code"},{"$ref": "#/oauth_client"}]
         },
    }
}

There might be also alternative ways to achieve the same behavior using dependencies or patternProperties

[danielpeintner]

This seems to be an improvement that could (should?) go into the TD spec.
@egekorkan how do you see it?

[egekorkan]

This would work. dependencies may not work here since it is not possible to specify that something is not allowed. using not would not work I think. Once this is in the TD spec, we can add it to the validation schema and playground.

[relu91]

Another validation step that came to mind is to verify that the servient actually can serve the TD. For example, TD may specify a form with an MQTT scheme but the underlying servient may not support this protocol binding. In this scenario, the TD is syntactically valid but is still not correct for the runtime. Therefore, I'll add this verification step to the expose algorithm rather than to the validation.

[egekorkan]

I would also say that it should be in the expose. There could be the binding but the broker might be down at that moment of trying to expose

[relu91]

@egekorkan From 23/11/2020 call. Could you please provide a list of the additional validation steps that the playground does?

[egekorkan]

The additional checks are "documented" here: https://github.com/thingweb/thingweb-playground/blob/24cb71d465755d1c361bdb7c50b96963e80b3608/packages/playground-core/index.js#L54

Basically some simple static checks are done, nothing like checking whether the broker is available or whether the thing is available:

• enumConst: "Checking whether a data schema has enum and const at the same time."
• propItems: "Checking whether a data schema has an object but not properties or array but no items."
• security: "Check if used Security definitions are properly defined previously."
• propUniqueness: "Checking whether in one interaction pattern there are duplicate names, e.g. two properties called temp."
• multiLangConsistency: "Checks whether all titles and descriptions have the same language fields."
• readWriteOnly: "Warns if a property has readOnly or writeOnly set to true conflicting with another property."

Other checks can be added quite simply into this list.

[danielpeintner]

A related TD issue w3c/wot-thing-description#1043 has been closed by mentioning

@mmccool is going to create another issue for remaining improvements.

I don't think this has ever really happened.

At the moment the TD provides the following section https://w3c.github.io/wot-thing-description/#validation-serialization-json.
Are we okay with it or should we create a new issue (o re-open the old one)?

When it comes to security only there is a corresponding TD issue, see w3c/wot-thing-description#954.
Anyhow, I am not sure if it covers all aspects, does it?