12:00:42 RRSAgent has joined #wot-script 12:00:46 logging to https://www.w3.org/2024/02/19-wot-script-irc 12:01:54 cris_ has joined #wot-script 12:02:13 I'm tring to join the call but I can't access the event link 12:02:23 it seems that the w3c auth server is down 12:05:15 meeting: WoT Scripting API 12:06:00 chair: Cristiano 12:06:05 Mizushima has joined #wot-script 12:06:49 present+ Kaz_Ashimura, Crisitno_Aguzzi, Zoltan_Kis, Jan_Romann, Tomoaki_Mizushima 12:08:48 scribe: zkis 12:09:22 JKRhb has joined #wot-script 12:10:07 agenda: https://www.w3.org/WoT/IG/wiki/WG_WoT_Scripting_API_WebConf#February_19%2C_2024 12:10:44 topic: Minutes 12:10:53 Minutes approved 12:10:53 -> https://www.w3.org/2024/02/05-wot-script-minutes.html Feb-5 12:11:07 Topic: quick updates 12:11:20 CA: we have biweekly calls now 12:11:26 Topic: PRs 12:11:40 Subtopic: PR 534 12:11:43 https://github.com/w3c/wot-scripting-api/pull/534 12:12:16 s|https://github.com/w3c/wot-scripting-api/pull/534|-> https://github.com/w3c/wot-scripting-api/pull/534 PR 534 - fix(InteractionOutput): don't require schema.type in value function| 12:13:38 CA: started in a node-wot problem with schema 12:13:55 q+ 12:14:12 CA: implementation feedback pushed to change the spec 12:14:16 q+ 12:14:36 ZK: we should have a tracking issue for the case when implementations are asking spec changes 12:15:53 CA: a PR also counts as an issue 12:16:08 ZK: I am referring to normal WG practice here 12:16:27 ack z 12:17:46 JR: based on relevant comment we can make a new issue 12:18:46 CA: created issue 546 12:18:49 https://github.com/w3c/wot-scripting-api/issues/546 12:18:56 ack kaz 12:19:17 KA: this discussion contains several issues 12:19:25 ... one is implementation feedback from node-wot 12:19:37 ... another is a restriction by the schema mechanism 12:19:52 ... we should think about those separately 12:20:27 ... the spec should describe what is required by implementations, not to describe the schema mechanism 12:20:48 dape has joined #wot-script 12:21:01 ... the spec should think about the necessary dependencies, also towards other implementations 12:21:27 ... what kind of data do they handle, what structure is preferred, array or object, what is preferred when, etc. 12:21:47 ... we could start with use cases listed by Jan, but we can also ask for more use cases 12:22:04 q+ to WebThings 12:22:12 CA: in general I agree with gathering more feedback 12:22:48 ... this problem persists also in the libraries, we need to handle it somewhere 12:23:26 DP: maybe it's good to get other developer feedback, e.g. Mozilla WebThings, to see how do they handle similar issues 12:23:38 ... and whether is there anything to be fixed in the TD task force 12:23:42 KA: agreed 12:24:00 ack dape 12:24:00 dape, you wanted to WebThings 12:24:12 CA: IME they don't have this problem, since they use it only for validation, while node-wot is also using it for bindings 12:24:28 ... but we can ask nevertheless 12:25:00 DP: we have a use case from discovery also coming up and we also need to cover that 12:25:07 present+ Daniel_Peintner 12:25:15 CA: right, this is also needed for solving that 12:25:26 CA: we can do an iterative approach 12:26:01 ... for now we can keep the issue open, but agree in a short term resolution until further feedback comes 12:27:56 CA: explaining the details of a short term proposal 12:28:40 q+ 12:30:07 ack JKRhb 12:30:29 JR: I also tried to extend the algorithm to check the data schema 12:31:40 JR: for the valid schema, needs some discussion 12:31:58 ... we might need stricter definitions for validity 12:32:42 ZK: is it an application level issue, or implementation level? 12:32:54 CA: I would ask that as a generic question from the WG 12:33:04 ... let's separate the concerns for Scripting 12:33:24 ... we don't need very strict rules IMHO, the TD should spec that 12:33:28 -> https://pr-preview.s3.amazonaws.com/JKRhb/wot-scripting-api/pull/534.html#the-check-data-schema-algorithm PR 534 Preview - 7.2.3 The check data schema algorithm 12:33:43 CA: we need to be able to infer the type from the application 12:33:47 q+ 12:35:07 q+ 12:35:12 q+ 12:35:37 ZK: we should spec data formats in web specs in general 12:35:49 CA: we can defer to the TD TF 12:35:57 q+ 12:36:16 KA: agree, and we should look into some more implementation approaches and other specs 12:36:36 q? 12:36:40 ack zk 12:36:43 ack kaz 12:37:02 KA: it might be a good topic for the CG to have a study and tutorial 12:37:10 CA: yes, we can ignite a discussion there 12:38:26 DP: we have similar solution in value function and input data, but we don't spec the full JSON schema 12:39:00 DP: we could say that the value function may be used in this or that case, otherwise use ArrayBuffer 12:39:13 CA: right, we should update the spec 12:39:23 ack dape 12:40:49 JR: there's some example to call value() then catch exception 12:41:53 ZK: yes, these belong to explainers 12:42:15 i/and other specs/and other specs. like Daniel mentioned, WebThing is one possibility, and ECHONET should ne another possibility./ 12:42:38 JR: we wanted to expand the data schema algorithm 12:45:11 ... (brainstorming about the algorithm) 12:46:14 CA: some small updates would be needed, mostly we are fine 12:46:40 CA: Jan, please check the steps and provide a PR 12:46:43 JR: ok 12:47:07 q+ 12:47:07 Topic: Issues 12:47:14 ack JKRhb 12:47:51 KA: spec doesn't have to replicate the schema mechanism 12:48:10 ... we should start with what is needed for the spec, and what can be applied from external algorithms 12:48:27 ... if those are not enough, then we can add local algorithm steps 12:48:50 ... is the current schema mechanism good enough? 12:49:08 CA: yes, it is, but doesn't explicitly cover all permutations of the schema in our spec 12:49:26 ... we validate the schema, plus we spec what the runtime should return 12:49:55 CA: no reason to change, just to complete 12:50:22 KA: the base question is that validation by schema is different than by the spec 12:50:38 ... so we need to think about the schema and data processing separately 12:50:46 CA: maybe we should indeed split 12:51:02 q+ 12:51:09 ack kaz 12:52:28 KA: the current spec should be fine, but e.g. the EchoNet people were talking about grouping data, users etc, so the use cases can get complicated, so we might want nicer mechanisms for validation and data handling 12:53:27 DP: in ideal case, we should also split not only the spec prose, but also use helper methods to check e.g. if the value() function would work 12:53:38 ... without the need to catch exceptions 12:54:28 q? 12:54:31 ack dape 12:54:58 CA: opened issue 547 12:55:00 https://github.com/w3c/wot-scripting-api/issues/547 12:55:42 s|https://github.com/w3c/wot-scripting-api/issues/547|-> https://github.com/w3c/wot-scripting-api/issues/547 new related Issue 547 - Refactor: separate schema validation for data processing validation| 12:55:54 CA: we need to open or map issues at TD spec 12:56:31 CA: we should split the list of issue for triaging 12:57:14 q+ 12:58:36 DP: I can handle the triaging 12:59:02 KA: we should clarify the mechanism, e.g. split wait-for-td to multiple categories 12:59:13 CA: we can file issues at TD, if needed 12:59:32 KA: then it's just another label for TD 12:59:36 -> https://github.com/w3c/wot-scripting-api/issues?q=is%3Aissue+is%3Aopen+label%3Await-for-td Issues with "wait-for-td" 13:00:14 KZ: we have the TD label, then the TD spec may have multiple labels 13:00:29 DP: I can check with Ege about the labeling 13:01:16 KZ: we just need to handle the dependencies 13:01:28 CA: we have label for TD and tracking depending specs 13:01:41 s/KZ:/ZK:/g 13:01:43 CA: next week is canceled, we have biweekl 13:02:00 [adjourned] 13:02:01 CA: adjourned 13:02:06 s/[adjourned]// 13:02:15 rrsagent, make log public 13:02:19 rrsagent, draft minutes 13:02:20 I have made the request to generate https://www.w3.org/2024/02/19-wot-script-minutes.html kaz 13:02:28 s/biweekl/biweekly 13:02:37 rrsagent, draft minutes 13:02:38 I have made the request to generate https://www.w3.org/2024/02/19-wot-script-minutes.html kaz 15:29:31 Zakim has left #wot-script 16:12:16 Ege has joined #wot-script