<scribe> scribe: zkis
<kaz> Aug-10
in the last call, we had a resolution, but there is no tracking issue, nor PR yet
I can make the issue later today.
Also, some gardening is needed on the wikis and repo.
<kaz> Scripting wiki
<kaz> Scripting repo
Minutes approved.
<kaz> Scripting repo
We should include link to W3C wiki and call details.
Zoltan: also, we need to update the
linked documents
... we need to work on script management
Cristiano: miniapps blend well into that as well
<kaz> Scripting API Primer
Zoltan: we need to check and update
the primer.md
... the TAG actually requires an explainer.md and not a
primer.md
Kaz: we can publish the Primer as a Group Note
Zoltan: we should ask the author
<kaz> Scripting API Rationale
Zoltan: the rationale.md also need updating (at least with Streams related decisions)
<scribe> ACTION: ZK update rationale.md
Zoltan: Kaz, could we discuss the primer publication in the main call?
Kaz: yes, we can
<scribe> ACTION: ZK update the readme.md
<kaz> PR 231
Zoltan: the PR was reviewed and
approved, so merging it now
... we discussed adding the mandatory properties but don't have
an algorithm for initializing them
<inserted> (Daniel joins)
Cristiano: we should just check if mandatory fields are not defined
Daniel: we can also handle it differently: the TD spec says they are required and have a default value
Zoltan: but there are no default
values defined for them
... originally we first filled up the mandatory fields, then
validated
... should we continue like that
Cristiano: so we'd just check the existence of the properties
Zoltan: not sure how to initialize those fields
Daniel: we should not invent values
Zoltan: should we then just check what we get (no convenience fill-up)?
Cristiano: agree
Daniel: agree
Zoltan: okay, then we don't need to file an issue because the current steps are good
Cristiano: if we have optional fields with defaults, should we expand or not?
Zoltan: optional is optional, and we don't need to fill them up
Daniel: agree
Zoltan: we can file an issue later if needed
Cristiano: another thing, cross-validation for values
Zoltan: I think we should check the values respect the TD definitions
Daniel: for op values this is not the
case
... it is just a hint
Zoltan: the op values are used in the algorithms, so now we can create wrong ops and will fail later; it would be nice to fail these early
Cristiano: so we'd add validation steps for that
Daniel: not sure if we need to break it, since it might work fine
node-wot does not check op values per se. A wrong op value would be simply never used
Daniel: node-wot gets the op from the Form and if not found, then no result
Zoltan: we should make sure op values are from the values defined by the TD spec
Cristiano: JSON-validation might include
checks for enums
... also for terms defined in the vocabulary
... field cross-validation etc
... it is protocol-dependent
Zoltan: that is runtime type checking and should not be in the generic steps
Daniel: if we have any TD that
doesn't comply the rules, will fail the TD validation; we
should not check twice
... it will fail not on creation but during exposing
https://www.w3.org/TR/2019/CR-wot-thing-description-20190516/#sec-default-values
<inserted> TD spec - 5.4 Default Value Definitions
Zoltan: wondering if the expose steps are now correct
Daniel: we don't need the expand
step
... no need to specify since if a value is not found, the
client can take the default value
Zoltan: then we need to incorporate that in our steps
Kaz: it might make sense to
discuss this with the TD TF on Wednesday
... based on concrete use case
Zoltan: makes sense
Daniel: the problem is that people are on holiday
Zoltan: we can do that later
... we should track this in an issue
<scribe> ACTION: ZK to create issue in Scripting and TD spec about handling default values
<kaz> PR 234
Will be reviewed later.
Zoltan: what is the affiliation
Kaz: Invited Expert
<scribe> ACTION: ZK to add CA as editor
Daniel: we should invite Ege
adjourned