- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Tue, 13 Dec 2016 01:17:00 +0900
- To: Public Web of Things IG <public-wot-ig@w3.org>
- Message-ID: <CAJ8iq9ViMW6iB9FrcE5y3jZmySSP-h2-5z_55Gq1obWAbfA1MQ@mail.gmail.com>
available at:
https://www.w3.org/2016/09/19-20-multimodal-minutes.html
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/
Received on Monday, 12 December 2016 18:02:19 UTC