Meeting minutes
Minutes
<kaz> May-3
McCool: some minors only, will publish
no objections; approved
planning
Kaz: no update on WD publication
McCool: we need to aim for June 1st for a stable draft
… should we extend the call to 2 hours for the next three weeks?
PR 168
PR 166
merged
PR 162
PR 162 - Expiry date for registered TDs
Preview - 6.2.1.1 Registration Information
McCool: what do you mean by "read-only" here?
… which is the directory?
… someone reading the TD?
Farshid: yeah
McCool: but it's still confusing to have two roles here
… (regarding 'expieres') also how to distinguish the expiration timing?
… would be clearer to simply refer to the ttl
Farshid: ok
… will update 'expires' and 'ttl'
McCool: the time is based on when the data is registered
… (going through the "Files changed")
McCool: the biggest problem is about 'expires' and 'ttl' (relative time vs absolute time)
Farshid: can generate another PR to fix those points
McCool: let's merge this PR 162 itself and will create a new issue to address those points
… then fix the issue with a new PR
(issue 162 merged)
the other PRs
McCool: how to deal with the other PRs?
… would have Ben to discuss them
(PR 158, 159 and 160 by Ben)
PR 160
PR 160 - Rename actions to match properties and events
McCool: (skims PR 158)
Farshid: should we have a separate PR for converting Thing to TD?
McCool: why don't we comment here?
… (adds a comment to PR 160)
… we generally agree that the new names are a useful improvement
… but disagree on the merger of PUT/PATCH (especially if they're hard to distinguish in the Scripting API, or make it harder to distinguish the functionality in other protocols/make the API more HTTP specific)
… so if we had a PR that *JUST* did the name changes, we could merge it
PR 159
PR 159 - Split registration event into multiple events
Farshid: gave a comment
McCool: (adds comments to PR 159)
McCool: Farshid, can you add your comments as well?
Farshid: ok
McCool: can we merge this PR 159?
… (adds another comment that his PR 159 is based on an old version spec)
McCool: let's check with Ben then
Issue 169
Issue 169 - EnrichedThing as a class?
McCool: how does this relate to Thing Model?
ac: please see the example below
McCool: so multiple inheritance here?
ac: yes
ac: if this addition brings confusion, we can skip this
McCool: (adds some comments)
… (e.g., in some cases, Thing needs to provide information that is part of the enriched data namespace (not core TD))
Farshid: seems there is some confusion
McCool: (adds some more comments)
… having an "@type" for "EnrichedThing" would be nice
Kaz: a basic question here
… if a Thing can accept multiple inputs, e.g., one from Link and another from Directory at once, how the Thing can tell those inputs are compatible and generate the consolidated TD (or EnrichedThing)?
… we need to clarify the algorithm based on some concrete use case scenario
… we need to have some specific/limited set of namespaces to be included here. right?
… maybe not for the WoT Directory itself, but we should have how to manage multiple namespaces to be consolidated for a TD
McCool: maybe you could add comments to this Issue 169 or create a new issue about that point?
Kaz: yeah
(some more discussions)
Kaz: how can the Thing tell which Discovery service to be referred to?
McCool: we currently use "w3c.github.io" URL but that is not our intention for the actual service
McCool: we should use a sub-URL under td, e.g., https://
… or continue to use GitHub for now, and dd an ednote
… or assume a given URL, use it in all examples
Kaz: when we created ns/td namespace, we didn't really predict we would have some more namespaces for WoT purposes
… probably we should list all our necessarily namespaces for WoT purposes and then think about how to call them
AOB
McCool: need to talk with Ben as well
[adjourned]