W3C home > Mailing lists > Public > public-wot-wg@w3.org > July 2021

[Scripting] minutes - 12 July 2021

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Tue, 20 Jul 2021 14:45:29 +0900
Message-ID: <87a6mhbksm.wl-ashimura@w3.org>
To: public-wot-wg@w3.org
available at:

also as text below.

Thanks a lot for taking the minutes, Cristiano!




      [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


          Cristiano_Aguzzi, Daniel_Peintner, Kaz_Ashimura,
          Tomoaki_Mizushima, Zoltan_Kis





    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

   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
   … 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

   <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


   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

    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

This archive was generated by hypermail 2.4.0 : Tuesday, 20 July 2021 05:45:35 UTC