W3C home > Mailing lists > Public > public-wot-ig@w3.org > December 2016

[scripting] minutes - 12 December 2016

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Tue, 13 Dec 2016 01:17:00 +0900
Message-ID: <CAJ8iq9ViMW6iB9FrcE5y3jZmySSP-h2-5z_55Gq1obWAbfA1MQ@mail.gmail.com>
To: Public Web of Things IG <public-wot-ig@w3.org>
available at:

also as text below.




      [1] http://www.w3.org/

                               - DRAFT -

                         WoT IG - Scripting TF

12 Dec 2016

   See also: [2]IRC log

      [2] http://www.w3.org/2016/12/12-wot-irc


          Kaz_Ashimura, Daniel_Peintner, Debbie_Dahl,
          Dirk_Schnelle-Walka, Yingying_Chen, Michael_McCool,
          Johannes_Hund, Uday_Davluru, Zoltan_Kis




     * [3]Topics
         1. [4]agenda
         2. [5]WoT and MMI
         3. [6]Scripting API and REST API
     * [7]Summary of Action Items
     * [8]Summary of Resolutions

   scribecnick: kaz


   jh: Kaz mentioned MMI guys are joining
   ... also we have 2 ongoing topics: REST API vs Scripting API,
   different type of event handling
   ... anything else?


WoT and MMI

   jh: we could start with discussion on collaboration with MMI
   for Scripting API
   ... who is attending?

   dd: Debbie Dahl

   jh: did you prepare something for today?

   dd: not really prepared but can provide some information
   ... we also have Dirk
   ... MMI is focusing on use interface esp. for natural interface
   ... kind of abstract event handling protocol
   ... high-level coordination between application and user
   interface including speech interface, gesture interface, camera
   interface, etc.
   ... we keep the interface abstract so that we can use various
   interface modalities
   ... the MMI lifecycle event is theoretically similar to APIs to
   start/pause/cancel the transaction
   ... Dirk, Kaz might want to add something
   ... any questions?
   ... modality components of MMI has similar concept with WoT

   jh: is there any concrete topic for collaboration?
   ... this TF is working on Scripting API
   ... the interaction model you describe might be similar to what
   we're working on based on property, action and event
   ... would make sense to see which part is similar and which
   part is different with each other
   ... e.g., lifecycle and interface abstraction
   ... but seems that it might be too early to point out the
   concrete similarity
   ... can provide a link to our GitHub repo
   ... any other questions?

   mm: is MMI on process or already standardized?

   dd: already standardized
   ... several RECS
   ... now we're working on discovery of modality components
   ... think semantics of the Scripting API could be a wrapper of
   the MMI lifecycle events

   mm: given your work is a REC, we could think about wrap that

   dd: maybe MMI could wrap TDs

   vents MMI Architecture (its lifecycle event section)

      [9] https://www.w3.org/TR/2012/REC-mmi-arch-20121025/#LifeCycleEvents

   dd: and if the Scripting API would wrap the MMI Architecture,
   semantics of natural language would address what the user wants

   mm: wanted to see PoC or concrete mechanism

   jh: let's see other questions

   dp: you define interaction model in MMI
   ... how do you define codes?
   ... which kind of language do you support?

   dd: we have generic event handling mechanism
   ... also 2 other pieces, e.g., ExtensionNotification
   ... all of the events have data field
   ... you may send data using that
   ... the format of the data is app-specific
   ... in the MMI Architecture, there is an example of XML
   ... but you can use JSON, etc.

   dp: within MMI, how to deal with the data is app-specific
   ... and the MMI Architecture itself doesn't specify that, does

   dd: right

   g diagram on the possible relationship between WoT and MMI

     [10] https://www.w3.org/2002/mmi/kaz/images/MMI-as-UI-for-WoT.png

   ka: there was discussion about how to bridge WoT and MMI during
   the MMI meeting in Lisbon
   ... and some of the WoT participants (Sebastian, Uday and
   Andrei) joined the discussion
   ... the left side of the diagram above is the WoT world
   consists of three WoT Servients
   ... the top Servient is a controller
   ... the left below Servient connects to a rice cooker
   ... the right below Servient connects to an air conditioner
   ... the capability of each device is described by th the Thing
   ... on the other hand, the right side is the MMI world for user
   interface which consists of the orange Interaction Manager as
   the main controller, the brown Resource Manager and the green
   Modality Component
   ... the Modality Component may provide speech
   recognition/synthesis for voice interaction
   ... MMI lifecycle events, WoT Script API and protocol binding
   would be used for message exchange between the WoT world and
   the MMI world

   jh: ok
   ... MMI mainly focuses on user interface for computer systems
   ... this picture is nice to express that idea
   ... MMI Interaction Manager handles human input
   ... would like to follow up for the IG plenary discussion
   ... how to map the Interaction Manager and the Modality
   Component could be mapped to WoT Servients

   mm: what is the wired protocol to bridging WoT and MMI?

   jh: how does the MMI Architecture interact with outside?

   dd: so far we've been thinking about HTTP and WebSocket for
   ... is that what you mean by "wired protocol"?

   jh: ok
   ... MMI over HTTP, etc., is specified?

   dd: there is a section within the spec

   port HTTP transport section

     [11] https://www.w3.org/TR/2012/REC-mmi-arch-20121025/#HTTPTransport

   mm: any implementation?

   jh: not really public

   -> [12]https://www.w3.org/TR/2012/NOTE-mmi-interop-20120124/
   MMI Interoperability Test

     [12] https://www.w3.org/TR/2012/NOTE-mmi-interop-20120124/

   mm: very interested in the implementation
   ... esp. possible participation in the PlugFest, e.g., during
   the Santa Clara f2f

   jh: people bring their implementations to the PlugFest demo
   sessions based on the WoT Current Practice document
   ... if we could reuse the MMI mechanism for speech interface,
   etc., it would be very interesting
   ... we need to bridge the message between the WoT world and the
   MMI world
   ... if somebody can join the PlugFest we can follow up this
   ... we should definitely take input on the lifecycle event part
   as well
   ... is there somebody who bring this to the IG plenary

   mm: do we want to invite the MMI guys themselves?

   jh: sure
   ... can anybody from MMI can join the IG call?
   ... also would be great to have somebody from the WoT group

   dd: do you have any idea on concrete messaging?

   jh: regarding messages, we have Thing Description
   ... Thing Description is serialized version of the data model
   ... major resource is on GitHub

   <jhund> [13]https://github.com/w3c/wot/tree/master/scripting

     [13] https://github.com/w3c/wot/tree/master/scripting

   jh: expose thing and consume thing
   ... the third part is discovery
   ... there is some proposal as well

   jhund-proposal.md Johannes' proposal


   jh: consuming things
   ... actual messaging is done by the protocol binding layer
   ... this is what we've been discussing for the interaction

   dd: thanks
   ... would like to look into the detail
   ... turning on the light, change the color to blue, etc.

   jh: ok
   ... tx so much
   ... any other questions?
   ... would discuss this further during the main call

