14:55:56 RRSAgent has joined #wot-td 14:55:56 logging to https://www.w3.org/2022/02/23-wot-td-irc 14:56:07 meeting: WoT-WG - TD-TF 14:56:14 present+ Kaz_Ashimura 14:56:46 ryuichi has joined #wot-td 15:01:26 present+ Ege_Korkan, Klaus_Hartke 15:03:54 present+ Sebastian_Kaebisch 15:03:59 dape has joined #wot-td 15:04:00 present+ Daniel_Peintner 15:04:56 preesnt+ Jan_Romann, Cristiano_Aguzzi 15:05:45 JKRhb has joined #wot-td 15:05:54 scribenick: JKRhb 15:06:01 topic: minutes 15:06:46 cris has joined #wot-td 15:06:52 ek: (goes over today's agenda and starts reviewing the minutes of the last meeting) 15:07:07 McCool has joined #wot-td 15:08:06 present+ Tomoaki_Mizushima, Michael_McCool 15:08:17 rrsagent, make log public 15:08:30 i|goes|-> https://www.w3.org/2022/02/16-wot-td-minutes.html Feb-16| 15:08:37 rrsagent, draft minutes 15:08:37 I have made the request to generate https://www.w3.org/2022/02/23-wot-td-minutes.html kaz 15:09:14 chair: Ege 15:09:48 s/preesnt+/present+/ 15:09:50 rrsagent, draft minutes 15:09:50 I have made the request to generate https://www.w3.org/2022/02/23-wot-td-minutes.html kaz 15:10:04 ... are there any objections? 15:10:25 There are none, kaz is asked to remove the draft status 15:10:43 topic: Issues 15:10:54 subtopic: Issue 1405 15:12:01 mm: I noticed that there are a number of IANA security considerations that might cause conflicts with our own Security and Privacy Considerations 15:12:55 ... as they are not part of normative but informative sections 15:13:22 i|noticed|-> https://github.com/w3c/wot-thing-description/issues/1405 Issue 1405 - Consolidate Security and Privacy Considerations (moving IANA security considerations)| 15:13:48 ... an option would be to move everything under Privacy and Secruity Considerations but then these secions have to be normative 15:14:25 ek: I don't have a problem with making the two sections normative, but then you would need to make the security guidelines normativ as well 15:15:50 mm: These do not need to be normative as they only discuss possible risks and mitigations in an informative way, 15:17:07 ... problem would be that we would add normative assertions, but we are feature frozen 15:17:31 ek: We are not feature frozen in that sense 15:17:56 mm: I will provide a PR for this issue for the next meeting 15:18:03 subtopic: Issue 1403 15:18:53 ek: Michael Lagally proposes renaming the event fields data and dataReponse field to message and messageResponse 15:19:27 ... in the discussion an alternative was adding an "event" field instead 15:19:41 q+ 15:19:45 q+ 15:20:01 q+ 15:20:13 ... I think event causes a duplication of terms but data is too ambigious. I made some suggestions 15:20:18 i|Michael Lagally|-> https://github.com/w3c/wot-thing-description/issues/1405 Issue 1405 - EventAffordance: rename data and dataResponse to message and messageResponse| 15:20:44 mm: Payload sounds good but we should postpone it to TD 2.0 15:21:16 sk: I agree with postponing, we need to discuss payload structure in general 15:21:19 q? 15:21:21 q+ 15:21:32 present+ Michael_Koster 15:21:34 ack seb 15:21:44 ... examples are Philipps Hue and LwM2M which have their own payload formats 15:22:02 ack d 15:22:35 ack dape 15:23:00 dp: We should only change the name with good reason 15:23:00 ack cr 15:23:37 q+ 15:23:54 ack k 15:23:58 ack m 15:24:06 Defines the data schema of the Event response messages sent be the consumer in a response to a data message. 15:24:34 (for the record, I am ok with "data" since it is under event.) 15:25:00 -> https://w3c.github.io/wot-thing-description/#eventaffordance 5.3.1.5 EventAffordance 15:25:19 kaz: There seems to be a typo in the description of the dataResponse field ("be" should be "by") 15:25:46 sk: I will create an issue for the typo 15:25:51 subtopic: Issue 1400 15:26:16 q+ 15:26:44 ack c 15:27:04 ek: Thomas raised the issue that in TMs affordances could be mandatory by default and marked as optional using "tm:optional" (instead of "tm:required") 15:27:30 ca: This approach follows JSON Schema, but our use is different 15:28:20 s/There seems/Agree we should defer this discussion to ver. 2.0 because we need to consider compatibility with ver. 1.0. BTW, it seems/ 15:28:52 q+ 15:29:06 ... how should incomplete affordances be handled? Should they just be empty? Would make more sense if everything was mandatory by default 15:29:07 q+ 15:29:55 mm: I agree that it makes more sense, use case is different TD is about defining data models 15:30:20 +1 15:30:27 ack m 15:30:29 ack s 15:30:47 ... behavior that everything becomes required if no tm:required is defined is not intuitive 15:32:49 sk: I agree that JSON Schema is a bit strange in this regard, but it is wildly used. 15:33:03 q? 15:34:15 ... my proposal would be that tm:required should stay but if it is not set then evething should be required by default 15:34:18 i|Thomas rai|-> https://github.com/w3c/wot-thing-description/issues/1403 Issue 1403 - ThingModels should not define "required" affordances in derived TDs, but "optional" ones| 15:34:34 rrsagent, make log public 15:34:35 ... SDF has a similar concept with sdfRequired 15:34:38 rrsagent, draft minutes 15:34:38 I have made the request to generate https://www.w3.org/2022/02/23-wot-td-minutes.html kaz 15:36:00 ek: I will contact the JSON Schema community to ask what the history behind their required property is 15:37:04 The meeting switches to discuss Binding Templates issues now 15:37:16 topic: Binding Templates Issues 15:37:26 subtopic: Issue 147 15:38:00 s/topic: Binding Templates Issues/topic: Binding Templates PRs/ 15:38:20 s/subtopic: Issue 147/subtopic: PR 147/ 15:38:44 ek: This PR simply adds links to the individual bindings to the repository README 15:38:51 topic: Binding Templates Issues 15:39:43 subtopic: Converting the Binding Teamplates to Registry Documents 15:40:35 ek: Registry documents are a new type of document that can contain normative content and are organized as tables 15:40:55 i|This PR|-> https://github.com/w3c/wot-binding-templates/pull/147 PR 147 - Adding links to readme| 15:40:59 ... they define process how additions can be submitted 15:41:11 s/ define process/ define a process/ 15:41:30 q+ 15:42:00 ... registries can also be a seperate document or a registry section 15:42:19 q+ 15:42:36 ... in this case registries are not subject to the W3C Patent Policy 15:43:12 kaz: Do you want to ask the group if we should proceed in this direction? 15:43:36 q+ 15:43:37 ek: I don't want to reach any solution today but present the option 15:44:10 kaz: This should be discussed primarily by the chairs/editors, but we can also discuss it here 15:44:32 i|-> https://www.w3.org/standards/types#registries Documents published at W3C - 3. W3C Registry Track 15:45:03 q+ 15:45:04 ca: I have a question regarding the embedded version of the Registry, can we include it the current Binding Templates? 15:45:51 ek: To be normative, they must be part of a normative document to be normative. They could be added to the TD document, though. 15:46:20 -> https://www.w3.org/2021/Process-20211102/#registries W3C Process - 6.5. The Registry Track 15:46:43 kaz: What is the intention to add a registry? 15:47:44 s/What is the intention to add a registry?/I'd like the whole WG to clarify our intention whether we want to use the registry track or not./ 15:48:42 q+ 15:49:44 sk: The intention would be to define protocol information in a formal way, each protocol has its own approach, with the registry approach we could express that we are aware of the variety of protocols and information can be incorporated via GitHub for example. 15:51:35 kaz: I completely understand which is why I suggested discussing this topic six months ago. 15:52:13 sk: You are right, we weren't aware of this type of document before you've mentioned it. We should discuss it in the editor's call 15:52:43 ek: Is it possible to have a registry section in a note document, kaz? 15:53:20 kaz: That is complicated, it would be better to split it into two parts and use the registry track for the registry document 15:53:45 ek: This registry track is similar to the way registrations work which was surprising to me 15:54:15 ack k 15:54:18 ack c 15:54:22 ... there also has to be a policy for changes which makes it more transparent for external contributors 15:55:30 ca: I agree with the direction. However, if the registry is not normative, does it solve our problem that we want to refer to it from the main TD document? 15:55:40 q+ 15:55:49 (sorry, I need to drop...) 15:56:01 sk: We should take a look at the approach taken by the DID working group, it should be solvable 15:58:16 kaz: One more comment: The approach taken by DID is possibly not the best solution, we should use the latest version defined by the W3C process. We now have three tracks and we should discuss which is fitting best for the Binding Templates 15:58:45 sk: Would be cool if you could help us and make a suggestion, kaz 15:59:15 ack k 15:59:15 kaz: The group as a whole should make a decision what we want to do with the Binding Templates 15:59:31 subtopic: TD Issue #1395 15:59:37 s/make a decision/clarify/ 16:00:11 s/Templates/Templates, and the Chairs and the Editors should discuss the procedure to follow based on that./ 16:00:30 ek: There have been changes in OpenAPI 3.0 that make Security Schemes protocol specific 16:00:39 s/best solution/best solution for us/ 16:00:47 mm: The name and in issue is related to this 16:01:02 ... we need to defer this to TD 2.0 in order to not break things 16:01:53 s/, we should use the latest version defined by the W3C process/. We should think about what we want to do and then which track we should use based on the latest version of the W3C Process./ 16:02:21 ... name and in are not permitted by the RFCs, we dicussed adding a value of "auto" to solve this" 16:02:55 s/three tracks/three tracks (REC Track, Note Track and Registry Track)/ 16:03:27 ek: I don't know if it is the best way the solve this, we could discuss defining SecuritySchemes in protocol documents 16:04:40 (ok, now I do have to drop) 16:04:41 i|There have been|-> https://github.com/w3c/wot-thing-description/issues/1395 wot-thing-description Issue 1395 - Security descriptions alignment with OpenAPI 3.0| 16:04:42 mm: Using auto is a workaround, an additional assertion should be added to handle this issue for now. We have to deal with it in TD 2.0. I will create a PR for the issue at hand which should be able to be merged next week 16:05:20 subtopic: BACnet binding 16:06:00 jb: (introduces himself) 16:06:17 q+ 16:06:25 ack s 16:06:39 present+ Joel_Bender 16:07:05 ... I've been invited by Michael Koster to discuss how BacNET could be integrated into the Web of Things 16:07:36 s/BacNET/BACnet/ 16:08:41 jb: How much does the group know about the BACnet protocol? 16:08:52 new to me :) 16:09:06 -> https://www.w3.org/Consortium/Patent-Policy-20200915/ W3C Patent Policy 16:09:19 sk: I work at Siemens and am therefore familar with it, but I think the group in general is not 16:10:38 (kaz reminds Joel of the W3C Patent Policy to make sure) 16:13:00 jb: BACnet is a peer to peer protocol, standardized by Ashray, used by many different families of objects (lights, elevators, ...). Mostly based on reading and writing properties. There seems to be a natural fit with WoT Things from my understanding 16:14:41 ... there is a part of the BACnet standard that concerns Web based Things, object identifiers can be used to tie BACnet objects to the Web of Things (?) 16:15:31 ek: (shows the basic requirements for a protocol binding based on existing Binding Documents) 16:17:26 ... for modbus, for example, there is a modbus:function. Protocol Bindings are independent of other protocols, Modbus for example is unaware of HTTP, but a consumer could re-expose a modbus Thing using HTTP 16:17:59 -> https://w3c.github.io/wot-binding-templates/bindings/protocols/modbus/ Ege shows the MODBUS binding template draft as an example 16:19:07 ... the requirement would be to define a vocabulary (e. g. for interaction affordances) and an ontology to autogenerate the tables in the document 16:19:36 i|the requirement|-> https://w3c.github.io/wot-binding-templates/ontology/modbus also the Ontology file 16:19:57 q+ 16:20:02 ack k 16:20:05 ... Modbus is probably the best binding document at the moment 16:20:29 s/Ashray/ASHRAE/ 16:21:09 mj: there are two examples in the issue 16:21:39 -> https://github.com/w3c/wot-binding-templates/issues/144 wot-binding-templates Issue 144 - BACnet Binding for Web of Things 16:21:55 jb: There are some things that need to be fixed in the example (for example, we refer to things by identifier and not by name) but it is pretty straightforward 16:22:05 i|There|-> https://github.com/mjkoster/ODM-Examples/blob/master/protocol-descriptor/observable-flow-protocol-descriptor-bacv-223p.td.json example 1| 16:22:20 i|There|-> https://github.com/mjkoster/ODM-Examples/blob/master/protocol-descriptor/observable-flow-protocol-descriptor-bacnet-223p.td.json example 2| 16:23:23 sk: Key is to work together on an ontology to have everything that is needed by BACnet. If you already have an ontology then it should be very easy to create a binding 16:25:06 mj: There is also the need to define, e. g. data schemas 16:25:56 jb: There is a process to define data models based on submissions by manufacturers, which are translated into RDF by a data modelling working group 16:26:29 q? 16:27:06 ca: There are some technical difficulties when writing these documents, as they are partially autogenerated by a .ttl file 16:27:29 ... maybe it would be easier if you submitted a document and cleaned it up 16:28:18 -> https://github.com/w3c/wot-binding-templates/tree/main/bindings/protocols/modbus MODBUS area for Binding Templates 16:28:52 jb: I think I could also clone the repository and use the MODBUS document as a basis 16:30:11 ... which files are autogenerated? 16:30:51 ca: Only the index.html file, which is created by a script which probably needs to be updated as the current document directories are hardcoded 16:31:18 ... we can take care of these technical details, though 16:32:04 sk: Do you think we could work together on this? We could work in the W3C to start a blueprint 16:32:30 jb: Sure, I would start with creating a fork of the Binding Templates repository 16:33:20 ... I am not an invited expert/part of a member organization (yet), though 16:33:52 kaz: Making him an invited expert would not be necessary, though 16:34:32 jb: Michael could make a contribution in this case 16:35:07 ... joining W3C should not be an issue, however (?) 16:36:32 s/Making him an invited expert would not be necessary, though/If we need concrete contribution to our specification, e.g., providing concrete text for our spec, we should ask him to become an Invited Expert, but if we can continue the discussion based on BACnet's public resources and would invite Joel like today's call, we don't need to make him an Invited Expert./ 16:37:48 sk: (gives more background regarding WoT testing and plugfests, especially when it comes to working with the ASHRAE community) 16:38:08 jb: Would such a plugfest be BACnet specific? 16:38:13 s/Michael could/Michael Koster could/ 16:38:34 sk: A specific BACnet would be possible 16:38:56 s/specific BACnet/specific BACnet event/ 16:39:16 q+ 16:39:46 ... next event is planned for march, focussing on TD 1.1 as it is required for the Recommendation status 16:40:10 -> https://github.com/w3c/wot-testing/tree/main/events/2022.03.Online Next Plugfest 16:40:15 ... the next one, in summer, could take BACnet and a possible first draft into account 16:40:29 s/... the/sk: the/ 16:40:37 jb: Which protocols do you focus on? 16:41:19 sk: It depends, we discuss it before the plugfests and can discuss that we want to focus on a specific protocol for example 16:41:41 q? 16:43:05 ek: (shows the structure on the wot-testing repository) 16:43:26 s/on the/of the/ 16:43:32 -> https://w3c.github.io/wot-usecases/#echonet-use-case ECHONET use cases 16:44:01 kaz: Before the actual plugfest, we might want to discuss concrete use cases first, as we did with echonet 16:44:09 s/echonet/ECHONET/ 16:44:17 https://w3c.github.io/wot-usecases/#smart-building 16:45:38 https://w3c.github.io/wot-usecases/#connected-building-energy-efficiency 16:45:43 kaz: Takenaka, a large Japanese construction company, has started using WoT for their use cases, for example 16:46:05 s/http/-> http/ 16:46:07 ek: (Shows the WoT use cases document) 16:46:32 s/document)/document where new use cases could be included)/ 16:46:34 s/#smart-building/#smart-building use case by Sebastian/ 16:47:34 subtopic: Binding Templates Issue 49 16:47:36 s/#connected-building-energy-efficiency/#connected-building-energy-efficiency another use case by Farshid| 16:47:49 s/Farshid|/Farshid/ 16:48:07 s|https://w3c.github.io/wot-usecases/#s|-> https://w3c.github.io/wot-usecases/#s| 16:49:31 -> https://github.com/w3c/wot-binding-templates/issues/49 wot-binding-templates Issue 49 - CoAP Blockwise Indicator 16:54:21 kh: In HTTP you can define headers, in CoAP, however, you need to understand the context of options. In the discussion in the issue, we had the idea of rather describing the CoAP related features that are offered by a Thing and not the raw option values 16:55:57 q+ 16:56:02 ack k 16:56:27 ... for some options like hop limit you could still use a generic option, but otherwise the Consumer would need to know the context of the option 16:57:39 ... my favorite would be to only use featurs and only use optionName: optionValue as a fallback 16:57:50 ek: In MODBUS, you only have features at the moment 16:58:35 kh: In BACnet you could also have a similar approach 16:59:11 sk: Would you propose removing optionName, optionValue completely? 16:59:42 kh: I would prefer removing them completely, but we discussed this some time ago and decided against it 17:00:33 mk: I would also go for more of a feature approach 17:02:03 q+ 17:03:03 kh: One question I have, we currently have the binding document and the RDF document, which was very helpful in the case of HTTP. This could not be used for CoAP so well if we changed the binding document approach for CoAP 17:03:31 q? 17:03:40 ek: The RDF documents for CoAP and MQTT are currently very generic 17:04:22 present+ Joel_Blender 17:04:32 rrsagent, draft minutes 17:04:32 I have made the request to generate https://www.w3.org/2022/02/23-wot-td-minutes.html kaz 17:04:48 q+ 17:04:50 ack c 17:05:15 ack s 17:05:56 kh: Having an RDF document would not be a requirement for TD then? For BACnet we woud need a URI scheme then 17:08:10 ack k 17:09:09 kaz: (jumps in and suggests we continue the discussion next week since we're already out of time and this topic is a big topic requires longer discussion.) 17:09:12 [adjourned] 17:09:17 rrsagent, draft minutes 17:09:17 I have made the request to generate https://www.w3.org/2022/02/23-wot-td-minutes.html kaz 17:09:34 i/jumps/scribenick: kaz/ 17:09:35 rrsagent, draft minutes 17:09:35 I have made the request to generate https://www.w3.org/2022/02/23-wot-td-minutes.html kaz