Meeting minutes
agenda
Lagally: first architecture with housekeeping
… then profile we should discuss scope and goals
… also validation is an open issue
… any other things that we should cover today?
… ok
house keeping
minutes
<kaz> Dec-2
Lagally: I reviewed the minutes they are fine
… side note: yesterday we discussed an issue in the TD task force. We should have a second look to it
… gave a background about how the Profile spec was created
… we created issue 152 where we can discuss how to proceed
… are mintues ok?
… minutes approved
new timeslots
<kaz> Doodle for Profile
<kaz> Doodle for Architecture
Lagally: we have doodle pools for the new timeslots please answer asap
Architectures
Lagally: two PRs ready to go
… one from McCool is still wip
PR 650
<kaz> PR 651 - Remove arch-consumer-configuration
<kaz> PR 650 - remove arch-methods assertion and section
Lagally: the PR removes a section
… about protocol methods
… looks good.
<mlagally____> Proposal: Merge https://
RESOLUTION: Merge https://
PR 651
<kaz> PR 651 - Remove arch-consumer-configuration
Lagally: as previous PR it removes an assertion about consumer configuration
… it is more related to discovery
… but it has no reviews
… I did
<mlagally____> Proposal: Merge https://
RESOLUTION: Merge https://
<McCool> all, I'm trying to call into the arch meeting but the webex is not opening for me. Did I miss a change of webex?
publication blockers
<benfrancis> McCool: The webex on the calendar is wrong, the link on the mailing list works
<McCool> argh
<benfrancis> McCool: https://
<mlagally____> please use the old webex
Lagally: we have just one publication blocker
… it is a TD assertion it should be moved there or removed
… we have more but most of them are assertions
… please spend sometime working on them
<mlagally____> Please all owners of publication blockers dedicate a bit of time to resolve their issues and create PRs.
<mlagally____> https://
Lagally: the label is blocks pubblication, use the URL above to see the list
spec alignment
<kaz> Spec alignment issues
Lagally: is terminology section moved from discovery?
McCool: pretty much
Lagally: ok closing the issue
… is moving terminology from TD pending?
McCool: yeah
Lagally: about binding templates? I think it is solved
… there also another issue about binding templates terminology, they are requesting definition of content type and MIME type
… looking at the current document we don't have those term defined
… leaving open
… for issue 617 we need @Ege
Lagally: I think we have everything covered in the architecture?
… aob?
WoT Profile
open PRs
<kaz> Open PRs
Lagally: there's a lot of conversation going on in different issues/prs
… a good starting point is the list of PR
… some of them are labeled as needs discussion
… there are two PR marked as close
… I'm wondering why are those labeled as that
Ben: I created an alternative PR that should cover the same changes
… if that PR would be merged PR 87 should be close
… but feel free to remove the close label if you find it misleading
McCool: maybe a different label can help, like potential conflict?
Lagally: not sure it will help since we have many conflicting PRs right now
… the next one with close label is from @Ege it creates an echonet example
… why is labeled as close?
Ben: Ege suggested so
Lagally: I think we should merge it
Ben: Ege suggested closing it
Lagally: ok, we can.
RESOLUTION: close without merging, as suggested by the author: https://
Expectations for the WoT Profile spec
Lagally: I have a couple of slides to support the discussion about goals and purposes of this document
… I'd to have a open table
… reaching a consensus
… I'd ask to be really open about personal/company agendas
… different opinions are symptoms of the current IoT status (fragmentation)
… as task force chair I'll try to be objective and separate company goals
<kaz> [Scope]
McCool: IoT and Interoperability are huge topics
… we need to be practical
… we should limit ourselves to address interoperability problems of the current spec
… about webhooks, I think they are important but we don't have experience with those protocols.
… on the other hand we have experience with SSE and longpoll.
… action and event models feel to big topics to be added inside Profile
Kaz: before starting the discussion, we should clarify the procedure for the discussion today. for example, are you ok with starting discussion on each slide?
Lagally: yes that is my intention
Kaz: ok. even so, probably scope and goals should be discussed together
Lagally: ok
Ben: +1 for mccool points
Lagally: you can see wot profile use cases on the use case document
Ben: we can solve the first use case out-of-box interop with profile
… the last use case I don't think we can solve using profile alone
… you need a software that those the translation between protocols
… basically you can't guarantee interoperability between profiles
Lagally: when we have the separation between the Thing and Protocol Binding
… it should be easier to threat different profiles as abstracts objects and let them interoperate
Cristiano: we had experience with Modbus, MQTT and OPC-UA
Kaz: about the main scope and goal, we should clarify how to deal with the discussion
… given the current situation, today's discussion is kind of brainstorming and I think we should ask each member about their opinion if any
McCool: it is good to have use cases analysis
… maybe it is beneficial to identify the target actors for profile (which are the target consumer/producers ? )
Lagally: profiles might have just a role in the digital tween use case
… it is beneficial to refer arch definitions to help the discussion
<kaz> [Terminology]
<kaz> (some supplementary discussion on terminology)
<McCool> (servients: note that we have Thing Descriptions, not "Servient Descriptions". I.e. we currently describe just the *server* affordances...)
Lagally: the arch is more than client - server model
… we different interaction patterns: client-server, client-servient, servient server, servient-servient
<kaz> [Scope] revisited
Lagally: going back to the scopes
Ben: earlier point: interop between protocols. I think this is a goal of the Thing Description
… I recall that we settled for a scope in a previous call but it wasn't tracked
Kaz: would suggest we ask the other participants about their opinions as well. if they have same opinion with somebody, that's fine.
Lagally: Toumura-san, Matsukura-san and Mizushima-san, what about you?
… what do you need for Profile?
Toumura: I'm a Consumer implementer
… so narrowing down the scope would be helpful
… we don't have enough information for consumer implementations
Lagally: tx, that's a good point
… would support that viewpoint too
… for Oracle, it's essential to have limits and constraints
… that fit into database-based server implementations
McCool: support idea to make resolution on the scope
… looking at the issue we started about the outline
… we define entities precisely, etc., would make sense
Issue 152 - Propose an outline for a new profile document
Ben: great to have different voices
… Lagally, you mention human readability
… more contentious
… my concern is what it means in practice
… that's important but should be solved by the TD rather than the Profile
… human readability should be defined by TD rather than as a constraint within Profile
Lagally: ok
… but let's focus on the discussion on OOTBI today
Kaz: I think today's discussion is kind of brainstorming, so we should ask everybody's expectations for Profile and make sure we won't deny any of them.
Lagally: ok
Matsukura: can understand everybody's opinion
… about interoperability
… for easier deployment
… Fujitsu has a product for WoT
… so we focus on how to maintain devices everywhere
… it's difficult because TD has a logical ID
… but the information is not really connected to actual devices
… we have to describe TD when we install it in the field
… the location information, etc.
… human readability is important but
… we need to specify useful information
… TD is abstract data model
… why such information is needed for actual fields?
… Profile document should focus on practical usages
… one possibility is describing limitation, e.g., nesting levels
… we provide gateways assuming a Thing
… that kind of intention is expected
… limitation of the length of TD may be specified by Profile
Sebastian: what would be useful is considering specific protocol like HTTP to define Profile
… would be helpful
… very clear
… how to interpret it
… interoperability for commercial products is another point
… how the data model to be used
… there is strict representation to be fulfilled
… to adapt to any kind of customer expectations
… my experience is it's not possible to limit it
… specific application areas require existing deployed mechanisms
… something fit with all the needs
… I'm ok with clear guideline on how to deal with HTTP connection
… but could be as flexible as possible
… to provide information for customers
… if the customers want something more compact, should fit with that
Lagally: Profile is for greenfield deployment, right?
… meaning new stuff
… different scenario
Sebastian: yeah, but greenfield mainly addresses protocols. right?
… typical established protocols for industries already
… data model as well
… e.g., OPC-UA and ECLASS
… they exist and won't disappear
… so the scope of Profile is not just defining new stuff
… would ask about something
… what would be the strategy when TD has more stuff which can be consumed?
… what kind of files to be used?
… maybe can't be handled caused by some limitation
… should clarify that kind of points
Lagally: we're not only thinking about implementing large cloud apps
… every platform has some constraints
… we should probably define some common constraints
… e.g., max length for TD
Sebastian: we have to ask people about their limitations
… maybe some of them are secrete, though
… never thought about the goal of Profile because it should be flexible
Lagally: the question is flexibility itself wouldn't help interoperability
… interoperability needs some common constraints, I think
Ege: 2 points
… 1. definition of "interoperability"
… maybe controversial
… some systems might be interoperable but in some case don't work with each other
… how to handle interoperability by Profile?
… 2. question for Toumura-san
… e.g., UI generation
… If you always know there is a description, a "not identified" fallback could be used
<McCool> (title/descriptions need to consider internationalization, however: see my comments here https://
Ege: if we assume that kind of conditions, we could reduce implementation effort
… OOTBI can be achieved by small set of devices within IoT landscape
Lagally: but that is not the goal for WoT Profile
Ege: Profile would make it easier to tackle the IoT silo issue
<McCool> (re implementation effort: I agree implementation should be *finite*, i.e. finite set of protocols, etc. But I think we also previously agreed not to worry too much about *small* devices as consumers in this pass (can address constrained devices in a future profile))
<McCool> (also: 1. we should have a resolution on scope as ben noted, to confirm OOTBI 2. we should discuss issue https://
Kaz: as I mentioned during this call, I think the purpose of today's discussion is kind of brainstorming, so could you summarize your expectation for Profile briefly?
Ege: so my point is Profile would reduce implementation effort
Mizushima: would like to give my point based on the WoT-JP CG's discussion
… they can't understand TD because the spec is complicated
… can't understand how to use TD
… it's important to create a guideline about how to use TD
… and the structure for their own devices
… how to create TD file would be beneficial
<Zakim> kaz, you wanted to react to Ege
Ben: generating generic UI
… Web Things have Web Components
… when we have semantic annotation, can generate generic UI
Lagally: so what is your expectation?
Ben: so my expectation is that Profile doesn't need further definition on data model
Lagally: in positive way, what?
<benfrancis> Proposal: Definition of out-of-the-box interoperability "Any Consumer which conforms with a given profile can interact with any Thing which conforms with the same profile, without additional customization."
Ben: clarification on OOTBI
… any Thing conforms with some specific Profile can work with each other
… implementations by different manufactures can communicate with each other
Sebastian: my expectation is finding building blocks
… interaction affordance
… discovery
… Profile is something kind of nice guideline
… e.g., when I want to use HTTP-based Things
… nice guideline without any big requirements
… could get nice guidelines based on the Profile spec for WoT
Lagally: ok
… we've captured everybody's opinions today
… (goes through the lists of opinions)
… agreed on OOTBI
… reasonable to go for that direction?
Ben: could you show the actual definition?
Lagally: thought some definition on Architecture?
Ben: not Profile itself?
Lagally: some definition within the use case description from the Use Cases and Requirements doc
… section 3.2
Ben: then we actually miss clear definition
(kaz: right. so I also mentioned we should clarify that :)
Lagally: ok
… I'll write up a summary
… and let's try to get common understanding next
Kaz: I should have give some supplementary explanation at the beginning, sorry but we had some preliminary discussion during the Editors call as I sent the minutes by email to all the Editors and we thought it would be really important to claify eveybody's expectations for Profile as the starting point for the spec restructuring. So Michael Lagally is working hard for that diretion and organized this call.
… so the next step should be (as Lagally mentioned) summarizing the discussion today, and get consensus on our expectation for Profile including a clear definition for "OOTBI"
Lagally: yes, let's do so
<mlagally____> https://
Lagally: (generates issue 155 for that direction)
… is that OK?
(no objections)
[adjourned]