Meeting minutes
minutes
<dape> Feb-7
Daniel: we talked about use cases section renaming and discovery issues
Daniel: minor typo
Daniel: minutes looks good
… no objections to publish
quick updates
discovery
<McCool> https://
<McCool> https://
McCool: please review the links above
<mccool sharing the screen>
McCool: the problem is that we didn't describe the process of a consumer
… I listed some issues
… how we handle external links (federated TDDs?)
… how we manage external links? how much control the application
… should have?
Daniel: should the script download the whole directory?
McCool: we have no normative query mechanism
… worst case you download everything
… no solution so far
… json path non ready yet
… I have a PR which describes most of the discovery process
… there's new section Discover Consumer
… with a set of assertions
… trying to be permessive
… the arch will have a SHOULD assertion for implementing the discovery process on a consumer
… what is the minimum implementation?
Daniel: ok having just ONE required mechanisms
McCool: ok, remember that introduction mechanisms are not TDDs
Cristiano: I would ok about having the direct mechanism as the basic required introductio mechanism
McCool: I can expand adding use cases
Zoltan: In this scenario the consumer might be also a server?
McCool: these are requirements on the client
Zoltan: prior knowledge for discovery with direct is the URL
McCool: yeah we can defined two use cases
… automatic and manual
Zoltan: what should we expose to the client script
McCool: direct and directories stays on two different level of discovery
… the output of the introduction is a set of URLs
… remember that URLs pointing to a TD might be a TDD TD
… so you might need to futher explore it
… you might need to implement logic
… to futher explore
… also applicatio may choose to futher explore a TDD or a link
Zoltan: I was thinking that the application might have an higher level
… of abstraction
McCool: the problem is that queries are not mandotory
… for example jsonpath does not have regex
Zoltan: we need to focus on the use case
McCool: in the future yeah we can have something more abstract
McCool: directory is not required
… you can use different introduction mechanism
Cristiano: I think it is fine to support both use cases
Daniel: currently the implementation is hiding a lot of this details
… I am worried about the fact that this can be overcomplicated
McCool: I agree it is complicated
… I want to avoid situations where it won't work well
… infinite loops
… might be problematic
Zoltan: implementing an LDAP api might be complicated
McCool: we can do horizontal extesion
… breadth first style
Zoltan: some heuristic can be implemented on custom use cases
McCool: we could have a discovery factory
… where client can choose the type of discovery that suite its needs
… thing links are another issue
… I hope to have a final version for Wednesday
Cristiano: about ThingLinks of composed models, should we follow them automatically
… we have two options: flat and using links
McCool: originally we had only ThingLinks, but now we have also Read-Only TDDs and mini directories
… for an outlet strip should I get a mini-directory or a TD wiht links to sub-parts ?
Cristiano: I would say that a word on this in the spec might help implementers
McCool: yeah but it really depends by the use case
Daniel: action point for the Scripting API task force is to re-read the spec and give feedback
PRs
PR 375
Daniel: are you ok for Scripting Api Use Case scenarios?
Zoltan: ok
… I'll update the PR
introduce local again
jan: a little bit pre-mature
<dape> https://github.com/w3c/wot-scripting-api/pull/381
Zoltan: it was removed for a good reason
daniel: it touches what we discussed before
jan: we can revise later on
Cristiano: I would wait for a definition of local from the discovery spec
Zoltan: exactly
Daniel: sure
McCool: local might be a particular a set of introduction mechanisms
Issues
Issue 376
<dape> Issue 376 - Check alignments with Architecture
Daniel: we have to check the architecture document, it is still on my TODO list
Issue 363
<dape> Issue 363 - Consuming composited Thing Description
Daniel: you can have composed TDs
… what are the next steps?
… IMHO scripting api should not handle the special use case
… it is related with Thing Links
McCool: yeah, but Thing Links does not have affordances
… we are debating this
Zoltan: it looks like a link level optimization
Daniel: think link is something different
… in my TD I want to mention that an aggregation of TDs
Zoltan: you can't use Thing Links to describe composed Things
Daniel: we are overtime
Cristiano: just want to say that here the use case is different from Think Links. Composed TDs are a way to describe a set of related TDs
Zoltan: is there any use case description about this?
adjourned
<kaz> [adjourned]