– DRAFT –
WoT Architecture

Minutes

Sep-9

Lagally: (goes through the minutes)
… duplicated section title for PR 92

Kaz: just removed extra one

Lagally: ok

approved

WoT Architecture

PR 600

PR 600 - WIP: Add Description and Model Section

Lagally: (look into the PR)
… let's wait for McCool's participation

PR 592

PR 592 - Section on profiles

Lagally: (look into the changes)

Preview - 8.3 Profiles

Lagally: would suggest we merge this
… any opinions?

Ben: not really keen on this specific description but no strong opinions

Kaz: don't think "WoT Profile" itself is one of the WoT Building Blocks
… so should go to another section than "8. WoT Building Blocks"

Lagally: good point

Kaz: maybe part of the "1. Introduction" section following a simple leading text saying "Also the WoT Profiles document defines a limited set of the WoT capability."

Lagally: or might be a separate section 9

Ben: what about "WoT Discovery"? Is it one of the WoT Building Blocks?

Kaz: think it's OK to have "WoT Discovery" as one of the WoT Building Blocks
… but "WoT Profile" is by definition a set of limited parts of the "WoT Building Blocks"
… so it's strange to have a subsection for that within section "8. WoT Building BLocks"

Lagally: how about putting the proposed text as a separate section 9 following "8. WoT Buidling Blocks"?

Kaz: I'm Ok with that but we should review the whole structure of the WoT Architecture spec later again

Lagally: ok

(merged)

PR 603

PR 603 - WIP: Define and Discuss "Hubs"

Lagally: need more discussions

WoT Profile

PR 94

PR 94 - time format - initial draft

Lagally: (look into the PR)

Kaz: there is an internal server error maybe due to the invalidness
… we can check the HTML by validator later

Ben: any data format restriction for profile, btw?
… if the requirement is for canonical time notation
… wondering about usage of ms-based times

Lagally: that's popular within the UNIX context

Ben: we do use UTC-based format, though
… don't have a strong opinions about this PR itself

Kaz: in that case, we can merge this PR itself
… and then create another issue about further questions

Ben: ok

Kaz: and we should check the resulted HTML using validator :)

Lagally: ok

(merged)

PR 92

PR 92 - Define protocol binding for events - closes #42

Lagally: (goes through the PR)
… this is very browser-specific
… e.g., we don't use "user agent" as a client for WoT

diff

Ben: that's a common way to handle SSE
… timestamp is missing, though
… need to include timestamps in the schema
… you do get timestamps on the client side

Kaz: if this proposed description itself is OK, we can merge this PR itself
… and then should ask the node-wot guys to review it
… and also should think about how to deal with timestamps based on that mechanism

Ben: yeah
… SSE is not perfect but the options are quite limited for event handling

Koster: needs to be some metadata
… delimited by some application
… not really part of the protocol
… maybe that is where to put the timestamps

Ben: we're working based on some constraints with the existing implementations

(some more discussions)

Ben: don't disagree putting timestamps into payload

Lagally: would support this PR itself

Ben: would be good to have feedback from the implementers

Lagally: let's file a separate issue for timestamps

Koster: btw, we need to have some event handling mechanism for the Plugfest. Right?

Ben: yes, I'm also implementing something

Kaz: btw, Koster, can you also provide something on event handling for the upcoming Plugfest?

Koster: if the scope is narrow enough, could work on something

Kaz: great. Toumura-san has set up the VPN server, and we should have discussion on the detail next Wednesday

Lagally: (created new Issues on timestamps)

for events

for actions

Lagally: and then let's merge the PR 92 itself

(merged)

PR 91

PR 91 - Example TD and canonical TD for Core Profile - closes #90

Ben: still draft

Lagally: I'm a big fan of examples :)

Kaz: me too ;)

diff

Ben: would be better to rename the title of "Example Canonical Thing Description"
… but the concept here is
… the first example is about basic TD
… and the later example is about how a Consumer conforming to the Core Profile would interpret the example Thing Description
… hopefully not mandate for Web Things to expose
… just a informative summary

Lagally: ok

PR 85

PR 85 - Create echonetExampleTD.td.jsonld

Lagally: example TD for ECHONET

Ben: we could think about possible binding

Kaz: think we should generate this kind of example TD based on their (=ECHONET's) own proposal rather than we generate something for them
… we can do that based on their generated TD for the upcoming Plugfest based on their own Device Description standard (which is quite similar to TD)
… and then think about possible binding based on that example
… at least we should ask them to review this example if we want to include this instead of their own generated example
… note that Ege created this PR in July to help ECHONET work on the possible binding
… but ECHONET themselves are joining the Plugfest in 2 weeks
… and providing actual resources including TD and Binding Templates
… so we should look into that as well as this PR

Ben: wondering if ECHONET devices are conforming to the WoT specs
… including the data constraints

Kaz: yeah, we should see the difference during the Plugfest

Ben: would be great if they could follow the Core Profile, but maybe a bit different

Lagally: maybe there is a possibility we need another profile for ECHONET
… why don't we revisit this when Ege is available?

Kaz: yeah, we can revisit this PR after the Plugfest with Ege

Lagally: right

Issue 99

Issue 99 - How does a Consumer conforming to the Core Profile get a list of ongoing actions?

Ben: (summarizes the issue)
… here is no way to get a list of ongoing actions now
… so only the Consumer who invoked the action knows the URL of the actionStatus resource

Lagally: not everybody is capable to implement this feature
… do we really need to standardize this?

Kaz: wondering about the use cases for this
… maybe it might be even more useful to have a complete history of actions depending on use cases

Ben: regarding Lagally's question
… nothing on authorization within Core Profile
… only the Consumer which invoked the action can cancel the action currently

Kaz: ok
… understood
… and my point is for example for a manager servient within a big building management system might want to know the whole history including completed actions to handle the errors for maintenance purposes

Ben: in the case of actions, when you request an action, that require a resource
… the way you cancel the action is removing that resource
… currently the mechanism is ambiguous within the spec
… kind of side effect of mapping actions to REST API

Lagally: need some more discussion

Kaz: anyway, I've understood my point should be discussed as a separate issue based on some concrete use case description, e.g., center console for smart building/city services
… probably out of the scope of the "Core Profile", though

AOB?

(none)

[adjourned]