Meeting minutes
last minutes
<kaz> Dec-14
Minutes approved.
issue#285
<dape> https://
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://
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]