- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 31 Aug 2020 16:47:57 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2020/08/06-wot-arch-minutes.html
also as text below.
Thanks a lot for taking the minutes, Daniel and McCool!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WoT Architecture
06 Aug 2020
[2]Agenda
[2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#Agenda
Attendees
Present
Kaz_Ashimura, Michael_Lagally, Michael_McCool,
Daniel_Peintner, Tomoaki_Mizushima, Sebastian_Kaebisch,
Ryuichi_Matsukura, David_Ezell, Michael_Koster
Regrets
Chair
Lagally
Scribe
Daniel, McCool
Contents
* [3]Topics
1. [4]Past Minutes Approval
2. [5]Profiles
* [6]Summary of Action Items
* [7]Summary of Resolutions
__________________________________________________________
<dape> scribe: dape
Past Minutes Approval
[8]July-30
[8] https://www.w3.org/2020/07/30-wot-arch-minutes.html
Lagally: we had 2 Calls
... no objections -> minutes approved
Profiles
Lagally: 2 open PRs and 15 issues
McCool: Several issues seem to overlap
... consolidate/close?
Lagally: Agree
... should look into
... Let's talk about co-editors first
... we have Lagally, McCool, Mizushima
... Matsukura-san and Sebastian
... 5 co-editors
<kaz> [9]Issue 21
[9] https://github.com/w3c/wot-profile/issues/21
Lagally: Issue 21
... Mix of "scope" and "name" discussions
McCool: would be wise to start with scope first
... proposal: "core" does not even contain protocol
Lagally: Agree, should first talk about data model
McCool: In that case "core" makes sense
... insisting on a specific protocol in the core profile we run
into problems
... with data model only we do not guarantee interop
Lagally: relating to digital twin discussion: with core data
model we could have interop... even across protocols
Kaz: Agree. Starting with minimum set of features.
... we should define this set
Lagally: First set of features w.r.t. data model
... suggest splitting
... 1. constraints on data model
... 2. protocols and constraints
... 3. naming
McCool: some constraints are covered by JSON schema minLength
etc
... related to strings is which encoding
... is there anything besides data models?
Lagally: interaction model... but I see it as part of the data
model
McCool: ID formats? restrictions?
Sebastian: I agree we should avoid the naming discussion
... future profiles may pop up
... "core" assumes it is always part of of it
... I also agree splitting the constraints
... one profile with multiple constraints... security, . et
cetera
... one profile might not always work for all interested
parties
... e.g., HTTP and JSON is fine but needs "more" on the data
model side
Lagally: Then you can extend the profile
... once you go beyond there is no guarantee that you will not
blow other implementations
... conformant to profile means one has a guarantee
Sebastian: example: client with core and restrictions
... what do you do with strings longer than the expectation
Lagally: Cut string?
Sebastian: What is the difference with today's situation?
McCool: IF device says it satisfies profile.. it should satisfy
the constraints
... if intentions of "core" is being part of any profile.. than
name is fine
... out-of-box interop means I need to know whether it
satisfies the constraints
Lagally: One can also validate the constraints
Sebastian: We have to differentiate OOB interop and interop?
... benefit: change is high that others implement the same
Lagally: should not talk about changes but guarantees
<Zakim> kaz, you wanted to say if we really need to avoid using
"core" I'm ok with "vanilla", "plain", "minimum", "tiny" or
anything.
... personally "core" is OK for the minimum set of the
features, though
Kaz: need for defining what we expect
... "core" term might be ok, but terminology should come later
... let's defer naming discussions
... and start with use-cases and requirements
<McCool> another possible name would be "common" if we mean the
"intersection of all constraints needed for interop"
... although I think "core" means that, too
Lagally: We are defining a common ground
... should get more concrete
McCool: 2 comments
... 1. should not use interop but OOB
... 2. leave name for now OR pick another name (fix it later)
... "common" instead of "core"
Sebastian: suggest naming it OOB also
... there are use-cases that do not need profile
... Modbus does not need it
... very easy protocol
... simple datatypes et cetera
... there you have already OOB interop
Lagally: Do you think Modbus constraints are good candidate for
the data model constraints
Sebastian: Would recommend it. Very simple. Based on simple
types...
McCool: back to discussion that "core" does not contain
protocol
... Modbus is more restrictive than "core"
... but that is OK
Lagally: No-one needs to use maximum constraints
Koster: oob interop for CoAP and HTTP could be
... currently no core that works everywhere
<McCool> by the way description of "core" in section 1.3 does
not really match the proposal of not requiring a protocol in
the "core" profile; you would need the "core" plus at least one
protocol binding, and the bindings would have to match, to get
OOBI
Koster: we should call restrictions WoT-###
Lagally: main use case
... cloud use case
... multiple manufactures connect to same cloud
... with current flexibility in TD we can implement many
different variations
... generic cloud service is not implementable
... without limitations it is not possible
Koster: Once you make choices it is not anymore broad consensus
... we look at the framing
... need to agree what the goals are
... unsure about the efforts... we are trying device
specification
... like certifications
... maybe multiple profiles depending on domain
McCool: a device clarifies profile... it just works
Kaz: discussion during this call is great, because we're
clarifying people's expectations for "profile" from various
viewpoints
... we should clarify our expectation as a whole before diving
into the details of this initial document
... which features, which data models, which technology areas
and application domains we want
... because different parties have different ideas
Lagally: We agreed on horizontal profile
... common ground
Kaz: like we've been working on the use cases from the
viewpoint of "horizontal vs vertical", we can think about
profiles from the viewpoint of "horizontal and vertical"
... vertical part could be extension based on industry
applications while horizontal part could be McCool's mentioning
"core profile"
Lagally: let's try to do everything in horizontal
Kaz: we're not stuck with the name of "core profile" itself,
but could use another name, e.g., "common", "vanilla", "plain",
"minimum" or "tiny", for this draft document if needed. right?
McCool: suggest keep it for now and change later
... documentation requirements
... developer use case
... requirement for templates
... do not wanna burden small devices
... 1. specification of templates
... could contain documentation
... let's table "documentation topic"
... have it or link to it
Lagally: let's create issue for it, see Issue#27
Sebastian: similar discussion in templates.... how much should
a TD be self-contained
McCool: developer needs documentation
... with tooling it should just work, no human readable
documentation needed
McCool/ML: building UI is 3rd use case
McCool: Offline UI is the 4th use case
<kaz> [10]Issue 27 - Human readable documentation
[10] https://github.com/w3c/wot-profile/issues/27
<McCool> scribenick: McCool
looking at issue #25
<kaz> [11]Issue 25 - Comments on "core" profile and scope of
constraints
[11] https://github.com/w3c/wot-profile/issues/25
Ben Francis' comments about applicability of "web" if not using
URIs, the internet, etc; for instance, Modbus
Sebastian: modbus does have OOBI though; just need TD
... but its constraints are fairly tight
... OOBI not so easy for HTTP is since it is much more open
with many more options
... so constraining those options with a profile makes more
sense
Lagally: mjk did we cover your points?
Koster: I think so
... but some use cases would help at this point
... need some horizontal guidance for people building systems
from scratch
... even across domains
... and also for constrained devices, eg limit resources
... calling out the protocols that are constrained would be
useful
... see a lot of systems where it would be useful to...
... td is part of what helps protocols being interchangeable
... but we don't necessarily want to do this for one particular
use case
Lagally: let's take this step by step
... maybe find common ground for data model
... protocols are a different angle, may distract from other
things, like data models
Koster: are you talking about payload formats, content
encodings, or information models
... the definition of this varies and may or may not include
all these things
... the power of a TD is that we can standardize/define the
data model and to separate out and interfchange the protocols
... so maybe we are talking about the same thing
... what is your thinking about what should be standardized in
the data model
Lagally: I think we should not go down into standardizing
names, etc. but to put some constraints
Koster: so, for instance, a property can't be arbitrarily
complex
Lagally: exactly
... certainly many things to debate in the strawman
... but there are some suggested constraints on data models
there
Sebastian: feedback on that... worried about id field again
... had long discussion about id field
... second point is security is already mandatory in TD
Lagally: might be a mistake based on a basis in an old version
McCool: dates are actually formally defined, in a different
category than free-form descriptions
... there is also room for negotiation around id; the issue was
really having a central issuing authority
... we can allow sessions, randomly generated, DID, UUID, etc.
maybe we should specific types of ids
... maybe "support" should always be an email
Kaz: regarding "id", we should clarify what kind of ID is
needed in what kind of cases for what purposes, e.g., "globally
unique" mentioned here is one possibility but "session-wide
unique", "application-wide unique", etc., would be also to be
considered based on the use cases and requirements.
Lagally: yes, that's related to the lifecycle discussion as
well.
... and then additional field names with meanings, etc.
McCool: I think we need to handle a certain finite set of
context extensions, and only those
... especially for things with formal meanings, eg data types
Sebastian: worried that we are extending scope and vocabulary
too much
... my proposal would be to discuss these terms in the TD task
force to see if they should be included in the core model
... would avoid for now bringing these up here
... already set up a PR to move these to an issue on the TD
McCool: I concur; I think we should trim down this strawman as
much as possible to what we agree on
Lagally: what kind of timeline are we talking about?
Sebastian: it will probably take a while
McCool: propose we use an extension for now, and simply allow
it in the profile for now
... then in the long run, eg TD 2.0, it might move into the
core vocab
<mlagally_> [12]https://github.com/w3c/wot-profile/pull/26
[12] https://github.com/w3c/wot-profile/pull/26
McCool: I am a little concerned about making this core vocab
for 1.1 for compatibility reasons
Sebastian: mention geosparql in pr
McCool: please note I've listed a bunch in the geolocation use
case, we should add this, and also consider compatibilty with
the web API (defined by DAS)
... we will have to evaluate and look at dependencies, etc
Sebastian: I think we have to check and pick an ontology that
makes
... we can decide in the TD model
<kaz> [13]wot-thing-description issue 941
[13] https://github.com/w3c/wot-thing-description/issues/941
Lagally: if someone want to build an OOBI device that uses
geolocation, what should they do?
... let's say october
McCool: I think if it's october, even TD1.1 will not be out
yet, so you will have to use an extension
... this is fine, to get OOBI we just need to get people to use
the same extension and allow it in the profile (for backward
compat)
... I think we can agree we don't have consensus, and probably
we should not be defining new vocab in the profile
... we should create an issue and discuss various proposals for
solving this problem
Lagally: right now there is chance that people will use
divergent terms...
Sebastian: we should be discussing use cases, etc. first
Lagally: there is a use case for this... it was one of the
first ones
Sebastian: but when did we discuss that it should be in the
profile?
Kaz: charter says "profiles" are subsets of TDs for
interoperabilty purposes
... so I think we should define requirements for "profiles" as
subsets of TDs, and then collaboratively discuss what should be
the subsets of TDs with the TD TF
Lagally: would not have seen the definition of a pragmatic
keyword
... as being a problem
Kaz: my point is not whether these keywords or features make
sense or not
... but that we've been discussing requirements, and should
discuss how to deal with the requirements for subsets of TDs
with the TD TF
Lagally: right, that's the main point
... ultimately, what I want is these keywords available as soon
as possible
Kaz: my assumption is that Sebastian should be OK if we just
make a proposal to figure out where they should be implemented
McCool: our Charter says profile should be a subset. If we
define new terms, it is a superset
Lagally: ok, agree we should not divergence
McCool: agree that geolocation is important, but we should
follow the process and put them in the right place
Lagally: would it be possible to prioritize geolocation?
Sebastian: more important than serial numbers, etc.?
Lagally: together would be nice, but can be decoupling is ok
McCool: would like to point out this is also needed for
geospatial queries in directories
Lagally: would be nice to get into 1.1 for September in the
FPWD
Sebastian: will put on the table next Wed
... McCool, can you comment on the issue and link in other
discussion?
Kaz: btw, we should look at the updated specs about
geolocation/geospatial terms
McCool: and maybe a joint meeting with appropriate groups at
TPAC, eg. DAS, etc.
Kaz: will talk with plh and ivan about that
Lagally: ok, agree to merge PR to delete these from strawman
... time to adjourn...
<kaz> fyi, meeting cancellation plans in August
August 13 - Architecture
August 11 - PoC
August 18 - PoC
August 19 - TD
August 20 - Use Case and Architecture
August 26 - TD may be cancelled; will discuss in main call on
August 25
[adjourned]
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [14]scribe.perl version ([15]CVS log)
$Date: 2020/08/10 07:54:09 $
[14] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[15] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 31 August 2020 07:48:03 UTC