- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Wed, 13 May 2020 18:03:02 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2020/04/24-wot-td-minutes.html
also as text below.
Thanks a lot for taking the minutes, Michael Koster!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WoT-WG - TD-TF
24 Apr 2020
Attendees
Present
Kaz_Ashimura, Daniel_Peintner, Michael_Koster,
Michael_Lagally, Sebastian_Kaebisch, Taki_Kamiya,
Ege_Korkan, Tomoaki_Mizushima, Zoltan_Kis, Kevin_Olotu
Regrets
Chair
Sebastian
Scribe
Koster
Contents
* [2]Topics
1. [3]Review of the previous minutes
2. [4]GitHub repo reorganization
3. [5]Issue #889
4. [6]Async API review
5. [7]Issue #890 keywords for async actions
6. [8]TD templates
* [9]Summary of Action Items
* [10]Summary of Resolutions
__________________________________________________________
<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> [11]Readme updated
[11] https://github.com/w3c/wot-thing-description/blob/master/README.md
Sebastian: also cleaned up old branches that were already
merged
<sebastian> issue
[12]https://github.com/w3c/wot-thing-description/issues/889
[12] 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>
[13]https://cdn.statically.io/gh/w3c/wot-thing-description/min-
maxLength-json-schema/ontology/jsonschema.html
[13] 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
[14]https://github.com/w3c/wot-thing-description/issues/893
[14] https://github.com/w3c/wot-thing-description/issues/893
<sebastian> [15]https://www.asyncapi.com/
[15] https://www.asyncapi.com/
<zkis>
[16]https://www.asyncapi.com/docs/getting-started/coming-from-o
penapi/
[16] https://www.asyncapi.com/docs/getting-started/coming-from-openapi/
<sebastian>
[17]https://www.asyncapi.com/docs/getting-started/coming-from-o
penapi/
[17] https://www.asyncapi.com/docs/getting-started/coming-from-openapi/
<Ege>
[18]https://www.asyncapi.com/docs/specifications/2.0.0/#definit
ionsProtocol
[18] https://www.asyncapi.com/docs/specifications/2.0.0/#definitionsProtocol
<Ege>
[19]https://github.com/fmvilas/asyncapi-websockets-example/blob
/master/asyncapi.yaml
[19] https://github.com/fmvilas/asyncapi-websockets-example/blob/master/asyncapi.yaml
<sebastian> issue
[20]https://github.com/w3c/wot-thing-description/issues/890
[20] 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> [21]https://www.w3.org/TR/REC-smil/smil-timing.html
[21] 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> [22]Issues with "TD Template" label
[22] https://github.com/w3c/wot-thing-description/labels/TD Template
<mlagally_>
[23]https://github.com/w3c/wot-architecture/blob/master/REQUIRE
MENTS/thing-templates.md
[23] 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> [24]wot-architecture issue 454
[24] https://github.com/w3c/wot-architecture/issues/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> [25]Issue 897
[25] https://github.com/w3c/wot-thing-description/issues/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> [26]https://github.com/eclipse/vorto
[26] 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
[27]https://github.com/t2trg/wishi/wiki/Agenda-items
[27] https://github.com/t2trg/wishi/wiki/Agenda-items
[adjourned]
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [28]scribe.perl version
1.152 ([29]CVS log)
$Date: 2020/04/27 09:08:27 $
[28] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[29] http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 13 May 2020 09:02:39 UTC