<scribe> scribe: zkis
<kaz> Nov-16
Daniel: any objections?
No objections
Minutes approved.
<kaz> Issues
Zoltan: fixed by PR #280, closed.
<inserted> DP: we should use dated links for the case one of the specs is moving forward and the other is stopped
Zoltan: do the dependencies already have a known URL?
Kaz: they will be published
tomorrow
... if we are using dated URL in the Scripting API draft, we
need to update the pubdate
Cristiano: we should go with the undated
URLs
... wondering if there is problem because publishing more
often
Zoltan: in general I agree we should
use undated, as it was also recommended in the TPAC
... (since people always look on the newest versions of
documents)
Kaz: the other specs in WoT are
using dated URLs
... and we can also use them for this publication
Zoltan: checking the source code, the
Scripting biblio has dated URLs for Architecture and TD, and
not dated for the others
... should we continue that for the upcoming Note?
Cristiano: fine with both
Kaz: technically it will use dated URL every time
Zoltan: we can leave it to that
way
... let us know how it works better
<scribe> ACTION: ZK to update the issue with a summary of this discussion
Zoltan: this was already discussed and we chose the design in the Note that will be published
Cristiano: will check again and decide if will continue keeping it open
Cristiano: this is one of the TD validation issues
Zoltan: do we need to spec these in the algorithms?
Cristiano: we could just say the value function applies the DataSchema of the returned object and raise an error
Daniel: node-wot has not yet implemented these validations, it's an open issue
Zoltan: it is our job to define well the validation and make it normative for security and privacy reasons
Cristiano: showing the "check data
schema" algorithm
... we need to add the steps that check the bounds
Daniel: we could get away not defining steps if they are not provided in the schema
Zoltan: we must include the checks if the boundary values are defined
Daniel: this is getting complicated, we should follow DataSchema
Cristiano: also there is a problem to keep up in the TD
<kaz> 6.2.3 The check data schema algorithm
Cristiano: for instance the data schema
checking algorithm is it public or not?
... could we follow the JSON Schema validation?
Zoltan: yes, preferably we should refer to external algorithm
Cristiano: do we have corner cases when our algorithm is more restrictive than JSON Schema validation?
Daniel: we are using less keywords so we should comply with JSON Schema validation
Zoltan: we should make it clear how do we apply it in our algorithms
Cristiano: that would solve a series of issues
Cristiano: could not find edge cases
when JSON Schema would not be enough
... the question is should we go deeper than JSON Schema
checking
... but probably not
Daniel: need to ask Ege
... Ege had additional points
Cristiano: we need to decide which
checks used by Ege to standardize in Scripting
... also, should we fail early or late?
CA is leaving a comment in the issue
Cristiano: should we add a runtime property for querying the version?
Zoltan: we could check what other specs do
<scribe> ACTION: ZK and CA look into other specs
adjourned