<scribe> Agenda: issues discussion https://github.com/w3c/wot-scripting-api/issues

<scribe> scribe: zkis

review 2 previous minutes

<kaz> Jan-13 minues

<kaz> Jan-20 minutes

<inserted> scribenick: kaz

Zoltan: any problems?
... can we approve those minutes?

<inserted> scribenick: zkis

Minutes approved

They can go public.

issue discussion

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

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: https://w3c.github.io/web-nfc/#write-and-read-json-serialized-and-deserialized

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> 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> 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