Meeting minutes
past minutes
Daniel: any comments on the minutes?
Daniel: no, past minutes approved, can be published
quick updates
Daniel: might miss next call
Cristiano: not available either on the next call
Zoltan: so we can skip the call
Daniel: so the next call is on 23 August.
<Mizushima> +1
publication
Daniel: publication plan, we can make an update in September or October
open PR
<dape> https://
Daniel: approvals are there, can be merged (after fixing conflicts)
Cristiano: we can mark package.json as private
Daniel: should we have the same name wot-typescript-definitions in the repo
Zoltan: no, I don't think we have that constraint
Cristiano: it's fine as it is
Daniel: ok, comments resolved in the PR
Daniel: about version numbering, is that fine?
Cristiano: the TD schema used the same convention for version
… though a date in a version is not common
… we can add SNAPSHOT
Zoltan: it's like a note in the version string, so whether it contains a date or snapshot it's private decision
Daniel: we can merge and try right away what happens when publishing the npm
Issue 193: Should writeProperty() return a value
<dape> https://
Daniel: whether writing a property should return a value
Daniel: we needed a feature to tell whether a value can be returned by the write op
Daniel: I suggest the Scripting TF waits until this is finalized
<dape> https://
Daniel: Sebastian commented
Daniel: there are 3 options, 1. no return, 2. return the same data schema, 3. return a different data schema
Daniel: the Scripting API should model these
Cristiano: this will imply other changes to the Scripting API, for instance DataSchema can be in a Form now
… this is a general issue
Daniel: there will be ExpectedResponse schema, AdditionalExpectedResponse etc
Daniel: we can return InteractionOutput on writes again, we need a way to indicate to expect something or not
Zoltan: we already have the schema in InteractionOutput, that can be null
Cristiano: I understood the same way
Daniel: I thought this was optional hint, but ok
Daniel: so if the TD TF decided to support the use case, Scripting might need little changes
Cristiano: may we can just add InteractionOutput and check the use cases
… based on Sebastian's comment on ExpectedResponse, we might need to re-check
… AdditionExpectedResponse was not defined well, therefore a schema was put there
Cristiano: again the question is what makes a difference between an Action and a property write
Zoltan: WoT inherited most problems from supported protocols and provided very little generalization
Cristiano: have the same feeling
Daniel: it's because the many specific use cases
Kaz: agree with both sides but clarifying typical use cases would be good
… for instance timeout with HTTP
… we should consider the exact use cases
Daniel: should we raise this with the TD TF?
Kaz: obviously this is a generic comment, to stick to use cases
Zoltan: we need more than just use cases, we need to be able to generalize and make it usable
Cristiano: we need more applications (with a lot of use cases)
Kaz: yes, use cases mean also the complete scenario
Daniel: we do have one mash-up use case
Kaz: we can start from the Core profile (Ben Francis)
Daniel: anyway we don't decide there, Scripting follows the decisions in the other tack forces
propose closing issues
<dape> https://
<dape> https://
Daniel: it's a lot of complexity and we don't have a use case
Zoltan: the TD TF should handle this first
Kaz: transferring issue is ok, but could go to the profile or implementation guideline
… so we can raise that in the main call
Zoltan: yes, we should transfer this, not close this
Zoltan: check the Generic Sensor API how this could be dealt with
https://
Kaz: warning to not add big features at this point given the charter period.
Daniel: call adjourned