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