- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Wed, 05 Feb 2020 14:29:12 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2020/01/27-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 API
27 Jan 2020
Attendees
Present
Kazuyuki_Ashimura, Daniel_Peintner, Michael_McCool,
Zoltan_Kis, Tomoaki_Mizushima, Ege_Korkan
Regrets
Chair
Zoltan
Scribe
zkis
Contents
* [2]Topics
1. [3]review 2 previous minutes
2. [4]issue discussion
* [5]Summary of Action Items
* [6]Summary of Resolutions
__________________________________________________________
<scribe> Agenda: issues discussion
[7]https://github.com/w3c/wot-scripting-api/issues
[7] https://github.com/w3c/wot-scripting-api/issues
<scribe> scribe: zkis
review 2 previous minutes
<kaz> [8]Jan-13 minues
[8] https://www.w3.org/2020/01/13-wot-minutes.html
<kaz> [9]Jan-20 minutes
[9] https://www.w3.org/2020/01/20-wot-minutes.html
<inserted> scribenick: kaz
Zoltan: any problems?
... can we approve those minutes?
<inserted> scribenick: zkis
Minutes approved
They can go public.
issue discussion
[10]https://github.com/w3c/wot-scripting-api/issues/198
[10] https://github.com/w3c/wot-scripting-api/issues/198
Zoltan: introduced issues 198 (closed in favor of issue 201). 2
ways forward on how to handle content in the Scripting API
[11]https://github.com/w3c/wot-scripting-api/issues/201
[11] https://github.com/w3c/wot-scripting-api/issues/201
Ege: the discussion seems reasonable, both arguments make
sense. When mentioning fetch(), didn't mean explicit
conversion.
Zoltan: text() and json() only handle 2 media types and we
still cannot avoid a generic opaque DataView
Daniel: agree that some content apps want to parse themselves
Ege: right
Zoltan: we could explore both paths by creating code examples
... for instance like this:
[12]https://w3c.github.io/web-nfc/#write-and-read-json-serializ
ed-and-deserialized
[12] https://w3c.github.io/web-nfc/#write-and-read-json-serialized-and-deserialized
[13]https://w3c.github.io/web-nfc/#read-data-from-tag-and-write
-to-empty-ones
[13] https://w3c.github.io/web-nfc/#read-data-from-tag-and-write-to-empty-ones
Daniel: this is similar to node-wot content handling
Ege: how can the consumer choose the Form?
Zoltan: yes, we have that gap now
Ege: issue 201 might cover it
Daniel: currently we just get back the raw data, and we can
parse it according to the Form
Ege: node-woth just chooses the first Form
Daniel: if the Property is reachable via CoAP and HTTP, the
client is not interested how it gets the data, it just picks
the first one
Ege: there is an internal assumption to pick the first Form
... it should be based on op, security, content type etc - and
currently there is no decision made on the content type
... in Scripting we could make the simplification that JSON is
picked if available
... based on Scripting level requirements; developer puts the
type as an option
Zoltan: should we mix scripting options and interaction
options?
Daniel: an additional optional dictionary could be used
Looking into InteractionOptions possibilities in the TD spec
Zoltan: we could use the TD for the app specified the order of
the Forms that implementation should use
... we could have sensible defaults: if app does not specify
Form, then the implementation should choose
Ege: right, and each implementation should document which is
their default
McCool: the TD itself needs to indicate the priority in the
list of Forms (that implementations should try until succeed)
<ege>
[14]https://github.com/w3c/wot/blob/master/testing/tests/2019-0
5/inputs/Intel/intel-camera.json
[14] https://github.com/w3c/wot/blob/master/testing/tests/2019-05/inputs/Intel/intel-camera.json
Ege: implementations should then figure out if they are in a
local network, or can reach the Internet etc
... so once the TD is consumed, during consuming is there a
reordering of Forms according to local context?
McCool: this is a decision we need to make in the spec
Zoltan: we should aim for stateless Scriping implementations:
if there is a choice, give it to the app
Daniel: if there is a Property reachable by CoAP and HTTP, how
can the app choose?
Zoltan: yes, by passing the object describing the Form
Daniel: sound complicated since the impl has to identify the
Form
Zoltan: so what is the simplest way to identify a Form?
... is the href + other field enough, or should the impl
generate a hash when consuming, then app provide the hash?
Daniel: that is simplest
... to use an index
Daniel: we should define the InteractionOptions dictionary for
used inside Scripting, not the TD
Ege: right
Zoltan: we should maybe file an issue about defining
InteractionOptions
<scribe> ACTION: ZK create issue about InteractionOptions
<ege> [15]https://swagger.io/specification/#requestBodyObject
[15] https://swagger.io/specification/#requestBodyObject
Ege: linked OpenAPI definition of various content types
Zoltan: time is up, but next time we continue, and also take
the rest of the issues
... AOB?
Next time, first thing is to approve these minutes, so please
take a look in advance. Thanks!
Adjourned
Summary of Action Items
[NEW] ACTION: ZK create issue about InteractionOptions
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [16]scribe.perl version 1.154 ([17]CVS log)
$Date: 2020/02/03 01:21:33 $
[16] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[17] http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 5 February 2020 05:29:18 UTC