W3C

WoT Scripting

11 January 2021

Attendees

Present
Cristiano_Aguzzi, Daniel_Peintner, Kaz_Ashimura, Tomoaki_Mizushima, Zoltan_Kis
Regrets
-
Chair
Daniel Peintner
Scribe
zkis

Meeting minutes

last minutes

<kaz> Dec-14

Minutes approved.

issue#285

<dape> https://github.com/w3c/wot-scripting-api/issues/285

Daniel: addressed most points, we could close it

Zoltan: yes, we can close it

Daniel: any open topic remained?

Cristiano: we can close it

issue#284 and #278

<dape> https://github.com/w3c/wot-scripting-api/issues/284 and https://github.com/w3c/wot-scripting-api/issues/278

Daniel: mostly about the links updated for the publication

Architecture Terminology, see https://github.com/w3c/wot-architecture/issues/574

Daniel: M.Lagally brought it up about the Thing fragments.

Cristiano: we should define what is the minimum content of Thing fragment
… Thing Model vs Thing fragment is a bit open and confusing, we should clarify

Zoltan: we need a private concept in Scripting, meaning a simple dictionary for initialization
… and if we can align, we can define a term in Architecture
… if there is a minimum required content, we should spec it

Daniel: the minimal content is the empty object
… it is not clear what is the difference in Thing Model vs Thing fragment
… a Model is like a typical description, a fragment is more like a JSON
… instance

Zoltan: implementations can override the provided dictionary

Daniel: they should be able to do that even with models

Zoltan: still think we should have separate definitions for Scripting and Architecture

Cristiano: but it's not just a normal dictionary, since it has to conform certain requirements
… like syntactic issues

Zoltan: so you'd like a formal definition and also a validation algorithm

Daniel: the problem is the JSON schema instance for validating would fail if you'd provide just a property name without and href
… so it is difficult to come up with this
… and it has to be the same for every implementation, so it should not be private

Cristiano: we also need to consider the directory use case as well
… like searching for Things similar to the ones passed

Zoltan: so a Thing should pass as a model

Cristiano: probably yes
… but mainly a separate entity, copy some stuff and then throw it away

Daniel: for a JSON schema validation, we should pick what we have now and mark the rest as optional

Cristiano: then it's just a fragment, if things are optional

Daniel: the "required" stances could be made optional, then it becomes usable for model/fragment

Zoltan: we should use "arbitrary fragment", rather than model

Cristiano: I agree here
… every model should have id, title, ... at least

Daniel: I hear the Thing Model is more restrictive, but IMO it's generic
… need to look into this

Zoltan: we could go by examples, then definitions

Daniel: we can have a simple definition: take JSON schema and prune all "required" stances

Zoltan: this is a necessary step, maybe also sufficient

Cristiano: agree

Daniel: we need to attend the Architecture call with this agreement

Cristiano: I can do that

validating Thing fragment

Daniel: we need to spec this, based on today's discussion as well

Zoltan: should that be in the TD spec?
… if there are any constraints, we should have an algorithm in the Scripting spec

Cristiano: I agree with Daniel's proposal for validation

Daniel: so in node-wot, if there is a "required" stance, we just ignore that it is required, i.e. the href can be there, but it can be overridden

Zoltan: why not creating an explicit JSON schema then for fragments?

Cristiano: I agree

Daniel: we do it on the fly currently
… not sure if there are more restrictions on the Thing model?

Daniel: we should wait on what others will say from the other task forces
… we leave the issue open
… in the best case we can assume model == fragment, but let's see

Cristiano: we should track it in an issue

Daniel: will do that after the call

discovery-related updates

Daniel: need to wait on the Discovery TF

versioning

Daniel: in the issue we say it's good practice to not break

Zoltan: but we need to track API changes somehow

Cristiano: an impl should be able to tell during runtime which semantic is used
… what if I want a script to work both with old and new ABI
… a version number would allow that

Zoltan: looks like we move more towards a REST API style

Zoltan: the question is what do we need to spec so that every impl respects it
… is it enough if we track version on node-wot level, or I want all impls behave the same way?

Cristiano: looks like we need at spec level, across all implementations, need to check

Zoltan: it's easier to have a version in the spec, than not having it, but what text we put in the spec

Daniel: it's not straightforward in the implementations, though - it must be updated, otherwise useless
… so I like more that the implementations are clear about versions

Zoltan: so we can stay with the current status-quo

Daniel: yes, but CA might have use cases for a spec version

Zoltan: I am not sure if other web APIs have versions any more

[adjourned]

Minutes manually created (not a transcript), formatted by scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).