Meeting minutes
Minutes
Minutes approved
<kaz> Feb-5
quick updates
Cristiano: we have biweekly calls now
PRs
PR 534
<cris_> PR 534 - fix(InteractionOutput): don't require schema.type in value function
Cristiano: started in a node-wot problem with schema
Cristiano: implementation feedback pushed to change the spec
Zoltan: we should have a tracking issue for the case when implementations are asking spec changes
Cristiano: a PR also counts as an issue
Zoltan: I am referring to normal WG practice here
Jan: based on relevant comment we can make a new issue
Cristiano: created issue 546
<cris_> w3c/
Kaz: this discussion contains several issues
… one is implementation feedback from node-wot
… another is a restriction by the schema mechanism
… we should think about those separately
… the spec should describe what is required by implementations, not to describe the schema mechanism
… the spec should think about the necessary dependencies, also towards other implementations
… what kind of data do they handle, what structure is preferred, array or object, what is preferred when, etc.
… we could start with use cases listed by Jan, but we can also ask for more use cases
Cristiano: in general I agree with gathering more feedback
… this problem persists also in the libraries, we need to handle it somewhere
Daniel: maybe it's good to get other developer feedback, e.g. Mozilla WebThings, to see how do they handle similar issues
… and whether is there anything to be fixed in the TD task force
Kaz: agreed
Cristiano: IME they don't have this problem, since they use it only for validation, while node-wot is also using it for bindings
… but we can ask nevertheless
Daniel: we have a use case from discovery also coming up and we also need to cover that
Cristiano: right, this is also needed for solving that
Cristiano: we can do an iterative approach
… for now we can keep the issue open, but agree in a short term resolution until further feedback comes
Cristiano: explaining the details of a short term proposal
Jan: I also tried to extend the algorithm to check the data schema
Jan: for the valid schema, needs some discussion
… we might need stricter definitions for validity
Zoltan: is it an application level issue, or implementation level?
Cristiano: I would ask that as a generic question from the WG
… let's separate the concerns for Scripting
… we don't need very strict rules IMHO, the TD should spec that
<kaz> PR 534 Preview - 7.2.3 The check data schema algorithm
Cristiano: we need to be able to infer the type from the application
Zoltan: we should spec data formats in web specs in general
Cristiano: we can defer to the TD TF
<kaz> and other specs. like Daniel mentioned, WebThing is one possibility, and ECHONET should ne another possibility.
Kaz: agree, and we should look into some more implementation approaches and other specs
Kaz: it might be a good topic for the CG to have a study and tutorial
Cristiano: yes, we can ignite a discussion there
Daniel: we have similar solution in value function and input data, but we don't spec the full JSON schema
Daniel: we could say that the value function may be used in this or that case, otherwise use ArrayBuffer
Cristiano: right, we should update the spec
Jan: there's some example to call value() then catch exception
Zoltan: yes, these belong to explainers
Jan: we wanted to expand the data schema algorithm
… (brainstorming about the algorithm)
Cristiano: some small updates would be needed, mostly we are fine
Cristiano: Jan, please check the steps and provide a PR
Jan: ok
Issues
Kaz: spec doesn't have to replicate the schema mechanism
… we should start with what is needed for the spec, and what can be applied from external algorithms
… if those are not enough, then we can add local algorithm steps
… is the current schema mechanism good enough?
Cristiano: yes, it is, but doesn't explicitly cover all permutations of the schema in our spec
… we validate the schema, plus we spec what the runtime should return
Cristiano: no reason to change, just to complete
Kaz: the base question is that validation by schema is different than by the spec
… so we need to think about the schema and data processing separately
Cristiano: maybe we should indeed split
Kaz: the current spec should be fine, but e.g. the EchoNet people were talking about grouping data, users etc, so the use cases can get complicated, so we might want nicer mechanisms for validation and data handling
Daniel: in ideal case, we should also split not only the spec prose, but also use helper methods to check e.g. if the value() function would work
… without the need to catch exceptions
Cristiano: opened issue 547
<cris_> new related Issue 547 - Refactor: separate schema validation for data processing validation
Cristiano: we need to open or map issues at TD spec
Cristiano: we should split the list of issue for triaging
Daniel: I can handle the triaging
Kaz: we should clarify the mechanism, e.g. split wait-for-td to multiple categories
Cristiano: we can file issues at TD, if needed
Kaz: then it's just another label for TD
<kaz> Issues with "wait-for-td"
Zoltan: we have the TD label, then the TD spec may have multiple labels
Daniel: I can check with Ege about the labeling
Zoltan: we just need to handle the dependencies
Cristiano: we have label for TD and tracking depending specs
Cristiano: next week is canceled, we have biweekly
Cristiano: adjourned