- From: Luca Barbato <luca.barbato@luminem.it>
- Date: Wed, 5 Jun 2024 09:56:19 +0200
- To: public-wot-wg@w3.org
On 04/06/24 19:06, Kaebisch, Sebastian wrote: > Hi Ben, all, > > thank you very much for your emails. As I have been on holiday for the > last 2 weeks, I am only now getting around to replying. > > I am surprised by the resolution draft, as it contains a conflict that > we have already expressed several times in the past such as in [1] and [2]: > > “...Profiles 1.0 profile specifications are allowed to define protocol > bindings that go beyond what can currently be described with binding > templates…“ > > Taking this into account, profile-based TDs are no longer a true subset > of the TD1.1 spec and not compliant to the WoT paradigm. In addition, > the WoT Binding Templates document no longer has any value, as the > implementer does not know whether a different binding paradigm is > followed somewhere else. They solve different problems, keep in mind that TD1.1 compliant descriptions can bring in ANY ontology and in any way it pleases the implementor, e.g. putting the vocabulary terms in conflicting/unexpected namespaces. This is a concern I voiced few times and it is to be addressed in 2.0 :) Profile do reign in this kind of flexibility, binding-templates provide composable building blocks implementations may agree with, but does not warrant that a Consumer aware of a protocol binding can fully consume every Thing using that protocol binding. A Thing sporting the basic profile warrants that all its read/write properties and all its invoke actions sporting an http form can be fully used. A Thing sporting the sse profile warrants that a Consumer can observe all the affordances that have http+sse forms and so on. > My assumption is, if the Profile has specific demands on the binding > definitions such as implicit assumptions of async actions, it should be > clarified in the official WoT binding document and not somewhere else. We do not have a mean to express relationship across affordances, nor way to map a response data schema to a affordance data schema. > Since this topic will be also discuss in the new charter in the TD2.0 / > Binding TF, it would more make sense to release Profile as Note so far > and publish Profile 2.0 as REC that harmonize perfectly with TD 2.0 > (this would correspond to your Option 2 below). The concerns I got from members is that not having __now__ a mean for greenfield implementations to offer a compelling set of features would hamper adoption and I tend to agree with them. Ideally a Thing supporting profiles from Profile 1.0 would be fully described within TD 2.0 and it would be a good fitness test for 2.0 overall. lu
Received on Wednesday, 5 June 2024 07:56:26 UTC