Changing the Platform Bindings to Combination Bindings

[egekorkan]

This is mostly editorial at this point given that there are no Platform Bindings but I had struggled before to find a name for cases like ECHONET Lite Web API, Philips Hue, and similar. Some of them are product ecosystems, some are platforms and some are standards that are about the protocol and data format. I think the word "Platform" is misleading given that ECHONET Lite Web API is not really a platform from my understanding. So I would propose changing the name of the category to "Combination Bindings" . It is not an "elegant" name but would make things more clear.

[egekorkan]

I have also used this term in the new charter proposal (line 278 at https://github.com/w3c/wot/pull/1065/files#diff-c932dc2c3feab042e31ac1654200765dee2318c17286329a1defd6195969e3d3R278)

[JKRhb]

Hmm, could "ecosystem binding" be an alternative? This could cover platforms, subprotocols, and APIs at the same time.

[egekorkan]

After talking with @mjkoster , another proposal would be to call them a "Framework Binding"

[benfrancis]

some are standards that are about the protocol and data format

Another use case I've been thinking about is Server-Sent Events, where I'm not sure it really makes sense to specify a "Server-Sent Events Protocol Binding" and "Event Stream Payload Binding" (for the text/event-stream content type) separately.

Whilst in theory it's possible to use the Server-Sent Events "protocol" with other event framing formats, in practice the two are tightly coupled together and are defined in the same section of the same WHATWG specification.

[egekorkan]

Call of 05.04:

• @mmccool : Arch spec uses platform at terminology. Framework is neutral and sounds good.

• @ashimura : Confusing to say that there are three bindings types, there is one mechanism.

• @mmccool : Each binding could say what part of TD it constrains

• @ashimura : we should get more information on what developers expect and best practices

• The participants of the call are tending towards removing the distinction and call documents like "HTTP Binding", "JSON Binding" and "OPCUA Binding" and the documents can specify what they "bind" and constrain.

[chachamimm]

I agree @ashimura opinions.

This is my opinion.

I don't think the protocol binding naming issue is too important.

If you want to change the name of the binding template, you should analyze and define and categorize all IoT protocols and IoT functions before renaming. If you can't define and categorize, naming issues will cause to confuse. Because people have different points of view.

I think "the platform bindings", "the combination bindings" are results.

I think we need to think about the core binding template. I think "HTTP Binding", "JSON Binding" and "OPCUA Binding" are results to adapt the core binging template.

ECHONET Lite Web API has already been implemented WoT. So I don't know if it is correct to deal with ECHONET Lite Web API in the binding template.

[egekorkan]

See #281 for further discussion.