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