Meeting minutes
Minutes
Cristiano: have reviewed them
… any objections?
(some minor problem with the CSS style, etc.)
approved
Cancellations
Cristiano: next week, the Scripting API call will be cancelled
Feedback from TD TF
Cristiano: joint discussion with the TD TF
Cristiano: about meta operation work item, etc.
Kaz: think we should clarify the procedure for the joint discussion as well
… how to continue the collaborative discussion, etc.
Cristiano: yeah
… should clarify our goals, etc.
PRs
PR 534
<cris_> PR 534 - fix(InteractionOutput): don't require schema.type in value function
Jan: discussion over node-wot as well
… schemas can be more complex
… multiple different schemas are possible
… this PR moves one proposal to summarize the discussion so far
… we need to remove (some of) the type requirements
… proposing to add constraints
… adding this suggestion might not make sense for some cases
… not sure if we can merge PR now
… maybe need some more discussion
rendered HTML - 7.2.3 The check data schema algorithm
Daniel: maybe we can shift the validator
… the possible downside is valiadation without any library
… not sure if we want to put any additional requirement
Cristiano: good point
<kaz> s/ping/point
Cristiano: we're using JSON Schema for two purposes
… for scripting itself and protocol binding applications
… put requirements for our logic which is not existing yet
… what to be done for random bytes?
… would it be a real requirement?
… not sure if everything is allowed by TD
… anyway JSONSchema is not a standard
Kaz: agree
… JSONSchema is only one possible mechanism for validation
… we should start with our own spec text for Scripting API
… if we can apply JSONSchema for that purpose luckily, that's fine
Cristiano: agree
Jan: maybe we can't cite JSONSchema
… but need to define necessary algorithm ourselves
Cristiano: not sure about the expected data mapping here completely
… e.g., around the second channel data
… it's not trivial about the mapping
… have to look into the detailed use cases
… tx for your input, Jan
Daniel: we've been already defining some simple form of JSONSchema here
… we could continue to work on that direction
… or can also work on one-off definition
… but for simplicity, reducing the complexity would be better
… e.g., no need for validation on our own
… would try to cover them with too strict restriction with JSONSchema
Cristiano: would be kind of compromise for us until we clarify the detail on the mapping payload
… we should not work on the detail now
… btw, everything in the table 4 at "5.3.2.1 DataSchema" from WoT Thing Description is optional
TD spec ED - 5.3.2.1 DataSchema
Cristiano: (adds comments to PR 534)
Kaz: which vocabulary terms to be handled here?
Cristiano: think we need four of them: oneOf, const, enum, default
Daniel: can put "?" for "default" here?
Cristiano: (put "?" to "default")
… related to Issue 537
Issue 537 - Proposal: use TD default values
Cristiano: Jan, can you work on "default"?
Jan: ok
Kaz: it would be nicer to have some brief description for each parameter
… e.g., in which case for what, we need "enum"
Cristiano: yeah
<JKRhb> +1
Cristiano: important to describe the use cases
… maybe need some additional description for that
PR 538
PR 538 - Type definition generator information to readme
Daniel: typo causing a merge conflict?
Cristiano: ah
Daniel: can copy the first line
merged
PR 543
PR 543 - fix: respec warnings about anchor/link
Daniel: simply fixes about ReSpec issues
merged
PR 544
PR 544 - fix: minor capitalization typo
Cristiano: another typo fix
Kaz: do we want to use "DoS" acronym for the title as well?
… "DoS" is more popular as a possible risk than "Denial of Service"
Cristiano: ok
… (adds "(DoS)" to the title too)
merged
Next call
Cristiano: let's continue the discussion next time
… remember we won't have the call next week on Feb 12
[adjourned]