<mjk> scribenick: mjk
Sebastian: any objection to publishing the
minutes?
... OK, minutes to be published
... (review of the updated wiki page)
Lagally: looks good. there could be a little more explanation of terms
<kaz> Readme updated
Sebastian: also cleaned up old branches that were already merged
<sebastian> issue https://github.com/w3c/wot-thing-description/issues/889
Sebastian: minLength and maxLength are
missing
... created a PR which is not finished yet
<sebastian> https://cdn.statically.io/gh/w3c/wot-thing-description/min-maxLength-json-schema/ontology/jsonschema.html
Daniel: how do we decide which options to add?
<Zakim> dape, you wanted to how to cherry pick JSON schema options
Ege: we need two implementations to qualify
Sebastian: we should be able to integrate
straightforward features
... the ontology can be used for other uses beyond Thing
Description
Ege: we had some of these at one time, but removed the features because no one was using them
Lagally: it's good to require two
implementations of each feature and to understand the use cases
that drive requirements
... for example the location information
... we should follow the process for adding new features
Sebastian: we could add a change log entry that explains each change/addition, maybe a separate document
<sebastian> next issue https://github.com/w3c/wot-thing-description/issues/893
<sebastian> https://www.asyncapi.com/
<zkis> https://www.asyncapi.com/docs/getting-started/coming-from-openapi/
<sebastian> https://www.asyncapi.com/docs/getting-started/coming-from-openapi/
<Ege> https://www.asyncapi.com/docs/specifications/2.0.0/#definitionsProtocol
<Ege> https://github.com/fmvilas/asyncapi-websockets-example/blob/master/asyncapi.yaml
<sebastian> issue https://github.com/w3c/wot-thing-description/issues/890
<mjk__> scribenick: mjk__
Ege: review sketches to illustrate
complex action example of a robot arm
... illustrating the need for keeping track of sequences and
dependencies
... the problem is how to structure the hypermedia state
machine
... the problem is simpler than the full hypermedia state machine
but a common set of patterns
Koster: This is like the Carsten's coffee machine example where the client is part of the state machine
Kaz: would there need to be an expected time parameter in the TD also?
Ege: yes, that is part of the problem
Kaz: also interested in this use case
<kaz> related to SMIL and SCXML
<sebastian> https://www.w3.org/TR/REC-smil/smil-timing.html
Ege: constructs similar to those used in SMIL 3.0
Koster: there may be an RDF version of the state chart language
Ege: there is an issue with conflicting requests from more than one client
Koster: is it an extended action or a new interaction class?
Ege: it's an action
Kaz: it's a new data model
construct
... there might need to be another language beyond TD to do
this
Ege: it needs to describe how the
action physically happens
... would also enable a digital twin simulation
Sebastian: need to finish this discussion and create a bigger topic for ongoing discussion
Kaz: reminder to invite Kevin and Ben to join as invited experts
Sebastian: what is the status of the TD
template design?
... mlagally has made a first pass description
<kaz> Issues with "TD Template" label
<mlagally_> https://github.com/w3c/wot-architecture/blob/master/REQUIREMENTS/thing-templates.md
Lagally: issue #454 has the working
definition of a TD template
... construct a thing from multiple templates
<kaz> wot-architecture issue 454
Lagally: need a way to resolve
naming conflicts
... web linking could be used with defined relations to describe
the inheritance
Sebastian: we need a concept of placeholders to be replaced when a TD instance is created from the template
Lagally: who does the
replacement?
... where do the values come from?
Koster: are protocol bindings part of the template?
Lagally: ideally they would be filled in
Ege: sometimes the protocol binding will need to be with the template
Lagally: we could think about what we want to do with templates. e.g use them in simulation
Ege: the template should be flexible as to what is required
Lagally: we also discussed a TD
fragment, which is not a TDT
... we shouldn't define a TDT as arbitrary fragments
Sebastian: we should be careful to allow
protocol information in the TDT
... in some cases as a hint or partial definition
Lagally: what if we want to define the same machine that uses 2 different protocols
Koster: maybe we need to manage the form part and the dataschema part separately from the affordances
Lagally: maybe we need an extended template that has binding information and a clear separation
Kevin: vorto has an extension
mechanism to provide more detail but we don't have override
... name conflicts are handled by namespaces and function block
prefixes
... sharing screen
... example of a vorto definition that extends another
definition
<kaz> Issue 897
Sebastian: we could use URLs in place of the
name string
... can we extend issue #168 to cover the extend mechanism?
Kevin: a question about the vocabulary, how do we describe optionality?
Lagally: is there a one hour tutorial on vorto?
Kevin: start at the vorto github readme
<sebastian> https://github.com/eclipse/vorto
Sebastian: time check, time to wrap up
... continue the discussion on the next call
... also continue the discussion on synchronous actions
... May 1 holiday next week
Kaz: OK to cancel
Sebastian: next TD call in 2 weeks
... AOB?
... T2TRG WISHI call, TD and templates on the agenda
https://github.com/t2trg/wishi/wiki/Agenda-items
[adjourned]