Meeting minutes
Minutes
from Last Meeting
<kaz> Nov-25
Canonicalization
Removed canonicalization from Thing Description, still needs removing from Architecture
Lagally: Doesn't appear to be mentioned in Architecture
Any objections?
No, minutes approved.
New Time Slot
<kaz> previous doodle poll
Lagally: Everyone except Sebastian suggested new Doodle poll
Many people also OK with the current slot
But some unhappy
McCool: Yes, unhappy
There are no fully green columns on the original Doodle poll
We need a two hour time slot
One hour on different days perhaps?
Ben: May be easier to find 1 hour time slots for architecture and profiles
McCool: I suggest for next week we keep the current slot, then have a new Doodle poll for separate slots
Lagally: I thought about that too, the only disadvantage is that we have to stick to the schedule
Lagally: Let's do what McCool suggested. Stick to current time slot next week, then separate Doodle polls for after that
McCool: Suggest adding links to the wiki
Lagally: I suggest I create Doodle polls and kaz adds them to wiki
Architecture
PR 615 - Address Binding Templates related issues
https://
Lagally: Does anyone suggest any changes?
Lagally: Adds link to new W3C process document, any problems with that?
McCool: The formal process is AC review, opportunity to complain
Lagally: Seems sensible and well written
Ben: Term "blueprint" may create some confusion regarding templates vs. profiles. I will file an issue.
Happy to merge
Kaz: During this charter period we use the old patent policy. On the other hand the process document has been updated, so referring to the latest process document is OK from a procedure viewpoint.
Lagally: So you don't have concerns?
Kaz: right. the more important point here is we continue to refer to the 2017 Patent Policy for the current Charter period.
Resolution: Merge.
PR 644 Move common terms from Discovery to Architecture
<kaz> https://
Lagally: Some comments on the "discoverer" term, still under discussion
I propose merging this and change later if needed
Any concerns?
Resolution: Merge
McCool: We moved terms over but had one term remaining. Still some discussion on Discoverer/Registerer but haven't reached a resolution, will do this at the same time.
McCool: Suggest merging. Generally suggest keeping all definitions in Architecture.
Merged.
PR 645 - Improve description of device categories
https://
McCool: I'm glad you did this. Suggest changing some sections as a follow-up as part of hub work. Fine with merging this, it is a step forward.
Sebastian: Is this your work or from IETF? It would be cool if this was aligned.
Lagally: It is aligned.
McCool: The lower ones are the same, we extrapolated from there.
Kaz: OK with content, but maybe the style for the table could be improved. E.g. background colour to identify the lines.
McCool: We did this for other tables, that could be cleanup, re-use CSS
Lagally: Any volunteers?
McCool: I think we can leave it until the end when we do bugfixes
McCool: An issue for cleanup, with this as a checkbox.
Resolution: Merge.
Issue 646 - Section structure, assertions, and issues
Toumura: A clarification about which sections are normative
https://
Lagally: What do the question marks mean?
Toumura: Asks to clarify whether this section is normative or not
McCool: Categories should be informative like terminology
Lagally: I guess System Integration section should also be informative
Lagally: A good example of the question of approval
Lagally: Can we pre-approve that?
Sebastian: Yes, OK
Lagally: Do we agree?
(No objections)
Filed issue https://
And https://
There are normative parts relating to Thing Description and Discovery
Two main sections which are normative, section 8 and the conformance section
And section 9
Lagally: Do we have issues about the normative statements?
McCool: I think the discovery assertions are appropriate since they are requirements.
McCool: They're really requirements on other specifications.
Lagally: It looks to me like they should be preserved
McCool: Negative things are hard to test for, but more design questions
Don't have to worry about having test cases for everything
Lagally: Shouldn't go into details here, but this is a good summary
McCool: Should decide what is an appropriate level of detail for WoT Architecture
Not a problem if requirements aren't testable
Ben: Should requirements not be in use cases and requirements document
For the record I think all sections of WoT Architecture should be non-normative and normative assertions should be moved to other specifications
Lagally: We should not take the word requirements to mean the same thing across all documents. Use Cases & Requirements is written by a different set of people.
Lagally: Does that answer your question benfrancis?
Ben: My point still remains, but I don't expect any action
Kaz: Thank you to ktoumura. This is exactly the kind of thing I have been asking editors to do, with this kind of structure.
Regarding benfrancis' point, after some discussion we can define which assertions should be in the architecture document and tested for the architecture specification and which features should be defined and tested by the other specifications.
There is the possibility that WoT Architecture should define abstract design and other specifications should define features
Spec Alignment and Publication Blockers
Sebastian: I can take all issues related to the Thing Description
common data model and constraints in profiles
<kaz> Lagally's slides
Lagally: put together a
presentation to collect the discussion on this
… has been a lot of discussion around
this
… original profile doc was a strawman, done over a
couple of days two years ago
… we focused on considerations for small devices at
first
… and wanted to help with adoption, and small
devices had the most constraints
… generic consumer of a TD is not implementable;
too open and extensible, TD permits too many things, too few
guarantees
… even if we just limit ourselves to
HTTP
… includes an example consumer scenario for a
weather station, also maps, predict weather
conditions...
McCool: btw, I have a
system that pretty much does everything listed, including a web
api: the Tempest weather station
… from WeatherFlow
Lagally: sensor on maps also needed human readable names, etc.
McCool: to summarize, key interop issue here is data interpretation
McCool: in general, we want to focus on interop
seb: the elements of
human readability opens a large number of complex questions, eg.
about internationalization, target audience, etc.
… also location is a very complex topic (indoor vs.
outdoor locations)
McCool: agree that
geolocation is very complex and will probably have to be
deferred
… but units are something we may be able to deal
with
Lagally: also want to
address both sensors and gateways
… gateways may need to aggregate data (for example,
computing averages, min/max, smoothing, extrapolation,
etc)
Kaz: to clarify, this is for issue 125? How many slides? Should we wait for the last page...
Lagally: five more
slides
… common data model and operation semantics are
important
… common payload format, common data model and
operation semantics
… for example, properties should be consistent,
error formats should be consistent, etc.
… want event models to also have consistent
behavior
Lagally: also define a minimum sensor, which is actually a *client*, supporting only push events
Lagally: home gateway would
have more: a server, can read and write properties, and
actions
… industrial gateway would in addition have a
scalable event system
… needs a different event model, but still has
common datamodels and operation semantics
Lagally: so today we are
focused on one protocol and this narrow view may not get us to
something that addresses these broader use cases
… in particular this is the motivation for
including webhooks, etc.
Lagally: in summary, I think
the current profile does not address industrial use cases, so
should not call it the "core" profile
… so we could define different profiles for each of
these scenarios
… and then based on what each profile does we
should pick an appropriate name
<kaz> @@@McCool's points and Sebastian's points recorded on Lagally's slides directly
<Zakim> kaz, you wanted to ask which part the Core Profile is within this diagram
Kaz: thanks for
detailed description
… two points; where and which part should be
described as a core profile
… (note that mm stopped taking notes, but ml was
capturing some in the presentation...)
Kaz: what is the core profile?
Lagally: this is the green parts in the diagrams
Kaz: tend to agree with
concrete use cases and requirements and bottom-up approach
… but in that case looking at particular IoT
standards such as OPC-UA and ECHONET
… these also have a set of basic data models,
etc.
… and event handling mechanisms
… at some point we need to consider how to bind
these, eg. for BIM systems
McCool: however, the HTTP focus is still appropriate if what we are looking at the output of HTTP web proxies/APIs
Ben: want to agree with
mm and seb about difficulty of defining constraints that apply to
everything
… however, there are some constraints that would be
useful, like units, but even that is hard
… agree with a bottom-up process
… disagree that the current profile is only good
for home gateways
… but constrained devices may need another
profile
… am a little concerned about not enabling
inter-domain applications
… discussion of events perhaps misses the point,
the issue is really TCP which is not efficient for this
purpose
… and do we want interop within profiles or between
profiles?
… regarding my PR that removes data model and moves
things around
… would like to discuss scope, etc.
… we agreed a while back to focus only on interop,
and remove others (human and constrained)
… also, there was a large amount of initial text
that was never reviewed
… and we need to review each assertion and see if
it supports the goals we have agreed to
Lagally: object that
proposal has not been properly reviewed; did agree to start with
strawmen; there were many opportunities for review
… regarding the two goals: small devices, no
problem
… but human readability not being a primary concern
I have a problem with
… if TD does not allow you to build a UI, it is
useless for many purposes
… only supports M2M use cases
McCool: so what I'm hearing
is that *some* human readability issues are interop issues, such as
"interop with a dashboard". But we need to clearly and narrowly
define these
… in particular, making titles and descriptions
mandatory may not be the right solution; semantic tagging might be
better (since they can be mapped into local langauges more
easily)
Lagally: regarding PR 125, I feel it does too many things at once, so it is too hard to come to a conclusion
Kaz: we are overtime;
but I felt the discussion was useful
… but I think we may need an even deeper
restructuring
McCool: perhaps we archive the current doc and start again from an outline, bring things in?
Ben: we already did that, and this PR is part of that
<benfrancis> My
proposed outline
https://
Ben: and why there are multiple changes in one PR is that removing things required changing references
Lagally: like idea of starting from a fresh outline and pulling things in
Ben: good, ok with that
McCool: suggest creating an issue to create a new outline, and an MR to do the archival
Lagally: let's start with the issue, can do the MR later
Lagally: creates issue 152
<kaz> Issue 152
<kaz> [adjourned]