<kaz> scribenick: mjkoster
<Ege> https://github.com/w3c/wot-binding-templates/pull/105
Ege: additional topic for today above
<kaz> Dec-2
<kaz> wot-marketing PR 100
Sebastian: OK to merge?
no objections, PR #100 merged
<Ege> door rang, brb
<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?
PR #105
<kaz> wot-binding-templates - PR 105
Ege: missing curly brackets in the example
merged #105
<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> 5.3.4.2 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
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
<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
<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