Open zolkis opened 4 years ago
How does an implementation know that an object in the TD Action
input
is meant as a single object parameter, or was meant as multiple parameters made from the members of the object?
I think there is either no or one input to an action.
This action input can be of a
{"type": "string"}
) or it can be also a { "type": "object", "properties": { "name": { "type": "string" }, "age": { "type": "integer", "minimum": 0 } }}
)OK, that would work. Anyway that constraint needs to be stated out loud in the TD spec, maybe as a note.
This is how the JSON schema works. But you're right, it wouldn't hurt to say more words about it.
The wording needs to be about the convention that an Action has 0 or 1 argument, and multiple arguments are represented as properties in an object.
Looking at it again, the above discussion is actually not correct. If you put { "type": "object", "properties": { "name": { "type": "string" }, "age": { "type": "integer", "minimum": 0 } }}
does not mean that you can send a name
or an age
as a string. You still have to send an object. The correct way to do it would be:
{
"oneOf":[
{"type": "string"}, //this would be the name above
{"type": "integer"} //this would be the age above
]
}
Actually it was fine, @zolkis was asking how to convey that an action can take multiple parameters. In other words, if you consider an action like a regular programming function, how can I express something like this:
function action1(input1: string, input2: string) {}
As @danielpeintner was suggesting, given that you can express only one input data schema for every action you have two options:
I would say that we can give the TD designer the freedom to choose between these two forms, because, given the fact that we are describing payloads, I think that strictly speaking it depends on the underlying platform payload. However, for the next charter I'd like to put some effort to get rid of URIVariables and unify everything under a relevant interface describing the inputs/outputs of WoT interface operations. This means that we might review this discussion and improve a little bit the spec.
I think it is worth re-opening.
Is there any update on this topic?
The current description of representing Action parameters in the TD is too laconic and creates misunderstandings.
The text should say how is it possible/recommended to represent multiple inputs to Actions, for instance by using an ObjectSchema.
But that would clash with representing a single parameter that is an object. How does an implementation know that an object in the TD Action
input
is meant as a single object parameter, or was meant as multiple parameters made from the members of the object?