09 Dec 2020



Kaz_Ashimura, Daniel_Peintner, Michael_Koster, Sebastian_Kaebisch, Taki_Kamiya, Tomoaki_Mizushima


<kaz> scribenick: mjkoster


<Ege> https://github.com/w3c/wot-binding-templates/pull/105

Ege: additional topic for today above

Review of minutes from December 2nd

<kaz> Dec-2

PR for the webpage TF description

<kaz> wot-marketing PR 100

Sebastian: OK to merge?

no objections, PR #100 merged

<Ege> door rang, brb

Issues for TD 2.0

<inserted> Issues to be deferred to 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> wot-binding-templates - PR 105

Ege: missing curly brackets in the example

merged #105

Binding template for new bindings

<kaz> Binding Templates Editor's Draft

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> 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> https://github.com/eclipse/thingweb.node-wot/issues/297

<kaz> wot-binding-templates PR 104

<kaz> wot-binding-templates PR 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> Issue 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> 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> Issue 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> 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> Issue 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> Issue 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 scribe.perl version 1.152 (CVS log)
$Date: 2021/01/11 06:07:54 $