IRC log of wot-arch on 2021-01-21

Timestamps are in UTC.

15:00:50 [RRSAgent]
RRSAgent has joined #wot-arch
15:00:50 [RRSAgent]
logging to https://www.w3.org/2021/01/21-wot-arch-irc
15:02:17 [mlagally]
mlagally has joined #wot-arch
15:02:26 [dape]
dape has joined #wot-arch
15:02:30 [kaz]
Meeting: WoT Architecture
15:02:45 [kaz]
present+ Kaz_Ashimura, Michael_Lagally
15:05:34 [kaz]
present+ Michael_Koster, Ben_Francis, Tomoaki_Mizushima, Michael_McCool
15:05:55 [McCool]
McCool has joined #wot-arch
15:06:16 [Mizushima]
Mizushima has joined #wot-arch
15:07:52 [kaz]
scribenick: McCool
15:08:29 [mjk]
mjk has joined #wot-arch
15:08:32 [McCool]
agenda:https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf
15:08:37 [McCool]
topic: minutes review
15:08:58 [McCool]
https://www.w3.org/2020/12/17-wot-arch-minutes.html
15:09:09 [cris]
cris has joined #wot-arch
15:09:48 [McCool]
ml: last week had discussion of terminology around TD fragment, partial TD, defined some actions
15:10:03 [McCool]
... cristiano and daniel to provide draft PRs
15:10:15 [McCool]
ml: any objections to publication?
15:10:23 [McCool]
... hearing none, will be published.
15:10:34 [McCool]
topic: FPWD feedback
15:10:52 [kaz]
s|https://www.w3.org/2020/12/17-wot-arch-minutes.html|https://www.w3.org/2021/01/14-wot-arch-minutes.html|
15:11:00 [McCool]
ml: we did resolve amny comment prior to FPWD, but have gotten more since
15:11:08 [McCool]
... we should review and resolve
15:11:36 [McCool]
... we do want to make sure the document makes progress and becomes useful in the next month or two
15:11:46 [McCool]
... it has many gaps and contentious items
15:12:02 [McCool]
... we ultimately want to get a document that helps the market
15:12:45 [McCool]
... and not just "one more IoT specification" but something that is easy to understand and adopt and solves real interop problems
15:13:25 [McCool]
q+
15:14:56 [McCool]
mm: I would like to propose that if there is a contentious but non-essential feature we should just take it out for now
15:15:06 [McCool]
... the main goal is interop and we should focus on that
15:15:30 [McCool]
ml: we we have two PRs and 37 issues
15:16:08 [mlagally]
https://github.com/w3c/wot-profile/pull/62
15:16:29 [kaz]
present+ Cristiano_Aguzzi
15:16:34 [McCool]
ml: this PR just catches up the editors' version to changes needed for FPWD
15:16:47 [McCool]
... propose merging, not controversial
15:16:55 [McCool]
ml: (merges PR 62)
15:17:03 [kaz]
rrsagent, make log public
15:17:07 [kaz]
rrsagent, draft minutes
15:17:07 [RRSAgent]
I have made the request to generate https://www.w3.org/2021/01/21-wot-arch-minutes.html kaz
15:18:27 [kaz]
Chair: Lagally
15:18:29 [McCool]
ml: next PR is canonical representation; will not look at that right now
15:18:46 [McCool]
mm: however, it would be helpful to link the related issue, which I hope is also linked to issues in the TD repo
15:18:47 [kaz]
s/amny/many/
15:19:14 [kaz]
s/FPWD feedback/FPWD feeback - PR 62/
15:19:15 [McCool]
topic: FPWD feedback
15:19:25 [McCool]
ml: they have been labelled in the repo
15:19:53 [mlagally]
https://github.com/w3c/wot-profile/issues/59
15:20:36 [McCool]
https://github.com/w3c/wot-profile/labels/FPWD%20Feedback
15:20:54 [McCool]
ben: see there are two main goals which are a bit in conflict
15:21:05 [kaz]
s|https://github.com/w3c/wot-profile/issues/59||
15:21:14 [McCool]
... one is about readabilty, the other about interop
15:21:20 [kaz]
i|see|-> https://github.com/w3c/wot-profile/issues/59 Issue 59|
15:21:24 [McCool]
... and there is also the issue of protocols
15:21:57 [McCool]
... suggest perhaps a "core" profile that supports HTTP and JSON and a constrained one that supports CoAP (and CBOR?)
15:22:38 [McCool]
ml: currently looking at "data model" constraints, then constraints on particular protocol bindings
15:22:48 [McCool]
q+
15:25:38 [McCool]
mm: so want to +1 what ben and ml said
15:25:57 [McCool]
... and note that I think we all agree the data model is central
15:25:59 [mjk]
what do we mean when we say "readability"?
15:26:21 [McCool]
... and data+http maps onto what ben is calling "core", and data+coap maps onto "constrained"
15:26:34 [McCool]
... we can argue about names, but conceptually we are on the same page
15:26:53 [McCool]
... and as for goals, I agree with ben that human readable + interop can be in conflict
15:26:54 [mjk]
so , descriptive variable names?
15:27:01 [McCool]
... and I propose we get interop done first
15:27:20 [McCool]
... then go back and see what we can do to improve interop
15:28:27 [kaz]
present+ Sebastian_Kaebisch
15:28:29 [mjk]
embedded documentation strings?
15:28:33 [McCool]
mm: I also think documentation makes more sense to be mandatory in the Thing Model
15:29:13 [McCool]
... so maybe what we should do is make a link the *model* mandatory
15:29:35 [McCool]
... and make documentation mandatory in the thing model
15:30:13 [McCool]
mjk: so I'd like to understand this better
15:30:35 [McCool]
ml: can you comment on what you felt was controversial
15:30:46 [McCool]
ben: so human-readable means strings, sent over the wire
15:31:00 [McCool]
... but constrained devices need a very compact, binary form
15:31:10 [McCool]
... and these are conflicting requirements
15:31:24 [McCool]
mjk: ok, I think it is what I thought
15:31:38 [McCool]
... so, titles, and descriptions, and also JSON vs. CBOR
15:31:45 [McCool]
... JSON is definitely easier to read
15:32:00 [McCool]
ben: also complexity of data structures
15:32:15 [McCool]
... lots of nesting is a problem for constrained devices
15:32:30 [McCool]
... if we limit depth, it can make it harder to read
15:33:14 [McCool]
mjk: making TD lightweight and putting docs in TM makes sense
15:33:36 [McCool]
... but yes, for constrained devices, just using numerical IDs for variable names makes sense
15:33:41 [McCool]
q+
15:35:14 [McCool]
mm: I think a compromise might work, for nesting, eg. 4 to 16
15:35:27 [McCool]
ben: there is the issue that that might not satisfy anyone
15:35:45 [McCool]
mjk: well, 1 is at the extreme end, flattens everything
15:35:57 [McCool]
... but the observation is that 2-3 is the natural limit
15:36:28 [McCool]
... what people want to do is have a variable name that refers to a single struct
15:36:31 [McCool]
q+
15:37:48 [kaz]
-> https://w3c.github.io/wot-profile/#thing WoT Profile Editor's Draft - 5.1.2 Thing
15:38:33 [McCool]
mm: there are several cases where we do want some nesting, eg for modularity, to make queries easy
15:38:39 [McCool]
... so 4 seems safe
15:38:55 [McCool]
ml: I'd like to propose 5 just to be safe.
15:39:46 [McCool]
mm: I'd like to say recommended practice is 4, and validator starts giving warnings when you are at 5
15:40:08 [McCool]
mjk: constrained profile should be good enough for devices that are bluetooth/zigbee class
15:40:21 [McCool]
... but I would expect a gateway to have both
15:40:22 [McCool]
q+
15:41:06 [McCool]
mjk: gateway may be acting as a proxy for constrained devices and so would be good to support
15:41:54 [McCool]
mm: so is the constrained a strict subset of core, or separate? We need to decide
15:41:55 [mlagally]
proposal: max depth of data schema is max 5, recommended practice is not to exceed 4.
15:42:10 [McCool]
ml: I think we should also focus on the data model, that definitely is common
15:42:32 [mlagally]
proposal: common data model - max depth of data schema is 5, recommended practice is not to exceed 4.
15:43:57 [McCool]
ben: do think we are on a bit of a tangent right now
15:44:04 [McCool]
... and want to get back to the original issue
15:44:20 [McCool]
... I do agree that if there are two profiles they should have a common data model
15:44:37 [McCool]
... but I think the TD already does that, and perhaps we should improve the TD spec
15:45:10 [McCool]
ml: not skipping over your comments, just capturing a consensus so we can make progress
15:45:34 [McCool]
q+
15:47:10 [McCool]
mm: think we should capture this consensus, then get back to ben's split profiles
15:47:17 [mlagally]
resolution: common data model - max depth of data schema is 5, recommended practice is not to exceed 4.
15:47:30 [McCool]
ml: ok, let's go back
15:47:46 [McCool]
q+
15:49:25 [McCool]
mm: some questions to ben: is core > constrained, or are they separate?
15:49:29 [McCool]
ben: separate
15:49:37 [McCool]
mm: and can a gateway support both?
15:49:40 [McCool]
ben: yes
15:49:53 [McCool]
mm: in which case the common elements need to be aligned
15:50:07 [McCool]
ben: so doing the same thing, but with different protocols
15:50:25 [McCool]
mjk: so really these aspects should be completely handled by protocol bindings
15:51:07 [McCool]
ml: issue is that protocols are designed to support a lot of different options even within a single protocol
15:51:29 [McCool]
... so we need additional constraints even within a protocol
15:51:35 [McCool]
q+
15:52:10 [McCool]
mm: I think a profile is in fact prescriptive
15:52:34 [McCool]
ben: agree; point of profile is to be prescriptive for greenfield devices
15:52:44 [McCool]
... so they are guaranteed to interop
15:53:01 [McCool]
ml: and if we do our job well, will still cover 80% of brownfield devices
15:53:23 [McCool]
mjk: there could be a slight middle ground when there are only a small number of options
15:53:53 [McCool]
ben: would not suggest getting rid of the TD altogher, but the more we prescribe the smaller the TD can be
15:54:21 [sebastian]
sebastian has joined #wot-arch
15:55:12 [McCool]
q+
15:56:23 [McCool]
ml: so getting back to the issue, since we don't have a volunteer for CoAP, I propose we focus on HTTP
15:56:32 [McCool]
q?
15:57:01 [mjk]
q+
15:57:14 [sebastian]
q+
15:57:32 [McCool]
mm: agree that we should focus on http for now, as long as we leave room for adding coap later.
15:57:55 [McCool]
ben: sure, as long as any profile has at least one protocol
15:59:00 [McCool]
mjk: does that mean that if I wanted to build a constrained device that supporte the "core" profile, it would have to support http?
15:59:03 [McCool]
q+
15:59:46 [McCool]
mjk: beyond the protocol binding there is also the issue of construction of payloads
16:00:08 [mjk]
ack m
16:00:14 [McCool]
ben: my understanding is the protocol binding says what the payload format is
16:00:28 [McCool]
ben: producer and consumer need to have a common understanding
16:01:29 [mjk]
mm: the gateway use case can inform how the core + protocols work together
16:01:31 [McCool]
mm: core does not mean everyone has to support it
16:01:39 [McCool]
... it's just the "http" profile
16:01:57 [mjk]
ben: a mobile app is a good use case for both direct connect and app interaction
16:02:05 [McCool]
... and I think we should focus on the gateway use case
16:02:06 [McCool]
q?
16:02:09 [McCool]
ack m
16:02:36 [mjk]
sebastian: concerned with the name "constrained profile" as being too broad
16:02:51 [McCool]
seb: I have a concern about the "constrained" name as well, since there might be other protocols for devices, eq mqtt
16:03:02 [mjk]
sk: propose a structure where the core profile is a data model constraint
16:03:04 [McCool]
... I would like another approach to structure this
16:03:11 [McCool]
... make core all the common constraints
16:03:21 [McCool]
... then the other constraints are handled in the binding documents
16:03:30 [kaz]
i/the gateway/scribenick: mjk/
16:03:46 [kaz]
i/core does not/scribenick: McCool/
16:03:49 [McCool]
... make each binding document have a chapter defining constraints when used with the core profile
16:04:05 [kaz]
i/a mobile app is/scribenick: mjk/
16:04:08 [McCool]
... I would avoid trying to integrate all the protocol stuff here, since we have the binding documents
16:04:39 [McCool]
ml: I like this idea of taking out the data model first, and keeping the protocol binding separate
16:04:52 [kaz]
i/... and I think/scribenick: McCool/
16:04:53 [McCool]
... regardless of where we put it
16:05:04 [kaz]
s/... and I think/mm: and I think/
16:05:25 [McCool]
... and there are lots of things that are relevant to interop that needs to be handled in protocols, such as error codes
16:05:36 [mjk]
q?
16:05:36 [kaz]
i/concerned with the/scribenick: mjk/
16:05:36 [McCool]
... event handling, etc.
16:06:00 [kaz]
i/I have a concern/scribenick: McCool/
16:06:08 [McCool]
ben: I think we all agree on the core concepts, we just disagree on names and where the concepts are documented
16:06:24 [kaz]
i/propose a structure where/scribenick: mjk/
16:06:25 [McCool]
... it's just where those specs live that we are going backwards and forwards on
16:06:27 [McCool]
q?
16:06:28 [mjk]
q+
16:06:31 [McCool]
ack s
16:06:39 [kaz]
i/I would like another/scribenick: McCool/
16:06:55 [McCool]
ml: let's first make the spec, then figure out where it goes...
16:07:25 [kaz]
s/... I would like/sk: I would like/
16:07:42 [kaz]
rrsagent, draft minutes
16:07:42 [RRSAgent]
I have made the request to generate https://www.w3.org/2021/01/21-wot-arch-minutes.html kaz
16:07:49 [McCool]
ml: I also see a lot of issues coming up when trying to answer data model questions in protocol bindings
16:07:56 [McCool]
... so better to consolidate that
16:08:11 [McCool]
q+
16:08:36 [mjk]
ackm
16:08:39 [mjk]
ack m
16:08:46 [mjk]
q?
16:08:49 [mjk]
ack mjk
16:09:42 [McCool]
ben: right now protocol template is very general
16:10:38 [McCool]
mm: so... profiles are prescriptive, so what we want are "descriptive" specs (TDs, protocols bindings) with "prescriptive" subsets that guarantee interop
16:12:33 [McCool]
mjk: want to understand if profiles are a template...
16:12:58 [McCool]
ml: have to be concrete and something that we can check conformance of an implementation againts
16:13:40 [McCool]
mjk: we need to write down the constraints somewhere... so that is the profile spec?
16:13:59 [McCool]
ml: yes, a profile is conceptually the set of all constraints that guarantee interop
16:14:21 [McCool]
mjk: and we also need actual data models for particular devices
16:14:40 [McCool]
ml: out of scope, necessary, but look at everything under specific classes of devices
16:14:59 [McCool]
... for example, we probably want to specify the units to be used for measurements
16:15:56 [McCool]
ml: although there would be issues in insisting on metric, so we might have to have options, precedence orders, etc.
16:18:19 [McCool]
ml: (types up summary of discussion in https://github.com/w3c/wot-profile/issues/59
16:21:08 [McCool]
q?
16:21:30 [McCool]
mm: suggest for MQTT/COAP we ask those working on protocol bindings for these to address
16:21:43 [McCool]
seb: but agree that let's do HTTP first
16:22:27 [McCool]
ml: I think we agree that we should focus on HTTP first anyway
16:25:10 [McCool]
(sorry dropping)
16:25:31 [mjk]
scribenick: mjk
16:26:11 [mjk]
topic: issue #49
16:27:12 [mjk]
cris: suggest to restrict the core profile to one security schema
16:27:37 [mjk]
ml: can cris create a PR for next time?
16:27:59 [kaz]
i|suggest to|-> https://github.com/w3c/wot-profile/issues/49 Issue 49|
16:28:35 [mjk]
topic: issue #45
16:29:34 [mjk]
sk: I think this is already discussed and addressed
16:29:46 [mjk]
ml: closing
16:30:31 [mjk]
topic: issue #42 need ege in the next discussion
16:31:12 [mjk]
ml: need ege in the next discussion
16:31:52 [mjk]
... need to discuss supported subprotocols and event model in general
16:32:14 [mjk]
... schedule on the agenda for the next call
16:32:16 [kaz]
i|need ege|-> https://github.com/w3c/wot-profile/issues/42 Issue 42|
16:32:26 [kaz]
s/ ege / Ege /
16:32:36 [mjk]
topic: issue #43
16:33:12 [mjk]
ml: made a PR to address the editorial comments
16:33:32 [mjk]
cris: "type" is just one field, should allow an array
16:35:30 [mjk]
mjk: "@type" does not imply multiple inheritance and can be array
16:38:55 [mjk]
ml: initially was to simplify due to requiring both string and array, should constrain to always being array
16:41:58 [mjk]
cris: the comment was about allowing both array and string
16:44:57 [mjk]
ben: allowing string makes for nice visual readability
16:46:03 [mjk]
mjk: there are other reasons where the source has a single string and doesn't need to be expanded
16:46:22 [mjk]
ml: seems like a small decision but this could be consequential
16:49:00 [mjk]
cris: we should be consistent, things are more complicated if there is special behavior
16:50:25 [mjk]
ml: can we remove the editor's note in sec. 5.1.1.2?
16:50:52 [mjk]
q?
16:53:43 [mjk]
topic: issue #60
16:54:02 [kaz]
-> github.com/w3c/wot-profile/issues/60 Issue 60
16:54:59 [mjk]
ben: allow multiple forms in a TD to enable layering multiple protocols
16:56:02 [mjk]
ml: what is the required behavior to specify when there are multiple protocols?
16:56:30 [mjk]
... we could require a separate TD
16:56:50 [mjk]
ben: it's OK to allow a single endpoint for each protocol
17:00:22 [kaz]
[adjourned]
17:00:27 [kaz]
rrsagent, draft minutes
17:00:27 [RRSAgent]
I have made the request to generate https://www.w3.org/2021/01/21-wot-arch-minutes.html kaz
18:58:43 [Zakim]
Zakim has left #wot-arch