No mechanism to indicate the "desired" form entry

[danielpeintner]

We got the request in the Scripting API task force that scripts might want to choose which form is used. In the sample TD below a script would like to decide which form entry is used for a given interaction (e.g., form[0] for the interaction toggle because it uses HTTP).

{
	"@context": "https://www.w3.org/2019/wot/td/v1",
	"title": "MyLampThing",
	"securityDefinitions": {
		"basic_sc": {
			"scheme": "basic"
		}
	},
	"security": ["basic_sc"],
	"actions": {
		"toggle": {
			"forms": [{
					"href": "https://mylamp.example.com/toggle"
				},
				{
					"coap": "https://mylamp.example.com/toggle"
				}
			]
		}
	}
}

Besides the desired intent of a script e.g., preferring HTTP (which is not supported in scripting yet) there is also no way to indicate in a TD what form entry is preferred. WoT runtimes are free to pick any form while it seems that there is an unwritten assumption that the order in the array might be an indicator.

Does it make sense to have a more explicit mechanism in a TD that indicates the preferred form entry or to make the unwritten assumption more evident in the specification?

[mmccool]

Previously we have discussed using the order of multiple forms to assign priority. However, the consensus of that discussion was that some consumers might do this, but we decided not to have a "MUST" assertion saying they do. If some consumers assigned a meaning to the other, then even if no meaning is assigned to the order by the specification, I think we should have an assertion that processors should not reorder forms arbitrarily, to avoid breaking such consumers (and maybe future-proofing against using order to assign priority later).

[zolkis]

processors should not reorder forms arbitrarily

I think that is the right formulation (SHOULD NOT) since clients MAY still choose whichever Form found in the TD.

However, as discussed in the Scripting call, it makes sense to be able to select the Form from an application, so the Scripting API will add that option to the interactions exposed by ConsumedThing.

Also, when specifying an ExposedThing with Forms, Scripting API implementations SHOULD NOT change the order clients specified for Forms. This is independent of the decision the TD TF has made and ensures compatibility with eventual later policies.

[takuki]

In TD call on 2/14, we discussed and suggest to say something like "Clients may choose the first form entry that works for them." in TD specification. This does not introduce any new constraint.

[sebastiankb]

@takuki can you provide a PR for this statement?

[sebastiankb]

please checkout PR #1108 if it is working for you

[sebastiankb]

PR merged