Single 'base' field but multiple 'forms' elements

[6d77]

While each InteractionAffordance can have multiple forms elements targeting multiple protocol bindings, there is only one base field, which applies to all or them. As protocol bindings are selected based on the protocol specifier in the URI, the base field is mainly useless (or at least only usable for a single protocol binding) in such cases.

I thing this is at least an inconsistency in the structure of the TD, which should be considered for some later version of a TD.

[danielpeintner]

There have been discussions about this restriction in the past (however I cannot find an actual issue or any other pointer I could share).

Having said that, I personally believe that adding multiple base's and proper linking introduces other issues and adds complexity to implementations. Moreover, I see base as a shortcut for common cases and not a generic solution. Self-contained URIs seem safer to me also.

The benefit of shrinked URIs that save space could (and probably should) be solved by clever representation formats if needed.

[6d77]

For me the main benefit of base is not shrinking, but easily applying a TD template to a specific IP address and port number changing only a single location. Here base can separate the address varying between devices of the same type from the path, which is the same for each of them.

Without base you would have the same address information in many places of your TD. In database design, it would be considered bad practice repeating the same information multiple times in multiple, similar looking places. And also in a TD this can easily lead to inconsistencies, which can be avoided by putting that information only in one common place - the base field.

So not only think of the base field as shortcut for common cases, convenience feature or syntactic sugar, but as an architectural design decision to put common information in a single place.

I don't want to repeat a discussion that has already taken place, but I want to point out, that there is still room for improvement on this topic.

[zolkis]

Here base can separate the address varying between devices of the same type from the path, which is the same for each of them.

Which is why Web specs use origin and path concepts. As I see it, base is a kind of tuple origin (scheme, host, port, without the domain).

[takuki]

So not only think of the base field as shortcut for common cases, convenience feature or syntactic sugar, but as an architectural design decision to put common information in a single place.

I think this is particularly important for Thing Description Template.

The Thing Description Template is being considered for the next WoT charter period.

For the final TD to be processed at runtime, I think we need to strike a balance between simplicity and usability.

[takuki]

In Aug 30 TD telecon, we found this an usability issue, not a functionality issue in the current TD.
The group will consider the suggested feature in the next TD version.

[sebastiankb]

In the past, we had a base that could be used as an array for multiple protocols. However, this was criticized because of the arithmetic that you have to take care of (as TD designers and implementations).

[sebastiankb]

The introduction of this function in TD 1.1 would result in backward compatible problems with TD 1.0. Therefore this topic should be covered in TD 2.0.

[egekorkan]

The issue #1026 points here but there is one point about changing IP addresses that is not covered here. Here, we are discussing about multiple IP addresses known in advance but not about IP adresses that are not known in advance and that are properly dynamic. Current solution for this would be to change the TD or manage a TM based approach but a solution to this would be nice if we can find an elegant way to do that.