W3C

– DRAFT –
WoT Architecture

03 February 2022

Attendees

Present
Cristiano_Aguzzi, Daniel_Peintner, Kaz_Ashimura, Kunihiko_Toumura, Michael_Lagally, Michael_McCool, Ryuichi_Matsukura, Sebastian_Kaebisch, Tomoaki_Mizushima
Regrets
-
Chair
Lagally
Scribe
kaz

Meeting minutes

Agenda

Agenda for today

Lagally: (goes through the agenda)

Minutes

Jan-27

Lagally: (goes through the minutes)

approved

Scalable Event Model

wot-thing-description issue 1323 - Missing event/notification affordance or operation

Lagally: (shows the diagram within the issue)

diagram

Lagally: a servient having two different roles
… Consuming Thing and talking with another Thing
… subscribe operation and unsubscribe operation
… then notify operation
… my idea is TD can describe all of them
… TD has the Event affordance

Thing Description - 5.3.1.5 EventAffordance

Lagally: (explains the vocabulary term there)
… if we want to describe a Consumer
… who receives the events
… some backward communication within the Consumer Servient

McCool: we have notification from the Thing
… the Consumer responds

Lagally: yes

McCool: not clear which side touches what
… the diagram could be improved
… you want to describe the metadata on the interaction here by TD
… for example, the data payload and the data schema
… good to indicate where the related various pieces are

Lagally: there was a proposal by Ege below within the issue

McCool: Sebastian mentioned the example was odd

Daniel: don't want to argue the diagram itself
… but what you were saying was
… not just exposed side
… so far don't understand it
… I'm confused
… seems to be trying to describe both the sides
… we need to clarify what we want

Lagally: simple example here
… is an intermediary

Daniel: we need to understand what is needed

Lagally: you may communicate additional data
… my generic thinking is
… if we can make this a generic model, the discussion would be easier

Sebastian: looking at this diagram and the TD spec
… adding statusresponse itself is fine
… but everything you want to do can be done by TD already
… so don't really understand what is needed here
… what is the actual difference between the two example TD, for example?

two TDs withing Lagally's comment

(FireAlarmButton and FireAlarmListner)

Sebastian: why the second TD (FireAlarmListener) is needed?
… how/who consumes it?

Lagally: (shoes a part of the first TD, FireAlarmButton)
… getting understand your point

                "type": "object",
                "properties": {
                       ...
                       listener: uri,
                       ...
                    }
                }

Sebastian: you have to provide information using a "Form"
… but the content of TD should be the same with the data you provided
… expressing what the Thing should do for you

Lagally: data vs dataResponse

Sebastian: you should define the expected Action here
… the question is what would be the value of the information here?

Sebastian: you have to set up a new Thing for the Consumer side
… if the Consumer thinks the original Thing can't fit its usage, the Consumer needs another Thing
… you can only communicate with the Thing already defined on the Thing side
… so I don't understand what is needed here...

Lagally: we should see what can be done/implemented during Plugfests
… not suggesting we should standardize this approach right away
… we can have a workaround, but having this kind of additional mechanism would make things easier
… I can come up with some implementation for the Plugfest

Sebastian: the question is that we need to freeze the normative features for TD 1.1
… I believe what you want to do can be done by the current TD 1.1
… we need to finalize the spec shortly
… and we've already started the wide reviews

Lagally: I know
… please see the PRs here

PR 1329 - Event consumer: Alternative 1 - event operation

Sebastian: that PR is for additional "datarsponse" field
… and I'm OK with the addition itself
… but we don't need Consumer TDs

diff

kaz: TD should concentrate on the generic data model for WoT
… and this kind of detailed event handling mechanism should be done as part of the possible management Thing and the processing model for that

Lagally: if we strike out the "Application" part from the diagram, probably the story would become easier
… we just need the "Consumed Thing" on the Consumer side
… and the "Exposed Thing" on the Thing side

Cristiano: the problem here is
… the diagram is quite generic
… every thing event can be mapped here
… we can describe it successfully using the current TD already
… the diagram shows too tight coupling
… having two TDs working together itself would make sense
… but not sure how to handle them

Lagally: think about the telemetry example
… Thing talking with a cloud service

Cristiano: I've looked at Ege's comment about that point
… we should concentrate on that use case then
… and think about what is really needed

Sebastian: any reference for that?

Lagally: need to search for the resource...

McCool: we should discuss the next steps given the time
… introducing an additional feature
… but are we OK with the gap for the use case?

Lagally: let's assume we have data and dataresponse

McCool: I'm OK with having dataresponse itself
… would suggest we focus on event handling caused by the change

Lagally: ok

kaz: are we OK with accepting PR 1329 then?

McCool: except additional notify

Lagally: I'll work on the change and remove the additional "notify" then
… would that be acceptable?

Sebastian: I'm OK with "dataresponse"

Lagally: will create another PR for that then

proposal: Lagally to create an updated PR for dataresponse without notify

proposal: Lagally to create an updated PR for dataresponse without notify (can be included in the 2nd WD if possible)

RESOLUTION: Lagally to create an updated PR for dataresponse without notify (can be included in the 2nd WD if possible)

PR 702

wot-architecture PR 702 - regenerate assertions

(no objections; merged)

McCool: please create a test directory for that

Lagally: would defer it

Lagally: would like to discuss it next week

[adjourned]

Summary of resolutions

  1. Lagally to create an updated PR for dataresponse without notify (can be included in the 2nd WD if possible)
Minutes manually created (not a transcript), formatted by scribe.perl version 185 (Thu Dec 2 18:51:55 2021 UTC).