contentCoding for ExpectedResponse and AdditionalExpectedResponse?

[JKRhb]

In the context of w3c/wot-binding-templates#193, I noticed that for the ExpectedResponse and AdditionalExpectedResponse classes, there is currently no contentCoding field defined. This could cause some ambiguity if a contentCoding is defined at the Form level. Furthermore, having no contentCoding makes it difficult to map these two classes to CoAP, where a few Content-Formats (which are a combination of a content type and -- in two cases -- a content coding) could not be modelled by either of the two classes.

I think this is a very minor issue, though, so it could probably be postponed to TD 2.0.

[egekorkan]

It can definitely be added in TD 2.0. However, we sort of have a solution now already, just not very elegant. You can use parts of the TD ontology in other places: https://www.w3.org/2019/wot/hypermedia#forContentCoding

a verbose TD would look like this

{
	"@context": "https://www.w3.org/2022/wot/td/v1.1",
	"id": "urn:uuid:0804d572-cce8-422a-bb7c-4412fcd56f06",
	"title": "MyLampThing",
	"securityDefinitions": {
		"basic_sc": {
			"scheme": "basic",
			"in": "header"
		}
	},
	"security": "basic_sc",
	"properties": {
		"status": {
			"type": "string",
			"forms": [{
				"href": "https://mylamp.example.com/status",
				"contentType": "application/json",
				"response": {
					"https://www.w3.org/2019/wot/hypermedia#forContentCoding": [{
						"@value": "deflate"
					}]
				}
			}]
		}
	},
	"actions": {
		"toggle": {
			"forms": [{
				"href": "https://mylamp.example.com/toggle",
				"contentType": "application/json",
				"contentCoding": "gzip"
			}]
		}
	}
}

You can of course put the URL inside the @context and make it look nicer but something like what I have pasted is technically correct