Scripting API and REST API

   <jhund> [15]https://github.com/w3c/wot/issues/288

     [15] https://github.com/w3c/wot/issues/288

   jh: there was an issue, issue-288
   ... also some discussion on the mailing list
   ... do we still need to change the Charter?

   mm: I've been thinking about this
   ... we could add an item to the Charter
   ... Scripting API is logic for applications
   ... would make sense to have some API beyond REST API
   ... REST API should go under Protocol Binding
   ... but do we want to add yet another normative deliverable for
   ... myself is reluctant for that
   ... personally think we should not make the scope broader

   jh: make sense
   ... would cause problems if we make the scope broader
   ... we can't change the existing REST APIs but should bind them
   to the Scripting API
   ... so that should be under the protocol binding topic

   mm: maybe we can add a topic for REST API but that should be
   ... but the question is we want to add a section even if it's

   jh: zoltan?

   zk: I'm fine with not modifying the Charter itself

   jh: we could decouple the discussion on Scripting API and REST

   mm: there is already standard API for REST

   zk: one question
   ... what do we do for this proposal?
   ... can we include this to the GitHub repo?

   jh: can include the proposal part of the repo
   ... (shows the latest draft Charter)

   mm: we can discuss this during the main call

   jh: will follow up the pull request
   ... for the scripting part, we would see the need for some
   ... for REST API
   ... but decouple from the Scripting API discussion
   ... would add a deliverable for REST API for that purpose
   ... we'll discuss this during the main call
   ... regarding MMI, we'll have further discussion during the
   main call
   ... bridging between WoT and MMI
   ... lifecycle events

   ka: regarding the potential change for the Charter, we need to
   check with Wendy as well

   jh: let's briefly talk within the group first

   [ adjourned ]

Summary of Action Items

Summary of Resolutions

   [End of minutes]

    Minutes formatted by David Booth's [16]scribe.perl version
    1.148 ([17]CVS log)
    $Date: 2016/12/12 16:15:19 $

     [16] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [17] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 12 December 2016 18:02:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:27:08 UTC