- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Tue, 20 Jul 2021 14:45:29 +0900
- To: public-wot-wg@w3.org
available at: https://www.w3.org/2021/07/12-wot-script-minutes.html also as text below. Thanks a lot for taking the minutes, Cristiano! Thanks, Kazuyuki --- [1]W3C [1] https://www.w3.org/ WoT Scripting API 12 July 2021 [2]IRC log. [2] https://www.w3.org/2021/07/12-wot-script-irc Attendees Present Cristiano_Aguzzi, Daniel_Peintner, Kaz_Ashimura, Tomoaki_Mizushima, Zoltan_Kis Regrets - Chair Daniel Scribe cris Contents 1. [3]prev minutes 2. [4]quick updates 1. [5]vacation plans 3. [6]test fest and virtual F2F 4. [7]issues 5. [8]Summary of resolutions Meeting minutes prev minutes <dape> [9]https://www.w3.org/2021/05/31-wot-script-minutes.html [9] https://www.w3.org/2021/05/31-wot-script-minutes.html Daniel: very short … we talked about vacation plans and open issues that could be discussed during the F2F … moreover we discussed about securityDefinitions and how they are configured in node-wot … minor typo at the end of the minutes … any other problems? Daniel: minutes approved quick updates Daniel: last time we proposed a shorten procedure to approve the minutes, just to gain more time during the calls … not sure who proposed it … the idea is to ask to everyone to review the minutes beforehand Zoltan: yes because usually the critical side is the approval not the reviewing process Daniel: I like the idea … even if it is different from the other Task Forces … kaz has the final word Kaz: yes, that would be ideal Daniel: ok Zoltan: we can include the link to an announce about the next meeting … maybe kaz email about pubblication is enough Daniel: not sure … we'll duplicate the content, kaz email should be ok Zoltan: ok Critiano: +1 for the new procedure Zoltan: we would gain 5 to 10 minutes per call Daniel: yeah, usually the minutes are very short Daniel: mizushima? Mizushima: ok Kaz: this implies that daniel would review the minutes beforhand <dape> 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. 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. vacation plans Daniel: please let us know if you are planning any weeks out … it seems that the other calls will have cancellation but I have available most of the time. test fest and virtual F2F Daniel: it would be useful to try to summarize any relevant topics about scripting api <dape> CA: Discovery does not require to report a TD <dape> ... it can be anything else <dape> DP: What is expected to be get? <dape> CA: Part of TD <dape> ... filter or selection Daniel: can we say that in our use case we require to return a full TD? Critiano: yeah we can reduce the possible queries types Zoltan: we should start from use cases … it would be reasonable to start from full TDs Daniel: so the consequence for us it to forbid partial fetching Zoltan: we already have general purpose fetching machinism Critiano: we can limit query syntax and check the return types Zoltan: we need demos for partialTD … try to build the whole use-case (end-to-end) Daniel: if we extend later it might break later on Zoltan: we can use a different function to return "anything" Critiano: we could start from limiting queries syntaxes and see how it would work for the implementation Daniel: we used to have a query field in the ThingFilter Zoltan: we could re-introduce Daniel: having jsonPath and SPARQL in the same object (ThingFilter would be odd) Zoltan: we can have enum specifing the query type Daniel: I would support it Critiano: it is like using functions Zoltan: I would expirement with both Critiano: can we limit query syntax? Zoltan: that's a difficult question, we will write algorithms for sure... how they will look like? Daniel: the easiest algorithm would be accept any query and try to map the result to a thing description, fail if not possible Zoltan: I want to keep it practical so we should go trough valid use cases. … do it small things and well Critiano: we have two options right now: 1. use the api just to get a TD and then interact with the TDD 2. provide a more user friendly api that interact with the TDD transparantly Daniel: Option 1 seems reasonable … but I feel biased, any other opionions? Zoltan: I would leave the current discovery api simple and then make an experimental api for Thing Directories Daniel: is there a definitive border between the twos? Zoltan: we can introduce an experimental entry point for Thing Description Directories. Daniel: we can ask for feedback Zoltan: expiremental vs stable api is easy to do right now issues Daniel: please check issue 327 … we need to discuss next week or in the issue Kaz: W3C Process requires us to provide implementations for REC Track specifications, we need to make this clear Daniel: running code is required, thank you for feedback … ok out of time adjourned <kaz> [adjourned] Summary of resolutions 1. [10]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. Minutes manually created (not a transcript), formatted by [11]scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC). [11] https://w3c.github.io/scribe2/scribedoc.html
Received on Tuesday, 20 July 2021 05:45:33 UTC