Meeting minutes
Preliminary
Lagally: just one hour time for this call
… focus on the high priority issues on the first hour
… maybe mccool can take over after
McCool: ok
Minutes
McCool: review f2f minutes deferred to the latter part of the call
<kaz> July-15
Lagally: any concerns on the previous minutes?
Lagally: ok approved
Profile PRs
PR 89
<kaz> PR 89 - Define protocol binding for actions - closes
<kaz> Issue 81 - Action semantics
Lagally: any other people had time to review it?
McCool: I did have look on other design patterns, I want to propose alternative solutions.
Ben: this is a draft for a protocol bindings for actions
… I did not specify update action operation in this draft
… two different action types: sync and asyc
… open issue: should we include input data in the response? now it is not mandatory in the PR
… where to include the created URL? header or body? now it is in the body
… there's no example for output data but it is planned
McCool: is there any difference between actions that "create resources" rather than just an async action?
… we discussed a lot about good design patterns also in discovery
… I read API design patterns book, there is a pointer to google.aip.dev/151
… there is a description for long running operations, maybe can inspire us
<McCool> https://
McCool: actual link above
Ben: interesting do you think it can improve the current status?
McCool: I think so, mostly it is just a checklist that we could follow
… we can do a sanity check
… there are also collections
Lagally: thank you, I suggest to review the current PRs with this new information in mind
<McCool> https://
Kaz: I am ok with starting with a simple proposal and doing further reviews, but we should consider binding with the exisiting IoT standards, e.g., Echonet, OCF, oneM2M, ...
McCool: I don't really agree with it, profile is for greenfield devices we have to strive to a good api rather
Kaz: in that case, I should have split my comment into two levels, (1) this binding within wot-profile for small devices (we need to think about device level standards) and (2) at some point later, we need to think about specific bindings with the other IoT standards.
McCool: looking at existing standards is good to create a list of requirements
Lagally: I too think we don't have to strictly follow a specific standard but get inspiration from them
… let's look at what we have
McCool: I agree, we just need some sanity checks
Koster: we can collaborate with the Thing-To-Thing group, we are working on the same pattern.
<mjk> https://
Lagally: what do you mean by collaborate?
Koster: maybe invite in the call or review PRs
Koster: we support getting a status and delete
… sometimes created resources have different owners: coffe process and confee machine
Lagally: we are using http specific features in Ben's proposal
McCool: yeah agree, it is a requirement question: do we want to extend to support to other protocol later?
Lagally: I do prefer to keep our solution open
Koster: we can allow blended solutions. e.g. put location in the header if user want
McCool: so do we merge it now?
Lagally: keep for review for one more week
McCool: we have one more week than vacation hit
Lagally: let's get every comment on the PR before next meeting
Ben: don't focus too much on protocol extensibility. This is good design for HTTP
… for example MQTT design would be completely different.
Lagally: can we use url in the body?
Ben: it is a convention to put it in the headers
Lagally: why do we have two action status?
Ben: one is the status and the other is a link to the status
McCool: one is the header and the other is the payload
Lagally: why don't put the url in the payload
McCool: as Ben said this would have another schema
Kaz: I can ask Matsuda-san about how they handle with this specific situation. BTW, what is the main reason to have sync or async? I personally think it would be useful for a use case that a Consumer talks with a group of Things which collaborate with each other, e.g., an air conditioner and a robot cleaner (robot cleaner cleans first, and then the air conditioner waits until the cleaning is done before it starts)
Ben: the main practical reason is that some actions may exceed the usual HTTP timeout
Kaz: I suggest to design a specific use-case for this description when we ask external SDOs for review.
McCool: the terminology is a little bit confusing
Ben: I agree
McCool: long-running and quick actions?
Ben: mmm not convincing cause you can have sync long-running actions too.
McCool: ok for keeping it
Lagally: maybe it requires one or more lines as introductions
PR 78
<kaz> PR 78 - Restructure WoT Core Profile section
Lagally: this is an old PR
Ben: I rebase it today, it is blocking
Lagally: I have some problems with the current changes
… it is a little bit "ostile" cause is deleting a lot of text
Ben: it is the result of a previous discussion that we had.
… I see removing as a good thing if it is simplify the current situation
mc: I suggest not to block Ben, the text is there in the repo
Lagally: the removed part has significant content that it is useful for other profiles
Ben: I don't indiscriminaly delete it, but it seems that it was a little bit out of scope
… which part of the text do you feel to keep because it contributes to interoperability.
Lagally: do you want to remote core data model?
Ben: yes and the external TD representations
Lagally: we should keep core Data model because we have to keep the separation between data model and protocol bindings
Ben: I agree with keep data model separate from the binding
… but I would put this on Thing Description spec
Ben: which of these constraints do you feel apply to all the bindings but not to all the devices
McCool: it might be sense to label sections with their goal
… title and description mandatory is human-readable
… we want to encourage good design in profile
… do we need a best practice section?
… it is different than targeting interoperability
Lagally: we can have it, but making a normative statement to stress the importance of our goals. (e.g., human readable)
Kaz: my suggestion is to not remove the content but maybe once move to the appendix section, and continue the discussion about which content to be included in the Profile spec. If the data model definition here need within the Profile spec, we can pick up the necessary part back to the main body. On the other hand, if part of the description to be moved to the Thing Description spec, we should do so.
Lagally: why don't we just remove human-readability constraints? so maybe just change the PR to be more fine-grained
Lagally: it is a long discussion, maybe defer to the next call
<benfrancis> https://
<benfrancis> https://
Ben: we had a similar discussion, above links to that
… we haven't talk about added sections, the PR is more about restructuring
McCool: maybe having a feedback on the sections that we should keep it would help future discussions
Lagally: let's look into that together
<kaz> (Lagally leaves and McCool takes over the Chair's role)
https://
<kaz> Cristiano: (mentions wot-thing-description Issue 1195 above)
PR 92
<kaz> PR 92 - Define protocol binding for events - closes #42
Ben: how do you feel about for a protocol binding for SSE?
Cristiano: node-wot has a draft implement of it, so let's do it
Koster: fair choice
McCool: no direct experience with it, but it is a w3c spec so it good.
Ben: thank you
Architecture PRs
PR 602
<kaz> PR 602 - Refactor TD/Discovery Material in Section 8
McCool: refactored building blocks section by adding discovery as a top level
McCool: any comments on the PR?
<kaz> 8.5 WoT Discovery
McCool: I think we can move on and merge it
… updates can be done in the future
PR 601
<kaz> PR 601 - Fixup Device Classes
<kaz> 4. Device Categories (which is added)
McCool: PR adds the device classes
… it mentions also about gateways and hubs
… and fixes minor formatting problems
… we need better category names, nodeMCU is a product
McCool: any objection ?
… ok merged
<kaz> PR 600 - WIP: Add Description and Model Section
PR 604
<kaz> PR 600 and 604 - WIP: Provides text for TM
McCool: PR 600 can cause problems with Sebastian's PR. I can merge it now and provide further work later
Sebastian: you can actually merge PR 604 too, it is marked as wip but I can work on it later
McCool: (reviews the changes in PR 600 and PR 604)
… let's merge PR 604 first, and will work on PR 600
<kaz> (PR 604 merged)
PR 605
Cristiano: this came from TD
Ben: yeah, we added subscribeallevents and related operations.
… but the definitions are in the architecture
… so I updated it
… we should move this table in td spec
McCool: right, let's merge it and then add an issue for moving it
McCool: ok for merging it
mm creates the issue about moving operations to TD spec
f2f minutes
<kaz> vF2f minutes
McCool: we discussed PRs
… canonicalization (but it is now outdated)
… duplicate text
Kaz: they are two proposal
McCool: they look the same
kaz removed the second entry
McCool: spotted another typo
… also there is a fixup entry that did not work
… no other comments?
kaz fixed the issues above
McCool: so day 3 is reviewed
McCool: two typos in day 2
… there's a random character
… missing a capital T
… async https://
… day 5
… keep in mind that the chapter number in the profile spec are now changed
… no any other issues
… ok everything is done
<kaz> yay!
McCool: AOB?
<kaz> [adjourned]