Previous minutes: https://www.w3.org/2020/04/06-wot-minutes.html
<scribe> scribe: zkis
Daniel: about init dictionary, do we continue using that name?
Zoltan: until it's changed in the
Architecture call discussion, we use the name
... it is a common name, what we needs to be discussed is how
does it relate to Thing Templates or Partial TDs
<kaz> Issue 210
Zoltan: wondering about the value of opening up hooks for event subscription and observe
Daniel: it came from proxy implementations who want to know when an event has been dispatched and observation notification happened
Zoltan: the proxy could subscribe
explicitly to the original Thing
... so it uses ConsumedThing
Daniel: but also exposes a new Thing
as ExposedThing
... and needs to forward the subscriptions to the original
Thing
Zoltan: ok, so it _completely_
defines the behavior, not just customizes it
... so I can do the changes in this way.
... another question, could we include additional data
(subscribe and cancelation data) into InteractionOptions?
Daniel: makes sense
... wondering if we need at all the subscription data and
cancellation data
<kaz> 7. the ExpostedThing interface
<kaz> 6. The ConsumedTHing interface
Daniel: anyway it's good to include into InteractionOptions
Daniel: explains the use case
Zoltan: seems clear, will complete the changes
Daniel: currently we don't really fully validate TDs in node-wot, just check context and expand the TD with default values.
Zoltan: yes, we should just relax that in the spec
Daniel: had the question whether should we use InteractionData as input as well
Zoltan: implementations can do that,
why to bother apps with that
... apps should just provide the language abstracted types, and
implementations figure out the serialization based on protocol
bindings
Daniel: points out an incorrect example, needs to be fixed
Zoltan: eventually we could return a parsed simple types or the complex InteractionData
Daniel: need to think about
this
... wondering would it be too complex if we require
InteractionData also for input
Zoltan: here is one example: https://w3c.github.io/web-nfc/#example-6
... and https://w3c.github.io/web-nfc/#example-13
... the problem is that in order to be able to handle the
exceptions, we make all use cases difficult
... perhaps at this level it is fine to be a complex API and
eventually have other simpler libraries on top
Daniel: OK, let's reach out to others and ask
Zoltan: any other topics?
Daniel: checking the list of issues at https://github.com/w3c/wot-scripting-api/issues
Zoltan: feel free to comment on any issues
[adjourned]