Meeting minutes
Minutes
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
Lagally: (look into the changes)
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
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)
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 ;)
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]