11:05:01 RRSAgent has joined #wot-script 11:05:01 logging to https://www.w3.org/2021/07/12-wot-script-irc 11:05:09 cris has joined #wot-script 11:05:24 meeting: WoT Scripting API 11:05:49 present+ Kaz_Ashimura, Daniel_Peintner, Cristiano_Aguzzi, Zoltan_Kis 11:07:56 scribenick: cris 11:08:21 TOPIC: prev minutes 11:08:23 -> https://www.w3.org/2021/05/31-wot-script-minutes.html 11:08:41 dape: very short 11:08:56 Mizushima has joined #wot-script 11:09:01 ... we talk about vacation plans and open issues that could be discussed during the F2F 11:09:53 ... moreover we discussed about securityDefinitions and how they are configured in node-wot 11:10:08 ... minor typo at the end of the minutes 11:10:14 ... any other problems? 11:10:24 s/talk/talked/ 11:11:40 dape: minutes approved 11:11:52 topic: quick updates 11:12:35 dape: last time we proposed a shorten procedure to approve the minutes, just to gain more time during the calls 11:12:41 ... not sure who proposed it 11:13:03 ... the idea is to ask to everyone to review the minutes beforehand 11:13:35 zoltan: yes because usually the critical side is the approval not the reviewing process 11:13:58 dape: I like the idea 11:14:11 ... even if it is different from the other Task Forces 11:14:24 ... kaz has the final word 11:14:39 kaz: yes that would be ideal 11:14:48 present+ Tomoaki_Mizushima 11:14:55 dape: ok 11:15:29 zoltan: we can include the link to an announce about the next meeting 11:16:07 ... maybe kaz email about pubblication is enough 11:16:23 dape: not sure 11:16:49 ... we'll duplicate the content, kaz email should be ok 11:16:55 zoltan: ok 11:17:39 cris: +1 for the new procedure 11:18:15 zoltan: we would gain 5 to 10 minutes per call 11:18:28 dape: yeah, usually the minutes are very short 11:18:57 dape: mizushima? 11:19:02 mizushima: ok 11:19:17 q+ 11:19:58 kaz: this imply that daniel would review the minutes beforhand 11:20:29 ack k 11:20:34 s/imply/implies/ 11:22:27 PROPOSAL: Previous minutes are to be read before the meeting. Concerns are to be raised in the beginning of the call. Minutes will be mainly approved in the beginning call. 11:23:32 RESOLUTION: Previous minutes are to be read before the meeting. Concerns are to be raised in the beginning of the call. Minutes will be mainly approved at the beginning of each call. 11:24:04 subtopic: vacation plans 11:24:44 dape: please let us know if you are planning any weeks out 11:25:05 ... it seems that the other calls will have cancellation but I have aviaible most of the time. 11:25:20 topic: test fest and virtual F2F 11:25:48 dape: it woul be useful to try to summarize any relevant topics about scripting api 11:26:17 s/woul/would 11:26:26 s/aviaible/available 11:27:04 CA: Discovery does not require to report a TD 11:27:10 ... it can be anything else 11:28:04 DP: What is expected to be get? 11:28:11 CA: Part of TD 11:28:20 ... filter or selection 11:29:34 dape: can we say that in our use case we require to return a full TD? 11:29:56 q+ 11:32:12 cris: yeah we can reduce the possible queries types 11:32:33 zoltan: we should start from use cases 11:32:53 ... it would be reasonable to start from full TDs 11:33:16 dape: so the consequence for us it to forbid partial fetching 11:34:02 zoltan: we already have general purpose fetching machinism 11:35:50 cris: we can limit query syntax and check the return types 11:35:59 zoltan: we need demos for partialTD 11:36:09 ... try to build the whole use-case (end-to-end) 11:38:30 dape: if we extend later it might break later on 11:38:54 zoltan: we can use a different function to return "anything" 11:40:35 cris: we could start from limiting queries syntaxes and see how it would work for the implementation 11:41:46 dape: we used to have a query field in the ThingFilter 11:41:57 zoltan: we could re-introduce 11:44:50 dape: having jsonPath and SPARQL in the same object (ThingFilter would be odd) 11:45:03 zoltan: we can have enum specifing the query type 11:45:12 dape: I would support it 11:45:58 cris: it is like using functions 11:46:08 zoltan: I would expirement with both 11:47:59 cris: can we limit query syntax? 11:48:27 zoltan: that's a difficult question, we will write algorithms for sure... how they will look like? 11:50:13 dape: the easiest algorithm would be accept any query and try to map the result to a thing description, fail if not possible 11:50:46 zoltan: I want to keep it practical so we should go trough valid use cases. 11:50:54 .... do it small things and well 11:53:52 cris: we have two options right now: 1. use the api just to get a TD and than interact with the TDD 2. provide a more user friendly api that interact with the TDD transparantly 11:55:31 dape: Option 1 seems reasonable 11:55:45 q+ 11:55:55 ... but I feel biased, any other opionions? 11:56:02 s/than/then/ 11:57:06 zoltan: I would leave the current discovery api simple and then make an experimental api for Thing Directories 11:58:27 dape: is there a definitive border between the twos? 11:59:05 zoltan: we can introduce an experimental entry point for Thing Description Directories. 11:59:42 dape: we can ask for feedback 11:59:56 zoltan: expiremental vs stable api is easy to do right now 12:00:31 topic: issues 12:00:39 dape: please check issue 327 12:00:55 ... we need to discuss next week or in the issue 12:00:58 q? 12:01:03 ack zkis 12:01:07 ack kaz 12:01:42 kaz: w3c requires to provide implementations for specifications, we need to make this clear 12:02:03 dape: running code is required, thank you for feedback 12:02:29 ... ok out of time adjourned 12:02:47 [adjourned] 12:02:53 rrsagent, make log public 12:02:57 rrsagent, draft minutes 12:02:57 I have made the request to generate https://www.w3.org/2021/07/12-wot-script-minutes.html kaz