Re: What to do with WoT Profiles 1.0

Hi Luca, Ben, and all,

Luca wrote:

I think the problem here is that having implicit elements could confuse
a consumer, but the best would be to see something practical.

I thought we already did but to make sure it is documented, I am adding it to the end of this email.

Following points are from Ben (indented ones):

What structure would you suggest? Every time this topic is raised in a meeting the response is that it should be discussed in writing and every time it is raised in writing the response is that it should be discussed in a meeting. I have made proposals in meetings, by email, in GitHub issues, in presentations and even strawman specification documents.

I do not have a quick solution but something threaded per issue sounds more reasonable. These can be different github issues or a github discussion which supports thread feature. I do not want pushing the discussion here and back but each time we go in this direction, a can of worms open and becomes difficult to close. This is expected at this point since there are multiple discussion points.

I think many of us are at least on the same page about a potential long term solution (i.e. WoT Profiles 2.0)

I agree with you on a high-level.

I'm afraid we'll have to agree to disagree on this point, because I don't believe the Thing Description specification will ever be expressive enough with binding templates alone to describe the level of detail necessary for out-of-the box interoperability.

I agree to disagree. Along the line, TD will be expressive enough, except for OOTBI maybe. For simple cases, it is already OOTBI from our point of view, even without profiles. For complex cases, there is lack of expressiveness and an big architectural gap for the “Things as clients” part we see with WebHooks. I think that a protocol like WebThing protocol over WebSocket can fix a lot of this gap but I sadly do not have time to look deeper into it.

but it would be useful to know whether Siemens would formally object to the publication of Profiles with the current approach, or whether they just don't want to implement them because it's architecturally inconvenient.

The second one. Details at the end of the email.

For the record, this is not true. Cristiano and I spent a great deal of time (paid for in part by private consulting and government grants) bringing WebThings Gateway into line with the current WoT Profile specification.

I was not aware of the extent of it, sorry for the uneducated remark.

Can you provide any details here? (Ege: about confusion of implementers)

Some within Siemens thought that one must implement a Profile to become a WoT-compliant implementation, which is not the case.

Details on implementation issues:

Let’s take a very simple example. A profile, let’s call it profile X, has only one assertion which says that actions must be invoked via HTTP PUT with a JSON payload. To indicate this, a TD will have the corresponding URL in the profile keyword’s value but does not have to indicate this in the form level, i.e. does not have to put “htv:method”:”PUT”.

Going into the Scripting API and node-wot implementation, it has a rather simple architecture. For a given TD, when you code thing.invokeAction(“myAction”, myVal), it goes through the TD, finds myAction, looks at the forms to find “invokeaction” in the op values and then checks whether it supports the uri scheme and the contentType. In this case of a Profile X TD, it will find HTTP and JSON, and will direct the function to binding-http stack. Each binding is a protocol-specific set of code that concretely implements the operations.

In this case, without implementing profile-aware parsing, the binding stack will send an HTTP POST request since the lack of method means using the default value, which is POST. To avoid this, in the binding level in the code, we have to start a switch logic based on the profile keyword, i.e. overwrite the defaults based on the knowledge we have on the profile. If there are multiple profiles, not sure what will happen. If there is a profile we do not know, it is walking in the dark and becomes a topic of degraded consumption. Putting this switch logic in the binding level is quite annoying and does not scale well in my point of view. With the future of profiles unclear, I am not sure if we would ever want to put this code into such an important part of node-wot.

We can avoid this implementation change by processing the TD before giving it to node-wot. In this simple case, it would be detecting profile X and adding method name to the relevant forms. This is possible since this profile is a subset of TD spec or in other words, everything in the profile can be described explicitly in the TD and used by profile-agnostic TD consumers. That way, we would have implemented profile X where such a processing of a TD can be offloaded to a separate package rather than http binding implementation in node-wot.

Now, looking at the current profiles, we cannot do this processing and generate a fully descriptive TD that can be understood by node-wot for all the details of the profile. Since we cannot implement all the details, it is the same thing as not implementing the profile since a Consumer should support every feature. Not being able to generate a fully descriptive TD implies that there are implicit mechanisms in a profile and this is the real problem.

Notes:

  *   I can provide this in a diagram if needed.
  *   Implementing a one-shot Thing and a hardcoded consumer is not the issue. I hope this is clear.

Best,
Ege

From: Luca Barbato <luca.barbato@luminem.it>
Date: Sunday, 28. April 2024 at 12:23
To: Ben Francis <ben@krellian.com>, Korkan, Ege (T CED IIS-DE) <ege.korkan@siemens.com>
Cc: public-wot-wg@w3.org <public-wot-wg@w3.org>
Subject: Re: What to do with WoT Profiles 1.0
On 26/04/24 23:10, Ben Francis wrote:
> In the last meeting I attended Luca said he would put a proposal in
> writing to the wider Working Group (since it requires a wider
> consensus), but as far as I can tell that didn't happen. I believe it
> was then discussed again in the following two WoT Profile meetings, but
> still no decision has been made.

I tried to get at least the consensus in the TF and understand exactly
how to address the concerns voiced by Daniel and Ege, but even that is
taking a bit more time than I wished =/

> What you call "implcit mechansims" but I would call a "concrete protocol
> binding" is the only available option to guarantee interoperability in
> WoT 1.x, since the Thing Description 1.1 specification is not expressive
> enough to unambiguously describe the full set of operations currently
> defined. If the consensus is that this is not acceptable, then that may
> rule out Profiles 1.0 being published in its current form. I think we
> need to hear more opinions on this.

I think the problem here is that having implicit elements could confuse
a consumer, but the best would be to see something practical.

>       * Any mention of ambiguity means a lack of expressiveness in the
>         TD spec, thus should be solved there first. The TD TF is aware
>         that there are a lot of things to do and we are working on
>         structuring the work and prioritizing work items.
>         Metaoperations is a can of worms and we will handle that in this
>         charter. Any suggestions on that would be nice. Along with
>         manageable actions.
>
>
> I'm afraid we'll have to agree to disagree on this point, because I
> don't believe the Thing Description specification will ever be
> expressive enough with binding templates alone to describe the level of
> detail necessary for out-of-the box interoperability.

You can bind a behavior to vocabulary terms, so everything would work as
long as the terms are in the TD. But I think we are returning on the
topic of degraded consumption.

lu

PS: Since Discovery and Security are on pause, can we have a Monday slot
for Profiles assuming it works better for everybody?