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

Re: [scripting] minutes - 12 December 2016

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Thu, 22 Dec 2016 04:18:03 +0900
Message-ID: <CAJ8iq9WN_MOvPo8XJ6fScaLERHA=xHSXWiTcxYkFtATkN1YjtA@mail.gmail.com>
To: Public Web of Things IG <public-wot-ig@w3.org>
On Tue, Dec 13, 2016 at 1:17 AM, Kazuyuki Ashimura <ashimura@w3.org> wrote:

> available at:
>   https://www.w3.org/2016/09/19-20-multimodal-minutes.html
>

Sorry but it seems the link above was wrongly cut&pated.

The correct URL for the minutes from the Scripting call on Dec. 12 is:
  https://www.w3.org/2016/12/12-wot-minutes.html

The text version of the minutes below is correct.

Kazuyuki



>
> also as text below.
>
> Thanks,
>
> Kazuyuki
>
> ---
>    [1]W3C
>
>       [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
>
> Attendees
>
>    Present
>           Kaz_Ashimura, Daniel_Peintner, Debbie_Dahl,
>           Dirk_Schnelle-Walka, Yingying_Chen, Michael_McCool,
>           Johannes_Hund, Uday_Davluru, Zoltan_Kis
>
>    Regrets
>    Chair
>           Johannes
>
>    Scribe
>           kaz
>
> Contents
>
>      * [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
>
> agenda
>
>    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?
>
>    (none)
>
> 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
>    servient
>
>    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
>    mechanism
>
>    dd: maybe MMI could wrap TDs
>
>    ->
>    [9]https://www.w3.org/TR/2012/REC-mmi-arch-20121025/#LifeCycleE
>    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
>    serialization
>    ... 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
>    it?
>
>    dd: right
>
>    ->
>    [10]https://www.w3.org/2002/mmi/kaz/images/MMI-as-UI-for-WoT.pn
>    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
>    Description
>    ... 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
>    transfer
>    ... is that what you mean by "wired protocol"?
>
>    jh: ok
>    ... MMI over HTTP, etc., is specified?
>
>    dd: there is a section within the spec
>
>    ->
>    [11]https://www.w3.org/TR/2012/REC-mmi-arch-20121025/#HTTPTrans
>    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
>    discussion?
>
>    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
>
>    ->
>    [14]https://github.com/w3c/wot/blob/master/scripting/proposals/
>    jhund-proposal.md Johannes' proposal
>
>      [14] https://github.com/w3c/wot/blob/master/scripting/
> proposals/jhund-proposal.md
>
>    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
>    REST API?
>    ... 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
>    informative
>    ... but the question is we want to add a section even if it's
>    informative
>
>    jh: zoltan?
>
>    zk: I'm fine with not modifying the Charter itself
>
>    jh: we could decouple the discussion on Scripting API and REST
>    API
>
>    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
>    template
>    ... 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/
>
>
>


-- 
Kaz Ashimura, W3C Staff Contact for Auto, WoT, TV, MMI and Geo
Tel: +81 3 3516 2504
Received on Wednesday, 21 December 2016 19:19:28 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 December 2016 19:19:28 UTC