14:58:51 <RRSAgent> RRSAgent has joined #wot-td
14:58:51 <RRSAgent> logging to https://www.w3.org/2022/01/26-wot-td-irc
14:58:56 <kaz> meeting: WoT-WG - TD-TF
14:59:31 <kaz> agenda: https://www.w3.org/WoT/IG/wiki/WG_WoT_Thing_Description_WebConf#Jan_26.2C_2022
15:00:36 <thjaeckle> thjaeckle has joined #wot-td
15:01:16 <cris> cris has joined #wot-td
15:01:57 <JKRhb> JKRhb has joined #wot-td
15:05:01 <dape> dape has joined #wot-td
15:05:46 <kaz> present+ Kaz_Ashimura, Cristiano_Aguzzi, Daniel_Peintner, Jan_Romann, Sebastian_Kaebisch, Thomas_Jaeckle
15:05:51 <kaz> chair: Sebastian
15:07:44 <kaz> present+ Michael_Lagally
15:07:50 <kaz> scribenick: dape
15:07:52 <dape> scribenick: dape
15:08:08 <dape> TOPIC: Previous minutes
15:08:24 <dape> ... Jan 19 -> https://www.w3.org/2022/01/19-wot-td-minutes.html
15:08:47 <dape> TOPIC: Continue discussion about new eventing approach
15:09:28 <dape> ML: I added example to issue 1323
15:09:59 <dape> ... we have many use-cases  for push notifications in use-cases document
15:10:12 <dape> ... e.g., in retail, AllStopButton
15:10:34 <dape> ... keeping TCP connection open drains battery
15:11:26 <dape> ... https://github.com/w3c/wot-thing-description/issues/1323#issuecomment-1022288921
15:11:45 <dape> ... fire alarm button
15:12:02 <dape> ... fire alarm observer
15:12:07 <dape> ... flow
15:12:18 <dape> ... 1. FireAlarmObserver subscribes to FireAlarmButton event affordance, registers itself as a listener.
15:12:35 <sebastian> q+
15:12:52 <dape> ... 2. Human user pushes the button, the FireAlarmListener gets notified, this triggers multiple actions, such as calling the police, sending a fire engine, ...
15:13:07 <dape> ... 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
15:14:05 <dape> ... <walks over TD snippets>
15:14:37 <dape> .. in case of alarm button true/false
15:14:59 <dape> ... dataResponse ... operator name
15:15:21 <dape> ... acknowledge in dataResponse
15:15:23 <dape> q?
15:15:58 <sebastian> ack s
15:16:11 <kaz> i/Continue discussion about/(approved)/
15:16:23 <dape> SK: 2 actors, FireAlarmListener vs FireAlarmObserver
15:16:51 <dape> ML: inconsistency .. let's call it listener
15:16:58 <kaz> s/... Jan/Jan/
15:17:10 <dape> q?
15:17:31 <kaz> i|I added example to|-> https://github.com/w3c/wot-thing-description/issues/1323 Issue 1323 - Missing event/notification affordance or operation|
15:17:41 <dape> ML: not only webhoock, more a general thing
15:17:42 <kaz> rrsagent, make log public
15:17:47 <kaz> rrsagent, draft minutes
15:17:47 <RRSAgent> I have made the request to generate https://www.w3.org/2022/01/26-wot-td-minutes.html kaz
15:17:59 <mlagally___> mlagally___ has joined #wot-td
15:18:04 <dape> SK: dataResponse is the only *new* thing, correct?
15:18:06 <dape> ML: Yes
15:18:32 <dape> ... we can still think about renaming
15:19:17 <sebastian> q+
15:19:17 <dape> ... we have form with "op": "notify"
15:19:35 <kaz> present+ Tomoaki_Mizushima, Michael_Koster
15:20:16 <dape> SK: the notify form confuses me
15:20:29 <dape> ... not sure about 2nd TD, who is consuming this TD
15:20:38 <dape> ML: It describes listener interface
15:21:16 <cris> q+
15:21:22 <sebastian> ack s
15:21:30 <dape> ... in the simple case it is just an URL
15:21:39 <dape> CA: about 2nd TD
15:21:48 <dape> ... I am worried about semantics
15:22:05 <dape> ... we are not creating events ... I am waiting for this event
15:22:49 <dape> ML: Similar to method signature
15:23:10 <dape> CA: we are defining a *magic* signature
15:23:39 <dape> ... we describe event  as source ...but this describes source
15:23:43 <dape> ... 2 different things
15:24:14 <dape> ML: in my thinking "event" is a contract
15:24:23 <dape> q+
15:24:32 <sebastian> ack c
15:24:56 <dape> ML: Chain of buttons ...
15:25:09 <kaz> ack c
15:25:11 <kaz> ack d
15:25:43 <kaz> regrets+ McCool
15:26:27 <dape> DP: not sure how a TD consumer know whether it expects a event or waits for event
15:26:36 <dape> ML: Not sure about syntax
15:26:50 <dape> ... assumption, everything can be described with TD
15:26:54 <dape> q?
15:27:27 <dape> ... we should be able to describe consumers
15:27:35 <dape> ... thing to thing contract
15:27:48 <dape> ML: I need to go
15:27:49 <ryuichi> ryuichi has joined #wot-td
15:28:09 <dape> ... please take a look at the example ... and provide comments
15:28:23 <dape> SK: I understand first TD
15:28:32 <dape> ... I still struggle with 2nd TD
15:28:46 <dape> ... it describes a consumer
15:29:00 <dape> ... information for implementation
15:29:24 <dape> ML: Try to join next call again
15:29:41 <dape> SK: Thanks!
15:29:45 <cris> q+
15:29:55 <dape> <MLagally left>
15:30:13 <dape> SK: I understand the dataResponse container
15:30:44 <dape> ... on the consumer side with the event .. I am not sure
15:30:47 <dape> q?
15:31:17 <dape> CA: Good example to be discussed in a call
15:31:33 <mjk_> mjk_ has joined #wot-td
15:31:37 <dape> ... does it make sense to have an extra ordinary slot/call
15:31:51 <kaz> q+
15:31:54 <mjk_> q?
15:31:56 <kaz> ack c
15:32:02 <dape> SK: I agree, on the other I have difficulties to find a slot
15:32:56 <dape> Kaz: Sebastian, maybe having a call with MLagally ?
15:33:15 <kaz> s/, on the other/, on the other hand, /
15:33:19 <dape> SK: Possible, but then someone needs to report to the community
15:33:34 <dape> CA: OR lets try again next week to make progress
15:34:08 <mjk_> q+
15:34:14 <kaz> ack k
15:34:25 <dape> Kaz. We just need someone (Sebastian?),  to understand the issue better.. that would help
15:35:12 <dape> MK: The confusion is about data being pushed .. and the direction
15:35:27 <dape> ... we are looking for a different pattern
15:35:52 <dape> ... I think MLagally wants to see the address .. where data is pushed to
15:36:07 <dape> ... maybe there is a different solution
15:36:08 <mjk_> qck mjk
15:36:11 <mjk_> ack mjk
15:36:22 <kaz> s/We just need someone (Sebastian?),  to understand the issue better.. that would help/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./
15:36:48 <dape> SK: address should be shared in subscription container
15:37:22 <dape> SK: Still very unclear to me
15:37:23 <dape> q?
15:37:23 <sebastian> q?
15:38:00 <dape> SK: Let's try to have a meeting with MLagally
15:39:02 <dape> TOPIC: Previous minutes (re-started)
15:39:15 <dape> ... Jan 19 -> https://www.w3.org/2022/01/19-wot-td-minutes.html
15:39:40 <kaz> s/(approved)/(later)/
15:39:51 <kaz> s/... Jan/Jan/
15:40:10 <dape> <SK walks through minutes>
15:40:40 <dape> SK: w.r.t. changelog, Taki can work on that topic
15:41:43 <dape> SK: any comments/concerns?
15:41:52 <dape> ... none -> minutes approved
15:42:08 <dape> TOPIC: Check TD publication plans
15:42:26 <dape> SK: updates can be found here, https://github.com/w3c/wot/blob/main/charters/wg-2021-extension-plan.md
15:42:57 <dape> ... we plan to have normative feature freeze Feb 4, 2022
15:43:08 <dape> ... 1 week left
15:43:42 <dape> ... e.g., webhook example
15:43:55 <dape> ...TestFest mid of March
15:44:12 <dape> ... CR candidate end of March
15:44:39 <dape> ... we also plan to start wide review process
15:44:59 <dape> ... today I started the review for accessibility
15:45:13 <dape> ... see https://github.com/w3c/a11y-request/issues/21
15:45:51 <dape> q+
15:46:35 <dape> DP: TD 1.1 is meant to be new or can we refer to TD 1.0
15:46:38 <dape> ack dape
15:46:46 <dape> SK: Good question, not sure
15:46:56 <kaz> q+
15:47:43 <dape> Kaz: I suggest to use static HTML
15:48:37 <dape> SK: Will do, for the time being we use ReSpec version
15:48:50 <dape> Kaz: Not sure about Daniels point
15:49:59 <dape> ... can add link to changes section
15:51:39 <dape> ... and mention 1.1 is new, but we published 1.0
15:54:17 <dape> SK: Okay, modify it accordingly
15:55:02 <dape> SK: will do the same for other groups: Internationalisation, Privacy, ..
15:55:41 <dape> TOPIC: Review and label PRs
15:55:46 <dape> ... https://github.com/w3c/wot-thing-description/pulls
15:55:51 <kaz> s/Daniels/Daniel's/
15:56:16 <dape> SUBTOPIC:  ignore definitions that are not used
15:56:20 <dape> -> https://github.com/w3c/wot-thing-description/pull/1359
15:56:31 <dape> SK: 2 points cannot be solved easily..
15:56:57 <dape> ... needs restructuring: own Privacy and Security section
15:57:34 <dape> ...do we need to fix that for this version.. or later
15:58:04 <kaz> q+
15:59:08 <dape> Kaz: for working draft it is OK like it is
15:59:16 <dape> ... can talk with webmaster and PLH
15:59:33 <dape> SK: Suggest to merge this PR as is...
15:59:48 <dape> ... and create a new issue
16:01:57 <dape> Kaz: not sure what pub-checker will say in  the end
16:02:26 <dape> DP: labelled as warning, not error
16:02:56 <kaz> s/not sure what pub-checker will/note that the bigger question is what is required by the W3C Process and the Pubrules checker./
16:04:36 <dape> SUBTOPIC: make hctl:hasTarget a datatype property
16:04:43 <dape> ... https://github.com/w3c/wot-thing-description/pull/1361
16:04:52 <dape> SK: still work in progress
16:05:14 <dape> TOPIC: Issues
16:05:26 <dape> SUBTOPIC: TD generated from TM should allow custom @type
16:05:34 <dape> ... see https://github.com/w3c/wot-thing-description/issues/1351
16:05:41 <Ege> q+
16:05:45 <kaz> ack k
16:05:51 <dape> SK: coming from discovery
16:06:16 <dape> .. other @type's should be possible
16:06:51 <dape> Ege: I don't think this strict limit was intended
16:06:57 <dape> CA: Think so too
16:08:16 <dape> SK: I am OK to update the document
16:08:49 <dape> ... we should add new text that explains that @type can be different
16:09:04 <JKRhb> q+
16:09:22 <JKRhb> q-
16:09:49 <dape> SUBTOPIC: ThingModel composition and TD relation
16:09:55 <dape> .. https://github.com/w3c/wot-thing-description/issues/1354
16:10:15 <dape> SK: misunderstanding: extension vs composition
16:11:49 <dape> q+
16:12:40 <cris> q+
16:12:47 <dape> ... w.r.t. scripting, do we need to load external TDs
16:13:00 <dape> ... this is *not* the case
16:14:15 <dape> ... different TDs
16:14:31 <Ege> ack e
16:15:44 <dape> ack dape
16:16:12 <dape> DP: suggest to rename "smart ventilation" to "smart room"
16:16:37 <dape> CA: I think the *current* name makes sense
16:16:58 <JKRhb> q+
16:17:03 <dape> ... links can be some kind of discovery
16:17:03 <Ege> q+
16:17:04 <cris> ack c
16:17:51 <dape> Jan: It reminds me also about discovery
16:18:09 <JKRhb> q-
16:18:11 <JKRhb> q+
16:18:29 <dape> Ege: for smart ventilator app ...I need 3 things to consume
16:18:41 <dape> ... "room" example makes more sense to me
16:19:04 <kaz> q+
16:19:09 <kaz> ack e
16:19:20 <dape> SK: I understand your concerns
16:19:28 <dape> ... avoiding confusion
16:21:14 <kaz> ack jk
16:21:18 <dape> TJ: in this example .... these are aspects ... ventilation and LEd
16:21:35 <kaz> s/LEd/LED/
16:22:39 <dape> CA: aspects are about import to me.... this is about composition
16:23:07 <dape> ... aspect, like temperature ... right keyword is "import"
16:23:08 <dape> q?
16:23:32 <dape> Kaz: wonder why we use "ventilation"
16:23:50 <dape> ... shall we use existing devices .. used in PlugFests
16:24:05 <dape> ... combination can be room / house etc
16:24:08 <dape> q?
16:24:12 <dape> ack kaz
16:24:28 <dape> SK: We had this example in the PlugFest
16:25:55 <dape> ... maybe renaming is a quick fix for the confusion
16:26:03 <kaz> q+
16:27:34 <dape> Kaz: Maybe we can add more models, like sensor
16:27:48 <kaz> s/sensor/sensor and display/
16:27:49 <JKRhb> q+
16:27:54 <kaz> ack k
16:28:40 <kaz> ack k
16:29:00 <dape> Jan: whole room might be to much
16:29:34 <dape> ... composition mechanisms for TDs ... worth mentioning in actual TD section
16:29:50 <dape> ... hided in ThingModel subsection
16:30:09 <kaz> i/Jan:/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./
16:30:19 <kaz> i/I just/scribenick: kaz/
16:30:29 <kaz> i/Jan:/scribenick: dape/
16:31:04 <dape> SK: I was thinking along the same line
16:31:24 <kaz> s/cleaner./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./
16:31:44 <dape> ... maybe it could go to 10.4 derivation of TDs
16:32:34 <dape> Jan: TD composition is useful also outside  of TMs
16:33:58 <dape> SK: "item" term is in generic TD model already
16:34:35 <dape> Jan: great, I see
16:34:45 <sebastian> q?
16:34:48 <dape> q?
16:34:53 <JKRhb> ack jk
16:35:13 <dape> SK: Will try to take care
16:35:59 <dape> SUBTOPIC: Removing MD5
16:36:06 <dape> ... https://github.com/w3c/wot-thing-description/issues/1362
16:36:30 <kaz> rrsagent, make log public
16:36:32 <dape> SK: We use MD5 in bearer....
16:36:34 <kaz> rrsagent, draft minutes
16:36:34 <RRSAgent> I have made the request to generate https://www.w3.org/2022/01/26-wot-td-minutes.html kaz
16:36:45 <dape> ... we should not list MD5
16:36:59 <dape> ... MD5 message-digest algorithm is a cryptographically broken
16:37:13 <Ege> q+
16:37:34 <dape> Ege: McCools comment is wrong, I think
16:37:40 <dape> ... it is just an example
16:38:27 <Ege> ack e
16:38:28 <dape> SK: Correct, you can still have it but we should not guide people to use it
16:38:48 <dape> ... will comment in the issue
16:39:35 <kaz> q+
16:40:28 <dape> Kaz: Suggest to have discussion in security call
16:40:39 <kaz> ack k
16:40:42 <dape> ... and also in the phase of wide review
16:41:36 <dape> SUBTOPIC: UriVariables can't be used for RootForms
16:41:42 <dape> ... https://github.com/w3c/wot-thing-description/issues/1357
16:42:02 <dape> SK: talked about having uriVariables on root forms also
16:42:56 <dape> ... I think we should allow it ... optionally
16:43:00 <dape> ... any comments
16:43:48 <dape> CA: trivial action is to add it to root level ... however .. it is kind of a patch
16:44:58 <dape> ... seems like a workaround .. but should not forget the real issue: additional input parameters
16:45:24 <dape> ... node-wot threats it as interaction options
16:45:46 <dape> ... moving it to form is a breaking change
16:47:34 <thjaeckle> q+
16:48:06 <kaz> ack th
16:48:39 <dape> TJ: uriVariables in root ... uriVariables  on interaction level still usable
16:49:59 <dape> SK: uriVariables  on top level.. make it possible to be re-used across many interactions
16:50:19 <cris> +1 :)
16:50:56 <dape> TJ: correct, interactions can overrule it
16:51:15 <dape> Ege: global definitions .. to be used in other affordances ?
16:51:27 <dape> SK: Yes,  this would be the benefit
16:53:23 <dape> .. reminds me that we should allow schemaDefinitions not only for AdditionalExpectedResponse
16:54:42 <dape> TOPIC: WoT Binding
16:55:00 <dape> Ege: init to design an official BACnet Binding for Web of Things
16:55:13 <dape> ... proposal for next protocol binding
16:55:20 <dape> ... https://github.com/w3c/wot-binding-templates/issues/144
16:56:06 <kaz> q+
16:56:22 <dape> ... about having official BACnet binding
16:56:38 <dape> ...  BACnet is an important protocol for building automation and control systems
16:56:52 <dape> ... we had Siemens Demo in PlugFest
16:57:17 <dape> ... also in use-case document
16:57:36 <dape> ... Michael Koster shared samples also
16:57:52 <dape> ... Dogan from Siemens is also interested in this topic
16:58:02 <dape> ... please comment in the issue
16:58:27 <dape> ... will (should) result in new protocol binding document, like other Modbus etc
16:58:56 <dape> ... the re-structuring of binding document makes it easier now
16:59:17 <sebastian> +1
16:59:42 <dape> Kaz: we worked with Takanaka building system .. should asked them too
16:59:45 <dape> Ege: agree
17:00:03 <dape> s/Takanaka/Takenaka
17:00:33 <dape> Kaz: will try to reach out to them
17:00:52 <Mizushima> +1
17:01:20 <Ege> q?
17:01:24 <kaz> ack k
17:02:15 <dape> Ege: after we have the people that are interested we can start working on it
17:02:25 <dape> CA: Sounds great that we have a new binding
17:03:23 <dape> [adjourned]
17:03:35 <kaz> rrsagent, draft minutes
17:03:35 <RRSAgent> I have made the request to generate https://www.w3.org/2022/01/26-wot-td-minutes.html kaz
18:15:17 <sebastian> sebastian has joined #wot-td
18:15:46 <sebastia_> sebastia_ has joined #wot-td
19:27:32 <Zakim> Zakim has left #wot-td