- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 17 Feb 2020 18:29:19 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2020/02/07-wot-td-minutes.html
also as text below.
Thanks a lot for taking the minutes, Michael Lagally and Ege!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WoT-WG - TD-TF
07 Feb 2020
[2]Agenda
[2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Thing_Description_WebConf#Agenda
Attendees
Present
Kaz_Ashimura, Sebastian_Kaebisch, Taki_Kamiya,
Daniel_Peintner, Michael_Lagally, Klaus_Hartke,
Ryuichi_Matsukura, Tomoaki_Mizushima, Michael_Koster,
Zoltan_Kis
Regrets
Chair
Sebastian
Scribe
mlagally, ege
Contents
* [3]Topics
1. [4]Agenda
2. [5]Review of previous minutes
3. [6]Proposed Recommendation
4. [7]New Issue (Daniel)
5. [8]Issue: 302
6. [9]TD Payload Pattern
* [10]Summary of Action Items
* [11]Summary of Resolutions
__________________________________________________________
<mlagally> scribenick: mlagally
Agenda
Sebastian: Approval of last minutes
<kaz> [12]Jan-24 minutes
[12] https://www.w3.org/2020/01/24-wot-td-minutes.html
(Sebastian walks through the agenda)
Review of previous minutes
Sebastian: let's review agenda from last meeting (Jan 24th)
<kaz> [13]Jan-24 minutes
[13] https://www.w3.org/2020/01/24-wot-td-minutes.html
(Sebastian walks through the minutes, does a recap)
Sebastian: any objections to go public?
... hearing none, they are approved
Proposed Recommendation
Sebastian: kaz, what's the process, in one month it will be
REC.
... we have some highlighting issues in the examples, can we do
some editorial changes?
Kaz: this is under AC review, all AC reps are asked to review
this as well as the architecture spec
... people are requested to provide comments on the mailing
list
... cannot add normative changes to those specs any more
... however editorial changes can still be done
Sebastian: We have highlighting issues, perhaps we have no
longer valid JSON, we need to find out the reason
Daniel: there was an issue raised by respec developers that
some parts are breaking, there's a PR for this (872)
... the preview looks a bit weird, there are respec issues
... (Shows Example 1, which is broken)
<kaz> [14]PR 872
[14] https://github.com/w3c/wot-thing-description/pull/872
Daniel: Kaz, can we keep the old version
... the filer of the issue presented the respec changes at TPAC
Lagally: Kaz, do we have the same problem in the Architecture
spec?
Kaz: I can look into this issue and the PR. However, we don't
have to care about problems with respec but can concentrate on
the static version for our next publication as RECs
Sebastian: perhaps we fix the highlighting manually
... btw, could you remind me of the URL of the AC vote?
Kaz: the announcement about the AC vote was sent out to the AC
members list, and it includes the URL of the AC review form.
<inserted> [15]AC announcement (Member-only)
[15] https://lists.w3.org/Archives/Member/w3c-ac-members/2020JanMar/0010.html
New Issue (Daniel)
<sebastian> [16]Issue 877
[16] https://github.com/w3c/wot-thing-description/issues/877
Daniel: In the scripting API we would like to specify how
people can indicate which binding to chose, if there are
multiple options
... currently we select from top to bottom
... the TD does not offer a way to specify
Lagally: what does preference exactly mean, hard or soft
preference?
Daniel: it is just a soft preference
Zoltan: if we state the order as a preference, this is enough
Daniel: technically there's no change required, there is no
change required
... one statement in the spec is enough
Sebastian: is there a use case?
... when we started, we had a numbering for protocol picking.
We removed it because we found no real use case
... the client can pick his preferred protocol
... if a server offers multiple protocols, it is up to the
client
Zoltan: this is an implementation thing where this choice has
to be made
Lagally: if we have multiple TDs with different orders, they
offer the same contract and should be functionally equivalent
Sebastian: Let's consider an example: if I can offer an observe
mechanism vs. long poll, it is more efficient
Ege: we can also think outside protocols, if the content type
is different
... what happens if alternatives are not equivalent ?
... for longpoll and observe there could be different forms
depending on the op
Koster: if a client knows what op to do, it picks the form for
that op
... ordering would work, but there's also protocol negotiation
pattern in HTTP
... queue(?) values, I never used them
... relying on a serialisation format, you may have a different
order based on a serialisation format
... what would people actually use?
... does the server always really know the best option?
... the client can always override
... would that really be used?
Taki: in most cases, the server side does not have a preference
... if there are multiple choices from the server, there is no
preference. Client needs to make the decision.
Lagally: I can see one use case: if there is a preferred higher
security on certain operations, the preference would be useful
Issue: 302
Sebastian: actions can be asked about the status (still runing,
finished)
<inserted> [17]Issue 302
[17] https://github.com/w3c/wot-thing-description/issues/302
Sebastian: also actions can be deleted
... question is whether to introduce it in the TD
... there's a long discussion, Ege can you give a short review
of the comments?
<ege> [18]https://github.com/w3c/wot-binding-templates/issues/2
[18] https://github.com/w3c/wot-binding-templates/issues/2
Ege: The issue is very old, it was the 2nd issue in the binding
template issues
... request can start an action, before it actually is
finished, e.g. fading a light, closing blinds, moving a robot
to a different location
... Mozilla stated, that this is currently not supported in the
TD
... In their case the response contains hypermedia links to
query status or cancel the operation
... how can we describe such a mechanism in the TD, there's a
proposal by Victor
... output returns an object with href and status
... href contains an @type annotation for managing the actions
... urivariables provide the information about links to these
operations.
... there are operations "cancel" and "query"
... I commented that there are actions that never stop, e.g. a
conveyor belt
... that continues running until it is stopped
... a stop movement can impact all other onging actions, there
are real use cases
... some TDs modeled this via properties
... this should be an action
Zoltan: such action could return a thing, this has beed
discussed several times and there were objections
Lagally: We should not impose a new format on existing
implementations, i.e. we need to describe existing systems
... Oracle already has a deplyoed System, Mozilla too, we
cannot ask for a change of the implementation
Koster: if we can come up with a pattern that returns a TD, a
different content type,, or some other payload content
... we must be able to describe an existing system
<sebastian>
[19]https://github.com/w3c/wot-thing-description/issues/302
[19] https://github.com/w3c/wot-thing-description/issues/302
Sebastian: hypermedia is not really standardized, there's no
common way for responses, this is open for any systems
... In HTTP and CoAP you have location in the header, I'm not
aware if people actually use that
... this is a very specific technique for these protocols
... there may be very different other ways
... i'm not sure we are able to describe this protocol behavior
in the TD
Koster: We had some discussion around protocol bindings, we
cannot describe all mechanisms, however can describe a state
machine
... the client can follow that, the TD does not specify all
implementation patterns
... can we design an abstraction for commonalities?
... we have to able to adapt, there was a discussion in the
architecture group
... we have to support all the ops, we may have optional ops
Lagally: This comes back to interoperability vs. describing all
possible existing devices
... this comes down to having a profile with a minimum set of
guarantees between client and thing
Koster: I agree, some TDs may have operations that are optional
... maybe we can trade off by having different TDs with
different OPs, like HTTP vs CoAP, the client may know what to
do based on the protocol
Klaus: For encoding in TD, do we assume knowledge about
behavior of the thing
... if yes, you just include the name of the pattern, otherwise
you need a detailed language in the TD
... Otherwise you have to describe the hypermedia state machine
... This pattern of asynchronous actions is very relevant
... would like to have support in the TD
... we have physical actions and protocol actions, we start
thinking with 1:1 mapping, however going forward an app may use
one action to affect multiple ongoing actions
Sebastian: do we want to teach the clients what is hypermedia
or is it just a singaling that hypermedia is used
... TDs should support both, i.e. indicate that hypermedia is
used and to describe the pattern
... Mozilla has a specific pattern, however they do not specify
it in the TD
Koster: there's an entry point in the TD, there could be a
content format to describe the details
... that would be interoperable
... Klaus can show us some ideas for the content format
... protocol bindings get much easier with LWM2M
... client knows what to do
Sebastian: Does LWM2M use Hypermedia?
Koster: they use links, but no dynamic hypermedia
Sebastian: would lie to see examples of impelemtations, e.g.
Oracle
ML: I will add more information to the issue
Sebastian: we should have implementatinos on the table
... we have this idea from Lagally about the profile, default
assumptions about hypermedia
Lagally: does it make sense to look into Mindsphere?
Sebastian: I will check
Klaus: In T2TRG we have areference device(coffee machine) where
you can make coffee orders. We're using hypermedia
Sebastian: Klaus, can you please provide more info?
Klaus: yes
Sebastian: these devices (Oracle, Mindsphere, Mozilla, Coffee
Machine) should also be considered for the Helsinki plugfest
Kaz: We should consider this in the plugfest call as well
Sebastian: We need a draft proposal
Kaz: starting with a survey of existing implementations is good
Taki: In the proposal there was query and cancel, when action
is in process we may not be able to cancel
... best we can do is stop the action, do something else. We
may not be able to go back to the original state
Sebastian: Are you asking for a clear definition of cancel?
Taki: yes
Kaz: maybe we can have a specific session with session rollback
capability, but that might be too advanced. so I'd agree with
Sebastian that we should start with initial survey and
proposals
TD Payload Pattern
[20]Sebastian's slides
[20] https://www.w3.org/WoT/IG/wiki/images/0/04/TD_Payload_Pattern.pdf
<kaz> scribenick: ege
Sebastian: motivation is that IoT systems already come with a
message pattern
... ikea comes with the payload structure shown in the slide
with these integers denoting different meanings
<klaus>
[21]https://github.com/OpenMobileAlliance/lwm2m-registry/blob/t
est/3311.xml
[21] https://github.com/OpenMobileAlliance/lwm2m-registry/blob/test/3311.xml
klaus: these integer values come from LwM2M
Koster: I also have TDs like that
... OCF has the same things as well
Sebastian: it looks like this in the scripting level
... would be better if we can have more human readable in the
scripting level
... defining message template or application paramaters which
are passed to the scripting level
... we can also define them in a global way
Koster: I have used the tag defined in iot schema
Sebastian: how do you do the parameters in the programming
level?
Koster: I use the full URIs defined in iotschema
... I have something that can bring them up as a flat JSON
object
... also using it in the global level?
Ege: so you would tag an interaction affordance with e.g.
MessageTemplate and you would be able to refer to that
Lagally: what if you don't have the tags?
Sebastian: you would use it just as a normal TD
Koster: different platforms can have different meanings of
transition time for example
Sebastian: Even if we annotate, the payload does not change
... so only when programming it takes effect
... using semantic annotations would be nice here
Lagally: I am wondering what the client should do
Sebastian: I am interested in approach of mk
... @type can be used for any protocol etc.
<kaz> [adjourned]
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [22]scribe.perl version 1.154 ([23]CVS log)
$Date: 2020/02/17 09:26:56 $
[22] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[23] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 17 February 2020 09:29:27 UTC