TD common definition and affects on formIndex

[danielpeintner]

@relu91 @danielpeintner I have added that TD as example but not as recommended as we don't want to encourage that as generic mechanism. I also now think that indicating formIndex in ScriptingAPI will not work nicely in compacted TDs that the developer sees. They would need to say that they prefer the form with this form/connection definition

Originally posted by @egekorkan in w3c/wot-thing-description#2163 (comment)

[egekorkan]

So what I wanted to elaborate today was that I don't find the current pattern of specifying a number when I want to say that I want to use http. It is an indirection that only simplifies the scripting api implementation but nothing else. The developer should never have to look into the forms or need to parse the forms in the application layer logic. It also makes the logic protocol and TD specific where there is no need to do so. With specifying something more meaningful, we can even find closely matching forms when there is no form found that matches exactly what the developer wants.

[danielpeintner]

The problem is that in many cases the selection is not purely on the protocol. I might have TDs with the same protocol but for example ipv4 vs ipv6 OR http with local vs public IP etc.
I think there are many such cases, and therefore we settled to use the formIndex to identify the form we need without going into too much hassle. Does that make sense?

Hence, the question I have is how can we properly support TD common definitions. For now, I think we should go with the approach @relu91 proposed to always work on expanded TDs.

[egekorkan]

Even without common definitions, the formIndex approach is for me still an indirection that only benefits the implementation but not the user. So the hassle is warranted from my point of view as a user. Nowhere else we require the developer to look into forms but here.

We can specify what can be provided (not everything) and for now that can be just the URI scheme and contentType. Theoretically, even modbus baud rate can be an input but that can be simply not provided as a filtering option.

[danielpeintner]

Even without common definitions, the formIndex approach is for me still an indirection that only benefits the implementation but not the user.

I think on the contrary. A good implementation can use any form (maybe the first one?). Anyhow, users might experience some problems with the selection .. maybe because the connection is fluky.. and an implementation might provide to the use the option to select "which" form to use... maybe the power user know which connection is more stable etc.

To put a long story short. I still believe formIndex is a good optional setting.

Nowhere else we require the developer to look into forms but here.

By default, you don't need to look into. You CAN if for whatever reason you want to...

[relu91]

I'm in the middle. I think that formIndex is a fundamental mechanism to let the application "break" the curtain and apply its own logic, but it might be nice to have a mechanism that is better than "I don't care which form you use.". Applications/libraries built on top of Scripting api should choose their own level of abstraction:

• I need to know exactly which form I'm using
• I just want to specify a protocol/ip/content-type.. (the problem here is to choose which "generic" parameters the applications want)
• I don't care I only want to read-write etc.

[danielpeintner]

Call 2025-12-10

@relu91 hope expansion algorithm is usable with formIndex. Maybe we can use TD expansion algorithm to select form (choosing a form definition).

@danielpeintner helper/utility function can use protocol and other information to get formIndex