<kaz> scribenick: kaz
Taki: no problem, so let's approve the minutes
Taki: the basic schedule
discussed
... tentatively, March 17 9am EST
Ege: typo within the schema
definition at Appendix B
... "subProtocol" to be fixed as "subprotocol"
Taki: (goes through the
changes)
... can we fix it?
Kaz: given it's typo fixing, we should do it
Taki: any objections?
(none)
Taki: (merges PR 879)
Kaz: I gave a comment, and the
ReSpec developers have updated their PR and propose to fix the
index.template.html instead of index.html
... on the other hand, we might want to concentrate on the
static HTML version without ReSpec for upcoming REC
publication, and apply this change to the 2nd-gen spec
Taki: right
... (adds a comment about our plan)
Daniel: what do you mean by the "Recommendation" and "next version"?
Kaz: I think we should think
about how to manage the HTML source for the new specs as well
as this ReSpec issue
... possibly we can continue to use the current
"wot-thing-description" for ver. 2.0 (or ver. 1.1)
... but it might be clearer to use another repo like
"wot-thing-description-11" or "wot-thing-desription-20"
... can create a GitHub issue about that point
Lagally: wondering about the effect for the Architecture document
Daniel: seems no effect to "wot-architecture" (URL below)
Ege: Initial connection
... MQTT or AMQP has some specific assumption of connection to
a broker
... while websockets not
... how can we describe it?
Lagally: does this kind of connection happen each time?
Ege: if you change the network, socket connection is destroyed
Lagally: asking about the context of
lifecycle
... we need to consider that
... the term and concept of "session" is important here
... there could be multiple sessions
Zoltan: can we describe the expected action for each case?
Kaz: I think we should clarify
the use cases and the requirements within the Binding TF a bit
more
... maybe we should think about the binding template part and
the TD part separately
... we should clarify how to deal with sessions using various
connection protocols first
... and then think about how to map them with TD's interaction
affordance
Ege: yeah
Taki: there are possibly many ways
to describe it
... so we should think about which would be the best
Daniel: we have some freedom
here
... so let's pick websocket as an example
Kaz: this discussion is related to the lifecycle state transition discussion during the architecture call
Lagally: yeah, would help us understand it more if we think about this during the next architecture call
Kaz: we should describe some specific use case for that discussion
Lagally: Ege, do you think you could describe concrete sequence diagram for that discussion?
Ege: yes, will do
Kaz: and can you join the next architecture call?
Lagally: every Thursday, 8am/5pm CET
Ege: ok, will join the 5pm CET session then
Taki: read-only/write-only
behavior
... wanted to check the status of this issue
... the text referred to might be a bit obsolete?
Lagally: the language is not really
precise, is it?
... "state must be retrievable"
Taki: the latest draft just have
"writeOnly"
... but it's true the current statement "This state can then be
retrieved (read) and optionally updated (write)." implies both
read and write
Lagally: we could be more explicit
Taki: (adds comments to Issue 854)
Kaz: just a quick question
... what should we do when we want to prohibit the property to
be even retrieved?
Taki: that is the intention of "writeOnly"
Kaz: can we use "unobserveproperty", for example?
Daniel: "observeproperty" and "readproperty" are different
Lagally: maybe we might want to clarify the mechanism here
Zoltan: theoretically we should have
all of "readable", "writable" and "observable" separately
... we had them separately at some point but may have been
removed
<Ege> https://github.com/w3c/wot-thing-description/issues/810
Ege: related issue 810 above
Taki: please create a new issue about your point, Kaz
Kaz: will do
<scribe> ACTION: kaz to create a new issue on how to permit/prohibit reading property
<scribe> scribenick: dape
Taki: Any update?
... last week we were asked to create use-cases
... ML provided uses cases as well as Ege
... issue with synchronous vs. asynchronous
... suggest to continue discussion on Github
Taki: talked about it last week
also
... relates to scripting API. issue 193
... we still need to describe it in TD spec
... suggest to continue the discussion on Github to finalize
the solution
Taki: about "desired" form
... recent comment about NOT changing form entry order
Zoltan: MMC said that clients can
choose form, however implementation should not change order to
allow for later to introduce this mechanism
... implicit policy to pick first in order
... should there be a text in TD describing such a policy?
Taki: Open question
Zoltan: Such a text is not limiting, client can still choose either one
<Ege> https://github.com/w3c/wot-binding-templates/issues/92
Ege: would like to discuss
https://github.com/w3c/wot-binding-templates/issues/92
... talks about next protocol. Feedback from more people would
be needed
... I listed some "possible" protocols
... Besides that no big items to work on
... would work on some updates
Taki: Fujitsu would like to see work on Echonet
Ege: Great. Could you/Matsukura-San add comment
Taki: Yes, will check internally and leave comment
Ege: My interest is ROS
... middleware for robots (XML RPC)
... API is specific with subprotocol
... OPC-UA, there is binding coming for node-wot
Daniel: Suggest talking with MCCool and Zoltan about OCF
Ege: open issue in Bindings with
describing payload of specific platform
... e.g. Ikea and OCF
... No 'real' news/updates besides MQTT issues
... propose and request input for issue 92
... CBOR issue in node-wot seems related
Daniel: Yes, ROS and XML is good example
Taki: Question: We published Binding templates W3C note. Going forward do we continue to update the note?
Ege: Yes
Taki: My concern is that updating document, looking at TD version 1.1, do we link snapshot?
Daniel: using dated URI
<Ege> https://www.w3.org/TR/2020/NOTE-wot-binding-templates-20200130/
Taki: I see, should make sure TD uses this URIs. Thanks!
Ege: Everyone, please prvide input to issue #92
<kaz> [adjourned]