- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Wed, 01 Apr 2020 18:15:39 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2020/03/23-wot-minutes.html
also as text below.
Thanks a lot for taking the minutes, Zoltan!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WoT Scripting
23 Mar 2020
Attendees
Present
Daniel_Peintner, Michael_McCool, Tomoaki_Misushima,
Zoltan_Kis, Kaz_Ashimura
Regrets
Chair
Zoltan
Scribe
zkis
Contents
* [2]Topics
1. [3]Previous minutes
2. [4]Issues discussion
3. [5]issue#208
https://github.com/w3c/wot-scripting-api/issues/208
4. [6]Discovery API
* [7]Summary of Action Items
* [8]Summary of Resolutions
__________________________________________________________
Previous minutes
<kaz> [9]Mar-2 Scripting call minutes
[9] https://www.w3.org/2020/03/02-wot-minutes.html
<kaz> [10]Mar-16 Virtual F2F minutes - Scripting session
[10] https://www.w3.org/2020/03/16-wot-minutes.html#item04
<inserted> scribenick: kaz
Zoltan: any problems with those minutes?
<inserted> scribenick: zkis
No objections, meeting minutes accepted
Issues discussion
Zoltan: if there are things to follow up, please create issues
... we have agreed on how to move on regarding issue#201
[11]https://github.com/w3c/wot-scripting-api/issues/201
[11] https://github.com/w3c/wot-scripting-api/issues/201
issue#208 [12]https://github.com/w3c/wot-scripting-api/issues/208
[12] https://github.com/w3c/wot-scripting-api/issues/208
Zoltan: the Oracle TD example raises questions regarding
subscription data, passing keys etc
McCool: maybe using hypermedia would be better; it depends if
this describes existing system or is it a wish list
I believe TD eventing is still underspecified, more work needed
McCool: we need to separate what is in TD and protocol binding
... we could also have a web hook
... if we put public keys in the TD, we also need to sign it
Zoltan: we need a mechanism that apps could manage keys
... we should maybe invite M.Lagally to next meeting
McCool: the cancellation uses id or URL; how is that handled in
Scripting
Daniel: this is very underspecified
... maybe works for Oracle, not sure if works for others
... subscriptions should be by name and the runtime would
associate that with bindings information
Zoltan: this looks like protocol bindings data that could be
hidden behind the name to subscribe to
McCool: we need to specify this
... we should check events for TD v2
... we need to solve this quickly
Zoltan: otherwise including these details would end up
fragmenting WoT
Daniel: checking the TD spec for how well Events are specified
... looks like a placeholder, it's not specified well
... we need a solution that works through all the use cases
McCool: these look like actions (when return type is different)
Daniel: we could also expose the whole thing to the apps
McCool: or standardize the mechanisms
Zoltan: is the subscription data always a DataSchema?
McCool: it could be anything
Daniel: these are just placeholders, they need more work
McCool: there are uncertainties how this works in practice
... is output data different schema than input data?
... when I make a subscription, I get back a data that is not
the regular event data
... but a subscription id or something
... later it might send data
... but it also might send data right after the subscribe call
Zoltan: event data is always dispatched separately from the
subscribe call
Daniel: if we ask for subscription, we should get some feedback
or return value
McCool: we could have an Action for subscription
... we'd need to spec how to identify id in subscriptions in
order to automate
... even if the protocols bundles together data and
subscription return, data is dispatched separately
Zoltan: right, it should be separate
McCool: we don't have means in the TD to handle subscription
id's
... we can have a best known method for TD v1 and make it a
mechanism to annotate subscription id's in TD v2
Daniel: open an issue on the TD spec
Zoltan: some data needs to be opened up to apps, the question
is how much (key management etc)
McCool: but that could be done in the setup phase
Zoltan: should we standardize interaction setup?
McCool: using shared secrets in an interaction should be
annotated as such so that the runtime could handle it
automatically
Zoltan: sounds good
McCool: I would flag this as an issue
... if the runtime is responsible for this, how to do it
Zoltan: maybe create an issue in TD, security and scripting
McCool: also, need to design how to handle MQTT
... the web hook was needed for instance
<kaz> [13]TD draft - 5.5.1.5 EventAffordance
[13] https://w3c.github.io/wot-thing-description/#eventaffordance
Daniel: will create the TD issue
Discovery API
<kaz> [14]Issue 206
[14] https://github.com/w3c/wot-scripting-api/issues/206
McCool: we can discuss this in the Discovery call
... we need to experiment with this
Zoltan: we could have a local directory to the runtime
McCool: we need a PoC, Singapore also interested
... the scripting API works in the 2nd phase (after onboarding
etc)
... during onboarding, it's another API that should be used
Zoltan: when you have the Scripting API object, the device is
already onboarded
McCool: it is also a virtualization issue
... if an app specifies a mechanism the implementation does not
need to respect it
Zoltan: right, and currently they get an error
McCool: the directory mode should always work
... like delegating discovery
Zoltan: apps can specify no mechanism, then the runtime will
choose the best or all available
... looks like we agree on discovery
McCool: We need fully specified filters
... including one for location
... need to look into the Location API
Zoltan: those are pretty easy to make an API for if we know the
use case
McCool: will discuss in the Discovery call
... there could be filters specific to directories
... also, we need to spec the semantic queries
... like SPARQL support
... keywords and templates should be specified
Daniel: is the list of discovery use cases complete?
McCool: we miss templates from there
Daniel: we miss that from the use cases but support it in the
API
McCool: partial TD?
Daniel: yes
McCool: semantic queries is a bit of a question, maybe partial
TDs would be enough
Zoltan: semantic query requires an infrastructure we currently
have not discussed yet
McCool: maybe the partial TD filters should be enough
... let's document and use that first
[adjourned]
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [15]scribe.perl version
1.152 ([16]CVS log)
$Date: 2020/03/23 19:32:29 $
[15] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[16] http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 1 April 2020 09:15:43 UTC