- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 11 Jan 2021 15:09:29 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2020/12/09-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/
WoT-WG - TD-TF
09 Dec 2020
[2]Agenda
[2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Thing_Description_WebConf#December_9.2C_2020
Attendees
Present
Kaz_Ashimura, Daniel_Peintner, Michael_Koster,
Sebastian_Kaebisch, Taki_Kamiya, Tomoaki_Mizushima
Regrets
Chair
Sebastian
Scribe
mjkoster
Contents
* [3]Topics
1. [4]Agenda
2. [5]Review of minutes from December 2nd
3. [6]PR for the webpage TF description
4. [7]Issues for TD 2.0
5. [8]Binding templates
6. [9]Binding template for new bindings
7. [10]TD issues
8. [11]Issue #1007
9. [12]Issue #800
* [13]Summary of Action Items
* [14]Summary of Resolutions
__________________________________________________________
<kaz> scribenick: mjkoster
Agenda
<Ege> [15]https://github.com/w3c/wot-binding-templates/pull/105
[15] https://github.com/w3c/wot-binding-templates/pull/105
Ege: additional topic for today above
Review of minutes from December 2nd
<kaz> [16]Dec-2
[16] https://www.w3.org/2020/12/02-wot-td-minutes.html
PR for the webpage TF description
<kaz> [17]wot-marketing PR 100
[17] https://github.com/w3c/wot-marketing/pull/100
Sebastian: OK to merge?
no objections, PR #100 merged
<Ege> door rang, brb
Issues for TD 2.0
<inserted> [18]Issues to be deferred to 2.0
[18] https://github.com/w3c/wot-thing-description/labels/Defer to TD 2.0
Sebastian: labeled issues to defer to 2.0. are there any
features that are labeled 2.0 that should be brought into 1.1?
Binding templates
PR #105
<kaz> [19]wot-binding-templates - PR 105
[19] https://github.com/w3c/wot-binding-templates/pull/105
Ege: missing curly brackets in the example
merged #105
Binding template for new bindings
<kaz> [20]Binding Templates Editor's Draft
[20] https://w3c.github.io/wot-binding-templates/
Sebastian: how does one add a new protocol binding?
... what is the minimum information that is needed to specify
the binding?
... we should restructure the document to add a section for
required items
Ege: maybe only the examples are problematic
Sebastian: the point is that the information about how to
construct a binding is not in one place
... e.g. a vocabulary is needed, subprotocols defined, etc.
... as an example, URL specifications include RFC3986 plus
additional specifications for specialized types
<Ege>
[21]https://w3c.github.io/wot-binding-templates/ontology/mqtt
[21] https://w3c.github.io/wot-binding-templates/ontology/mqtt
<inserted> koster: good timing to think about how to deal with
various possible protocols
Kaz: there could be a best practices appendix
Sebastian: there could be a document that describes the generic
actions, events, properties and design considerations
... this is being discussed how to implement OPC UA interfaces
in TD
reviewing PR #104
<Ege> door rang, brb
<Ege>
[22]https://github.com/eclipse/thingweb.node-wot/issues/297
[22] https://github.com/eclipse/thingweb.node-wot/issues/297
<kaz> [23]wot-binding-templates PR 104
[23] https://github.com/w3c/wot-binding-templates/pull/104
<kaz> [24]wot-binding-templates PR 98
[24] https://github.com/w3c/wot-binding-templates/pull/98
Sebastian: pointer to example modbus binding
Koster: sdf model for modbus is just the data formats in the
communication layer
Sebastian: maybe the modbus binding is a good first example for
modular binding specs
Koster: there are data model issues with e.g. modbus bindings
like multiple data set definitions
Sebastian: resolved to start working on a modular binding
document format
Koster: will spend some time - up to 4 hrs weekly
Daniel: Christian Glomb may be available?
Koster: we can work back from the example to the template
Sebastian: hope we can define a good set of bindings
<inserted> [25]Issue 991
[25] https://github.com/w3c/wot-thing-description/issues/991
Sebastian: other discussion on bindings?
Ege: http vocabulary issue #991
... information in forms fields are for both the thing and for
the consumer of the thing
... how do we indicate what is to be expected in the response?
<kaz> [26]5.3.4.2 Form
[26] https://w3c.github.io/wot-thing-description/#form
Sebastian: you would declare a response for content type
... we also need response header information
... is there a concrete example?
... this should be defined in the binding document
Ege: what is the agreement wrt optional items?
Sebastian: ExpectedResponse is a container that we could add
more terms to
... moved the issue to the binding repository
TD issues
issue #303
<trackbot> Sorry, but no Tracker is associated with this
channel.
<kaz> [27]Issue 303
[27] https://github.com/w3c/wot-thing-description/issues/303
error conditions for forms
Sebastian: it could work like HTTP with codes like 400
... a code and a string message
Ege: like to openAPI showing how input and output are linked
... separate response codes and separate schemas
<Ege> [28]Responses Object
[28] https://swagger.io/specification/#responses-object
Ege: TD can't describe multiple possible responses to an
interaction
Koster: normally a response will return the expected output
schema, but some protocols can have other responses, like erros
or redirects
Sebastian: also responses can include pointers as in hypermedia
protocols
Ege: may need other terms besides input and output, e.g. query
and error
Sebastian: where do we define the payload?
Daniel: we need to provide for a response extension for each
form, not necessarily per interaction
Sebastian: does Ben provide any concrete examples?
... follow up note on the issue
Issue #1007
<kaz> [29]Issue 1007
[29] https://github.com/w3c/wot-thing-description/issues/1007
Sebastian: json schema is not as strict on allowed terms for
validation constraints, e.g. allows "maximum" for arrays and
ignores it
... should we relax our validator?
Ege: the concern is that a stricter json schema validator would
fail a TD that was validated by TD tools
Daniel: not sure it would ever be an issue in practice
Ege: OK to close
Issue #800
<kaz> [30]Issue 800
[30] https://github.com/w3c/wot-thing-description/issues/800
multiple properties
Sebastian: propose to include only observeallproperties in TD
1.1
Daniel: what happens when you observeallproperties, then
unobserve a single property?
Koster: difficulties arise because there isn't a data model
element for all properties
Sebastian: it would be OK to include observeall and
unobserveall
Daniel: the meaning needs to be specified more thoroughly
Ege: agree
Sebastian: maybe observerall should be defined as an separate
process
... in parallel able to subscribe to individual properties
... ignore unsubscribes to properties that were not
individually subscribed to
Daniel: there could be undesired interactions
Koster: all needs to be modeled as a separate resource if both
individual and all are expected to be available simultaneously
Daniel: agree
Sebastian: yes, some separation is needed
... will prepare a PR for further discussion
Kaz: please include some concrete use cases
... if we remove features, put them into a section for obsolete
features
Sebastian: OK
... close for today, continue the discussion next week
... last meeting of the year on December 16
... next meeting of the new year Jan 13th
... adjourn
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [31]scribe.perl version
1.152 ([32]CVS log)
$Date: 2021/01/11 06:07:54 $
[31] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[32] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 11 January 2021 06:09:35 UTC