Re: What to do with WoT Profiles 1.0

Hi Ege,

Thank you very much for taking the time to reply, I appreciate your
engagement on this.

On Fri, 26 Apr 2024 at 17:35, Korkan, Ege <> wrote:

> I think such discussions should be done in a more structured fashion.

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 think many of us are at least on the same page about a potential long
term solution (i.e. WoT Profiles 2.0), but currently all progress seems to
be blocked on the decision about what to do with WoT Profiles 1.0.

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 stilll no decision has been

This email thread was my attempt to present two concrete options for a path
forward, though I note you haven't directly commented on either.

I'm sorry this thread ended up getting deep into the details, but I do
think that's what's necessary in order to get to the bottom of the
reservations people have about profiles and identify concrete next steps to
address them.

>    - In the previous calls, there was preliminary consensus on not using
>    profile as a patch mechanism for mechanisms that we cannot describe now in
>    the TD. Also, along the same lines, no profile should bring implicit
>    mechanisms (sometimes referred to as extending the td spec but I think this
>    is not a correct wording).
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.

>    - 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. At best, binding templates (a more
accurate name would be "binding vocabularies") are useful for describing a
small subset of what is possible with a given protocol, to provide a
limited level of compatibility with brownfield devices. Facilitating full
cross-vendor out-of-the-box interoperability between greenfield devices
requires something more detailed and prescriptive.

> We don’t say a generic consumer but a consumer implemented in a generic
> way. node-wot and many other implementations are like that. It is just
> architecturally annoying to implement another stack to handle profiles that
> add their own stuff. I feel that this point is just never understood by the
> profile TF or I feel it is kept getting ignored.

What are the other implementations of a "consumer implemented in a generic
way"? Are any publicly available for testing?

I do understand that having two separate code paths for consuming Things
depending on whether they use a profile is awkward. I think we have a
potentially neater approach to that for WoT 2.x, but we need to decide what
to do about 1.x.

I understand that profiles are not a commercial priority for Siemens (where
perhaps cross-vendor interoperability is not considered so important), 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. And
if they would object, what specific changes would be needed to address
those concerns?

> Ben wrote
> As far as I can tell, the current profiles only add functionality for
> conformant Consumers, they don't take functionality away for non-conformant
> Consumers.
> We have presented the case against this with node-wot many times.

I'm not saying this isn't true, but can you show me? I have only ever heard
this discussed in theory, never demonstrated in practice. I took great care
to design the profiles I worked on in such a way that wouldn't trip up
generic Consumers and functionality would degrade gracefully, so if there
are cases where Consumers do get confused I would like to know about it.

> Ben wrote:
> We are at a very late stage in WoT Profiles 1.0 to make such a drastic
> change to how they work and introduce completely new ontologies,
> effectively rendering all existing implementations obsolete.
> Other than WebThings, which was sort of profile compliant before the
> profile spec anyways,

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. This required deep architectural changes, the repercussions
of which I am still dealing with today. Please don't underestimate the
amount of effort which has gone into the implementation on both the
Producer and Consumer side to implement the current specification.

> the example implementation from Oracle and the new one I have heard from
> Luca, there are no other implementations.

This is certainly a problem, and I would welcome implementations from other
major contributors like Siemens and Intel. This is why I am keen to get to
the bottom of any reservations (or perhaps misconceptions) people may have.

> WebThings implementations should be describable in TD 2.0 and there should
> be no need to change it.
No implementation should be required to change to fit WoT in general, at
> least for Things.

If the profiles change, then Things which conform to them will need to
change. That is the nature of profiles. Consumers (e.g. Krellian Cloud)
which depend on profiles will definitely need to change, and will not
automatically be able to consume 2.0 Thing Descriptions. It will also be
years until 2.0 specifications are published, and a solution is needed in
the meantime.

>  Yes, there has been the case in Siemens with early adopters. I can
> provide more details in a meeting. Mizushima-san also expressed similar
> concerns in this week’s call.

Can you provide any details here? All that was recorded in the minutes of
the last last meeting were high level reservations, since there's never
enough time to go into sufficient detail.

> There are many open points in WoT and we should work on resolving them.
> Hope to see you in one of the next WG calls.

Yes of course, and I feel positive about the latest charter which mentions
lots of important topics, though many are topics which were also in
previous charters and didn't actually get solved.

I understand it's frustrating when people don't attend calls every week,
but please understand that it is a luxury to have an employer who will pay
a contributor to sit through many hours of standardisation meetings a week,
often with few tangible results. Please understand that some Working Group
members need to contribute asynchronously, but that doesn't mean we (I)
take it any less seriously.

I'm sorry if this email comes across as a bit pointed. I believe you and I
are actually very aligned on a long term direction for profiles, I
particularly value your expertise and experience and you are one of the few
people who regularly engage on this topic.

I just can't justify sitting through hours of meetings where the same few
people talk around in circles about the same topics but don't (or can't)
make tangible progress. I need to find a path forward for profiles, because
my company's products depend on them.

I would be very grateful for any opinions on the two potential paths
forward I proposed, or concrete examples of problems that need solving to
move forward.

Kind regards



Received on Friday, 26 April 2024 21:10:50 UTC