Meeting minutes
Previous minutes
<kaz> (later)
Continue discussion about new eventing approach
<kaz> Issue 1323 - Missing event/notification affordance or operation
Lagally: I added example to issue 1323
… we have many use-cases for push notifications in use-cases document
… e.g., in retail, AllStopButton
… keeping TCP connection open drains battery
… https://
… fire alarm button
… fire alarm observer
… flow
… 1. FireAlarmObserver subscribes to FireAlarmButton event affordance, registers itself as a listener.
… 2. Human user pushes the button, the FireAlarmListener gets notified, this triggers multiple actions, such as calling the police, sending a fire engine, ...
… 3. There may be additional events, such as "batteryLow" to indicate the need of human intervention and maintenance, i.e. a service person replaces the battery of the FireAlarmButton
… <walks over TD snippets>
… in case of alarm button true/false
… dataResponse ... operator name
… acknowledge in dataResponse
Sebastian: 2 actors, FireAlarmListener vs FireAlarmObserver
Lagally: inconsistency .. let's call it listener
Lagally: not only webhoock, more a general thing
Sebastian: dataResponse is the only *new* thing, correct?
Lagally: Yes
… we can still think about renaming
… we have form with "op": "notify"
Sebastian: the notify form confuses me
… not sure about 2nd TD, who is consuming this TD
Lagally: It describes listener interface
… in the simple case it is just an URL
Cristiano: about 2nd TD
… I am worried about semantics
… we are not creating events ... I am waiting for this event
Lagally: Similar to method signature
Cristiano: we are defining a *magic* signature
… we describe event as source ...but this describes source
… 2 different things
Lagally: in my thinking "event" is a contract
Lagally: Chain of buttons ...
Daniel: not sure how a TD consumer know whether it expects a event or waits for event
Lagally: Not sure about syntax
… assumption, everything can be described with TD
… we should be able to describe consumers
… thing to thing contract
Lagally: I need to go
… please take a look at the example ... and provide comments
Sebastian: I understand first TD
… I still struggle with 2nd TD
… it describes a consumer
… information for implementation
Lagally: Try to join next call again
Sebastian: Thanks!
<MLagally left>
Sebastian: I understand the dataResponse container
… on the consumer side with the event .. I am not sure
Cristiano: Good example to be discussed in a call
… does it make sense to have an extra ordinary slot/call
Sebastian: I agree, on the other hand, I have difficulties to find a slot
Kaz: Sebastian, maybe having a call with MLagally ?
Sebastian: Possible, but then someone needs to report to the community
Cristiano: OR lets try again next week to make progress
Kaz. my point is rather that Sebastian as the main Editor of the TD spec can chat with Lagally offline to understand his points and we can make the discussion during the TD call smoother. you don't need to report back from that chat itself.
MK: The confusion is about data being pushed .. and the direction
… we are looking for a different pattern
… I think MLagally wants to see the address .. where data is pushed to
… maybe there is a different solution
<mjk_> qck mjk
Sebastian: address should be shared in subscription container
Sebastian: Still very unclear to me
Sebastian: Let's try to have a meeting with MLagally
Previous minutes (re-started)
<SK walks through minutes>
Sebastian: w.r.t. changelog, Taki can work on that topic
Sebastian: any comments/concerns?
… none -> minutes approved
Check TD publication plans
Sebastian: updates can be found here, https://
… we plan to have normative feature freeze Feb 4, 2022
… 1 week left
… e.g., webhook example
… TestFest mid of March
… CR candidate end of March
… we also plan to start wide review process
… today I started the review for accessibility
… see https://
Daniel: TD 1.1 is meant to be new or can we refer to TD 1.0
Sebastian: Good question, not sure
Kaz: I suggest to use static HTML
Sebastian: Will do, for the time being we use ReSpec version
Kaz: Not sure about Daniel's point
… can add link to changes section
… and mention 1.1 is new, but we published 1.0
Sebastian: Okay, modify it accordingly
Sebastian: will do the same for other groups: Internationalisation, Privacy, ..
Review and label PRs
Sebastian: https://
ignore definitions that are not used
https://
Sebastian: 2 points cannot be solved easily..
… needs restructuring: own Privacy and Security section
… do we need to fix that for this version.. or later
Kaz: for working draft it is OK like it is
… can talk with webmaster and PLH
Sebastian: Suggest to merge this PR as is...
… and create a new issue
Kaz: note that the bigger question is what is required by the W3C Process and the Pubrules checker. say in the end
Daniel: labelled as warning, not error
make hctl:hasTarget a datatype property
Daniel: https://
Sebastian: still work in progress
Issues
TD generated from TM should allow custom @type
Sebastian: see https://
Sebastian: coming from discovery
… other @type's should be possible
Ege: I don't think this strict limit was intended
Cristiano: Think so too
Sebastian: I am OK to update the document
… we should add new text that explains that @type can be different
ThingModel composition and TD relation
Sebastian: https://
Sebastian: misunderstanding: extension vs composition
… w.r.t. scripting, do we need to load external TDs
… this is *not* the case
… different TDs
Daniel: suggest to rename "smart ventilation" to "smart room"
Cristiano: I think the *current* name makes sense
… links can be some kind of discovery
Jan: It reminds me also about discovery
Ege: for smart ventilator app ...I need 3 things to consume
… "room" example makes more sense to me
Sebastian: I understand your concerns
… avoiding confusion
TJ: in this example .... these are aspects ... ventilation and LED
Cristiano: aspects are about import to me.... this is about composition
… aspect, like temperature ... right keyword is "import"
Kaz: wonder why we use "ventilation"
… shall we use existing devices .. used in PlugFests
… combination can be room / house etc
Sebastian: We had this example in the PlugFest
… maybe renaming is a quick fix for the confusion
Kaz: Maybe we can add more models, like sensor and display
Kaz: I just thought something like the ECHONET use case, i.e., a smart home including an air conditioner, an LED, a sensor and a robot cleaner. We don't need use the ECHONET use case itself for this example but think about similar setting based on this use case here.
Jan: whole room might be to much
… composition mechanisms for TDs ... worth mentioning in actual TD section
… hided in ThingModel subsection
Sebastian: I was thinking along the same line
… maybe it could go to 10.4 derivation of TDs
Jan: TD composition is useful also outside of TMs
Sebastian: "item" term is in generic TD model already
Jan: great, I see
Sebastian: Will try to take care
Removing MD5
Sebastian: https://
Sebastian: We use MD5 in bearer....
… we should not list MD5
… MD5 message-digest algorithm is a cryptographically broken
Ege: McCools comment is wrong, I think
… it is just an example
Sebastian: Correct, you can still have it but we should not guide people to use it
… will comment in the issue
Kaz: Suggest to have discussion in security call
… and also in the phase of wide review
UriVariables can't be used for RootForms
Kaz: https://
Sebastian: talked about having uriVariables on root forms also
… I think we should allow it ... optionally
… any comments
Cristiano: trivial action is to add it to root level ... however .. it is kind of a patch
… seems like a workaround .. but should not forget the real issue: additional input parameters
… node-wot threats it as interaction options
… moving it to form is a breaking change
TJ: uriVariables in root ... uriVariables on interaction level still usable
Sebastian: uriVariables on top level.. make it possible to be re-used across many interactions
<cris> +1 :)
TJ: correct, interactions can overrule it
Ege: global definitions .. to be used in other affordances ?
Sebastian: Yes, this would be the benefit
… reminds me that we should allow schemaDefinitions not only for AdditionalExpectedResponse
WoT Binding
Ege: init to design an official BACnet Binding for Web of Things
… proposal for next protocol binding
… https://
… about having official BACnet binding
… BACnet is an important protocol for building automation and control systems
… we had Siemens Demo in PlugFest
… also in use-case document
… Michael Koster shared samples also
… Dogan from Siemens is also interested in this topic
… please comment in the issue
… will (should) result in new protocol binding document, like other Modbus etc
… the re-structuring of binding document makes it easier now
<sebastian> +1
Kaz: we worked with Takenaka building system .. should asked them too
Ege: agree
Kaz: will try to reach out to them
<Mizushima> +1
Ege: after we have the people that are interested we can start working on it
Cristiano: Sounds great that we have a new binding
[adjourned]