- 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