Re: What to do with WoT Profiles 1.0

On Mon, 29 Apr 2024 at 07:47, Korkan, Ege <ege.korkan@siemens.com> wrote:

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

OK, so this is obviously a misunderstanding. This is not a problem with the
normative content of the specification, but perhaps its informative
introduction and wider documentation of the Web of Things.

I have filed https://github.com/w3c/wot-profile/issues/402 to discuss this
further.


>
>
> 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.
>

Thank you for explaining this, I've never seen it put quite like this and
it helps me understand where you are coming from. I have taken two key
points from this...

*Compatibility with Binding Template Defaults*

It's interesting to me that to illustrate the point you had to invent a
hypothetical profile which prescribes something which conflicts with the
defaults defined in a binding template. I can definitely see how that would
cause a problem, but we have taken great care to design the current
profiles in such a way that does not conflict with the defaults of
bindings. This makes profiles a "progressive enhancement" on top of the
default behaviour, rather than conflicting with it.

This of course relies on the authors of future profiles doing the same, but
at least with the current (presumably short term) approach of all profiles
being specified in a single specification, we have some level of control
over this as a Working Group.

We could go further than this, by adding an assertion to the WoT Profiles
specification which requires that profiles must never prescribe something
which conflicts with the defaults in a binding template for a given
protocol. If we think that in Profiles 2.0 the profile protocol bindings
and binding template defaults might actually be merged and become the same
thing, it might be a good idea to specify this constraint now in Profiles
1.0. The one problem I can see with that is that currently profiles are
normative and binding templates are non-normative, and having a normative
assertion rely on the content on non-normative text may be a problem.

I have filed https://github.com/w3c/wot-profile/issues/404 to discuss this
further.

*Implementing a Profile by Pre-processing a TD*

Another point you make is that (at least for the node-wot implementation),
it would be convenient if a profile could be fully implemented by
pre-processing a Thing Description to declaratively express all the details
defined in a profile's protocol binding using a binding template vocabulary.

Firstly, this is not the only way to implement a profile and I don't think
we should limit the profiles specification by the architectural decisions
taken for one (albeit important) early implementation. I also feel strongly
that we shouldn't limit profiles to what is currently possible with the
informative Scripting API. Conforming to the Scripting API is optional for
JavaScript implementations and largely irrelevant for non-JavaScript
implementations. The scripting API should follow the other specifications,
not the other way around.

Having said all of that, I agree that in an ideal world it would be
possible to express the full protocol binding from each profile using a
binding template vocabulary and agree that the pre-processing approach you
describe is a neat way to implement profiles. Given we have established
this isn't possible today, as a minimum a Thing which implements a profile
should not exhibit behaviour that a generic Consumer consuming its
minimalist Thing Description would not reasonably expect. In other words a
profile may progressively enhance a Thing for conformant Consumers, but not
break non-conformant Consumers. Perhaps this is something else we could be
more explicit about in the Profiles 1.0 specification.

I have filed https://github.com/w3c/wot-profile/issues/403 to discuss this
further.

I have also filed https://github.com/w3c/wot-profile/issues/405 to address
the one case I have identified so far (synchronous member set to undefined)
where this is not already the case today.

A more extreme approach would be to require that any aspects of the
protocol bindings in profiles which can not be expressed using a binding
template vocabulary today should be made optional and non-normative in the
specification, since it would be awkward to implement in node-wot. I
personally don't think we should do this and would prefer the "progressive
enhancement" approach, where a node-wot Consumer will simply not use
features which can't fully described declaratively. In practice this mainly
just means node-wot might not support async actions. However, if anyone
thinks we should make those parts non-normative (or remove them entirely)
then please feel free to file an issue to discuss that further, and detail
the specific features you think need to be removed.

-- 

Thank you again for taking the time to explain this. Hopefully the issues I
filed will help split out some key issues and provide more structure to the
discussion.

I would encourage people to file other issues if there are other problems
that would either a) prevent you implementing profiles in your
implementation or b) cause you to object to the specification's publication.

I still think we need a wider Working Group consensus on the original
question I posed at the top of this thread, and a path forward for Profiles
1.0.

Kind regards

Ben

>