Meeting minutes
Agenda
<dape> Agenda
accepting past minutes
<dape> May-10
Minutes approved.
next call, May 24 is Whit Monday
It is a holiday in many countries, so May 24 call is skipped.
June F2F
<kaz> June Testfest/vF2F wiki
Kaz: someone needs to give update for node-wot
Daniel: will be on holiday in 2nd half of June
issue 193
<dape> https://
Daniel: there was a point about Echonet
Kaz: we need to ask Matsuda-san, etc., for clarification
… we need to wait for the result of that
Daniel: there was also a point about OCF
Zoltan: will check that
Daniel: proposal from ZK looks good, would it make sense to include that in the algorithms?
Cristiano: yes - it looks like a 200 response
… how do you specify tolerances in DataSchema?
… just discussed with Sebastian how to model uint16
Zoltan: right, precision is missing from DataSchema
Daniel: yes the schema misses that
Zoltan: what does number mean in DataSchema
Cristiano: it's like in JavaScript
Zoltan: so we cannot implement step 2 from the proposal
Daniel: right, and then we go on thin ice when rejecting because of precision differences
Daniel: but there is the "multipleOf" option which could help scaling the precision
… so we can put an appropriate formulation there
Zoltan: also, the app could observe the property and then write and check the value from the notification
Daniel: yes that would work
Daniel: and in the case of Philips Hue, one should model it with Actions
Cristiano: I agree
… the only way to write consistent TDs and model underlying protocols. I would not change the TD spec in order to cover protocols
… but then what should we do when strings are truncated?
Zoltan: a clear case of error
Cristiano: but the same case is with numbers
Daniel: I can see the relation
… if match is not 1:1, if we could have an error code for that
Zoltan: we could have a new option that hints at a minimum precision
Cristiano: why not let this logic be handled by scripts?
Zoltan: how do we return the value?
Cristiano: in the error
Zoltan: I see problems with that, maybe using InteractionOutput... typically for numbers, a standard is used for representation
<dape> https://
Daniel: this is linked to the error mapping case
Daniel: the use case is to know which protocol binding has failed
Zoltan: then we need a general information in replies which protocol binding was used
Cristiano: exactly
… we could keep the errors at interaction level, and we could reveal the details separately
Zoltan: should we have a separate call for more detailed errors, given the Error object, or can we standardize an Error object
Cristiano: will have to think about that
Daniel: would prefer without a second call for details
Zoltan: ok, but still I don't like to expose every protocol details to the apps
Cristiano: agree with that
Daniel: time is up
feel free to add to the issues
adjourned