<mjk> scribenick: mjk

Review of the previous minutes

Sebastian: any objection to publishing the minutes?
... OK, minutes to be published
... (review of the updated wiki page)

GitHub repo reorganization

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

Issue #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

Async API review

<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

Issue #890 keywords for async actions

<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

TD templates

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]