Meeting minutes
Introduction
Sebastian: welcome everyone!
Sebastian: please respect the W3C Patent policy
… health rules, code of ethics, and respect the queue
… if you have any question use the irc
<sebastian> https://
Sebastian: all the presentations are hosted in the link above
… please upload you slide deck at the link if you didn't already
Agenda overview
<kaz> Sebastian's slides
Sebastian: today Use cases, TD, Discovery and the Accessibility Joint meeting
… tomorrow outreach, security, profile and next steps
Today's agenda
Sebastian: intro and report of what happened in TPAC so far
… after use cases lead by mccool
… then TD meeting with Michael Koster and Ege
… short break and then Discovery
… at 17:30 we have to change the room
… 1st floor
… after finishing the meetings we will do a photo at the front of the pool
mizushima: is the use case and requirements slot is 30 min? or 45 min?
Ege: there is a error in the agenda
Sebastian: fixed
tonight dinner
Sebastian: wot dinner is planned today
… please if you don't have already let us know
WoT in a nutshell
Sebastian: a short introduction about what we are doing
… as you know the current IoT landscape is fragmented and it causes problems when it comes to develop large scale applications that work across different domains
… to solve this we designed the Thing Description
… lately we published 1.1 version of the major rec documents
… soon we will publish two notes Scripting APIs and Binding Template
… we also planning a next charter
… we passed the voting and it will start in October
… it is a good time to join and be there in the very beginning
… please welcome if you are not yet a member
… help us into improve interoperability in the IoT world
TPAC meetings summary
Sebastian: joint meeting with the Web Agents CG
… we discuss how TD can help to design TDs for autonoums agents
… we also met with JSON for linked data WG, were we got interesting feedbacks
… the breakouts sessions were interesting too
… we discussed about Home assistant, WoT role in smart cities, and new ways to define ontologies and json schemas
… today we also got a hands on section organized by the CG
Sebastian: questions?
Kaz: quick update about publication schedule
… talked with the author of the interoperability comment, we just need to add one line or to in the implementation report
… and the problem about the new charter should be also solved
… in short not big issues
Use cases and Requirements
<kaz> McCool's slides
McCool: we have a large number of use case collected and a huge number of feature requests
… we need to connect use cases and proposed improvements
… also a lot of use cases are really generic IoT use cases and we needed to use some work to traspose to WoT
… also some of them were vague
… like security they asked to be protected, but we had to understand what they really wanted
… same of them are use cases of technologies
<Michael shows a process for handling use cases>
McCool: I propose a way to categories use cases
… I made a list of example categories
… then I have more specialized discussion around Discovery and Security. In particular how to organize use cases
Ege: I think we can use the category to labels, but I don't how they could help
McCool: prioritization is a different problem
McCool: categories are here to help to reduce complexity
Ege: small thing, we would probably see that 1 work item will result in multiple features
Cristiano: sometimes it happens that a requirement is directly connected to a specific use case
McCool: let me capture that
Kaz: I agree with the approach, for today we can concentrate in the basic consensus
… for example the categorization will help and then refine
McCool: I want to reduce the workload
Kaz: some part of some category and some part of use case might be connected to different requirements
… today let's leave this details outside, just focus on the policy
McCool: use cases variegate a lot in the details
… categories help to unify and cover the gap
Sebastian: if you have a small feature request should I go with the full path
… for example, for introducing a new profile attribute should we go full depth?
McCool: think so
McCool: also I want to give use cases and requirements identifiers
Kaz: I agree, we don't need to generate a complete new use case description. We could also extends the existing one
<Zakim> kaz, you wanted to react to kaz
mahda: about the categories list, if we want to abstract from tech then we should not have cloud integration as category
McCool: requirements might have sub requirements
David: I think you are right, categories are helpful
<Ege> +1 to david
David: it is a convenience and it could be used to keep up tidy up the use case and requirements
… I use something like this all the time
McCool: we can use tooling to clean this up?
David: yep
<Zakim> dezell, you wanted to ask about arrow direction
<Zakim> dape, you wanted to react to mahda-noura
Daniel: we have tooling to connect use cases to the original cause
Luca: the end of the result is a feature
… with the graph we can justify it
… I doubt that we will change the use cases a lot.
McCool: yeah at least it will be really easy to do it
Luca: I like the approach and make our life simplier
McCool: more making the process more robust
… and say exactly why we introduced a certain feature
Luca: categorization might improve the whole process
… but still some work needs to be done
security
McCool: Security is special
… we have a security consideration document that needs to be connect with security mitigations
… we can select use cases affected by a treat
… and connect mitigations
discovery
McCool: it is more typical
… we have a simple set of statements about requirements
… we should press forward with one task force and then scale to others
… we are missing queries in discovery
… about the process
process
McCool: two modes: each task force defines it's own document in their repository or we centralize the use case collection and definition.
… it might be better to have a centralized definition
Sebastian: I support the idea to keep everything simple as possible and we should not touch the existing use cases
… it should be good to have a policy that welcomes new feature
… we should reduce the impression that is hard to implement a new feature
Kaz: I agree, we should have a single use case document which covers all the the use cases for WoT
… because we should start with strong needs from the viewpoints of users, developers and vendors rather than we ourselves start discussion on which features are needed for which spec.
… and then report which specification should be affected by the use cases
McCool: first of all, we need to have again the use cases meetings
… we could start from discovery
… because is simple
… then we can tackle the TD
… let's discuss this in the Discovery task force
Ege: we should clean up old use cases
… also work items in the end needs to land in the specific task force repo
<cris_> cris: I agree with Ege on clean up requirements
TD and Bindings
<kaz> Sebastian's slides
Sebastian: Agenda for this slot
… short overview about planned activities
… binding registry
… manageable actions (Koster?)
… need to check whether Michael Koster is joining
… fallback with my presentation
planned TD activities
Sebastian: <figure about basic structure> in TD
… thing model there since TD 1.1
… different security schemes in TD
… close side-document about binding mechanisms
… which refers to the dedicated binding documents for HTTP, Modbus, MQTT, ..
… this is the current status today
… we received some feedback
… not clear about the documents etc
… we had lots of discussions
… we were thinking about re-organizing the structure
… basic mechanism should be in TD itself
<zkis> ZK about having multiple documents: it's actually a recommended practice to split into multiple specific documents
Sebastian: specific implementations like Modbus etc should be specified in external document
… security should be in TD any-longer .. it should be bound to binding
… also new concept: binding templates managed by external SDOs like ECHONET, etc
… long discussion
… protocol "owner" should support specific binding
… WOT can help and guide what is needed
… that's our latest working assumption for now
<zkis> Slide 4 looks like a plugin mechanism - indeed the spec should just describe the plugin API. Implementation notes would be separate.
Sebastian: Ege will introduce registry mechanism later
Ege: Not necessarily SDOs but also other groups
… could be other CG or so
Sebastian: Correct
Salvatore: in BACnet standard we also speak about concept only and support externals
… manufacturer usually does not the entire concept and use just what they need
… applications are all different
… integrators are free about the scope
Kaz: I am okay with the approach also
… anyhow, suggest to continue the discussion what (=what kind of information, data, mapping) is needed for what purpose first.
… and then need to think about how to deal with that (=which group using what mechanism, e.g., registry or Note, with which group or SDO) later.
… 2 step approach should be applied here
Sebastian: Job of charter and follow the experience
Sebastian: I would like to speak about Planned Topics for next charter
… at the moment TD has a basic way to describe endpoint
… there is the base term
… identify protocol .. and where is server located
… there are protocols out there that need more
… like endianness ind Modbus etc
… no place yet in TD
Salvatore: In BACnet we have objects to describe the parameters for drivers
… universal object might not be possible
Sebastian: another idea is to optimize TDs
… depending on protocol at the moment we need to specify contentType for each resource
… if other than application/json
Sebastian: Another topic are manageable actions
… so far we did not find consensus
… no good standard we can rely on
… different solutions exist
… it is about controlling actions that run
Salvatore: in BACnet we have different ways to model this situation
… subscribe to events
… not specific to BACnet
… actions can have different return codes depending on the status they are
… BACnet does not define it .. but allows different means to achieve that
Sebastian: Question is to just have an abstract way
… subprotocol can take over the actual solution
Cristiano: Bottom up approach based on BACnet and HTTP etc
Manageable Actions
Luca: 2 Proposal to tackle
… uniform the efforts
… be explicit
… it is either a relation of a property which is going to change
… action in charge
Luca: Note about previous slide: TD at the moment does not model connected protocols good enough
… security schemes can be used to have building blocks
McCool: different ways of doing async actions
… try to describe existing things
… later on we could create abstraction
Ege: 2 things
… 1. recommend default mechanism ... pushing people in the right direction
… 2. long running affordances do not apply to actions only
… like event (alarms) chains
Kaz: Skeptical about how to extend the TD in that sense
… originally, TD is about how to describe the capability of each device.
… managing long running actions to big/complicated
… we should clarify the needs
… car manufacturers use state charts to model it
… we should not re-invent it
Sebastian: We still need to decide whether we stay on the abstract model
Salvatore: experience from BACnet
… we started with different examples
… looking at runtime interoperability
… needed interoperations ... bring things together
… what is the minimum set
… others can build on top of it
Mahda: In my Phd I considered temporary actions
… difficult to quantify ...
<Ege> I think she said temporal and not temporary?
Sebastian: Koster is missing today.. we should continue the discussion in TD call
<mahda-noura> temporal actions in automated planning
Some more topics
Sebastian: Another topic is canonicalization
Sebastian: required for signing
<dape> s/SUBTOPIC: Canonicalization /SK: Another topic is Canonicalization
Sebastian: Timeseries is another topic
<kaz> i/Another topic is/subtopic: Some more topics/
Sebastian: TD linting ... custom-based implementations
… binding registry ... Ege will talk about in more details the next minutes
McCool: There are big items not on the feature list..
… we can incubate new ideas .. like more semantic support
David: Clarification on linting rules within TD?
Ege: linting rules for TDs
David: validation?
Ege: how to specify that for example "title" is there
… additional mechanism
Cristiano: opinioned format/view of a TD
David: Got it, thanks
<Robert_Winkler> Question: Does TD 2.0 mean it's not backwards compatible?
Binding Registry for TD
<kaz> Ege's slides
Ege: Why are we talking about a registry ?
… no core binding document after next WG note
… concept integrated in TD spec
… not decided how to list them
… or how this list can evolve
… use case: different protocols
Ege: A list in a REC document ... REC cannot be changed
… requires to publish new REC
… the registry mechanism is a solution for it
… makes process more flexible
… basically REC can include registry section which can be updated
… this list (table) can be updated
<kaz> W3C Process
Ege: we will have special table in TD spec .. linking to actual bindings
… we need to define the rules for it
… e.g., withing W3C WebCodecs use registry table
… talked with WebCodecs people about mechanims and experience
… it is relatively new
… in IANA it is used for a long time
<kaz> WebCodecs Codec Registry
Ege: "living will" has to be carefully thought
… thinking about who can register and how to achieve link stability
… experience from WebCodecs was mainly good
… breaking changes to a core document -> apply change in all documents at once
… we should have follow-up discussion with WebCodecs after TPAC
… for example what are our requirements
… like templates
… for the users
… what do we guarantee
Ege: w.r.t. Binding registry .. I do not see another choice
Sebastian: I wonder how that works in practice
… updating table resulting in new date etc
Ege: I think it is a new date etc..
… W3C has tooling in place
Kaz: Thank you for the survey
… but we should think about 2-step approach about this as well
… what kind of information to be described should be clarified first, and then we can think about what kind of mechanism to be used for that purpose next.
… registry is a new mechanism
… on the other hand, even within W3C, there are several more approaches depending on the groups' situation.
… So I'd like to mention some more examples
… key question: registry of IANA manages mediatype
… some W3C groups handle registry differently... for example with notes etc
… we should look into those examples as well
… I can provide some of those examples/links
Sebastian: Kaz, can you give us an overview
Kaz: Will provide information
<kaz> Timed Text WG
<kaz> TTML Media Type Definition and Profile Registry
<kaz> Media Source Extensions Byte Stream Format Registry
<kaz> WebCodecs Codec Registry
<kaz> DID Specification Registries
Cristiano: On the rules. If there are changes on main document .. there should be changes in all the other referenced documents
… I don't think we can do that.. since the documents are not in our control
Ege: in the worst case we can remove an entry.. if it does not get updated
Ege: We can define process ... not sure what else
Salvatore: If the TD changes ... does it require an update of the device
Ege: TD has version field
Salvatore: What is the sense of a TD registry
Ege: Not about TD .. about binding
Ege: at the moment we have a list of supported protocols .. defined by us
… in future "others" can provide such "binding" documents as well
Salvatore: A manufacturer can define each own binding... who is enforcing it ?
Ege: no-one
McCool: Need to sort out how to handle versioning
… I think once you register something .. it should not change
… change to a binding should get a new version
… another aspect is about documents that are not public
<cris_> +1 for immutability of the registry entries
McCool: we should also state compatibility with TD version
… validation is also important .. each binding should have such validation
<McCool_> please record on minutes: rule for publishing all "intermediate" TDs versions should also apply to bindings to avoid "skips" preventing upgrades
<sebastian> let's resume 17:05
Discovery
<kaz> McCool's slides
McCool: discovery, mechanisms for making TD's available, protect the information
… outline presented
… use case and requirements, sparql is optional not mandatory, json paths not complete
… issue of spatial queries which won't be json path
… we need to do cleanup in the document
… we should focus on this immediately in the current charter
… important buckets are: queries (filter by content, JSON Path, Sort-by), discovery mechanisms via MQTT, OPC UA
… priortiy on working on the two items that are not dependent on the td
… TD versions consideration in the directory
… for self-describing devices, there are some devices that support multiple directory services
… we need to broaden the types of formats that can do directories
… geolocation, queries need to be considered for mobile devices
… we need an ontology for DID vocabulary, needs to be published as a fetchable URL
… current proposal says add the terms to the ontology, which adds unneccessary things to the ontology and add weight, and convince people to put metadata information, but security threat
… we should version things and publish them, and not change things that are published, freeze, append only
… short term plan: ontology, connect work items to requirements, working on the work items
Christian: mentioned the multi protocol support, mqtt, and coap and the exploration phase mentioned only coap, does the protocol has to be changed?
McCool: HTTP gives you everything but it is not suitable for every use case
Christian: if we want to avoid protocol switching, the api should be designed that it is generic enough to support different protocols
McCool: mqtt discovery is not standard, we need to chat with the OASIS people
Cristiano: in node-wot we have mqtt discovery, the problem of switching protocol already exists, I like the coap directory approach, lets start with a simple case
[adjourned]