Meeting minutes
agenda
<kaz> agenda for today
Ege: we will start for TD 1.1 publication process
… another major thing is to sync tha static html to the new process document
… we have bacnet
… one topic will be deferred for the next week
… after Michael will discuss next action items
… we need to agree fro the process of new use cases
… if you have other items for the next week you can always provide the action items in the wiki
… any questions?
… ok
TD publication
PR 1916
<kaz> wot-thing-description PR 1916 - Sync Resources Folder
Ege: we synchronized a couple of resources
… with the root of the repository
… and then I will move it to the resources repository.
Ege: ok no objections, merging
… ok merged I'll do the same in the wot-resources repository
<cris_> +1
updated process document
Ege: the process document has been updated
… we have to align
… it is commented
… ok if the processVersion is commented the document should report the current Process version.
… but this is not the case
… maybe we have to update it manually?
Kaz: let's look in the latest html in the github.io as a starting point
Ege: still wrong
Kaz: this means that respec is old
Kaz: we can manually update it
Ege: the processVersion is deprecated
… during this call we can't do anything
… we should do this after respec is updated
Kaz: web master said that respec is going to be updated tomorrow
… for today we can ignore the pub rule error
Ege: found the PR
… it is very fresh
<Ege> w3c/
binding templates
Ege: we will talk about URI variables problem next week
PR 312
<kaz> wot-binding-templates PR 312 - improve BACnet JSON schema
Ege: I added BACnet json schema
… we decided to not put types in the schema
… but I understood wrong, fennybay explained the problem
… the types goes in the form
Ege: basically there are a set of bacnet types
… these datatype are later defined
… there types of annotation of data
… everything is done at the form level
… showing an example
Cristiano: good direction
… maybe the text should be more assertive
Ege: yes
Cristiano: also starting from this we should ask ourselves if also application types will need extension
… example having just number and integer is good enough?
Cristiano: is it possible that the value pass data schema but is not valid for bacnet?
Ege: yes, we need a better validation process
Koster: doing this correctly depends by the right schema mapping in the TD next
… we don't have it yet and this is a temporaney fix
Ege: agree
Cristiano: +1
Ege: we are seeing this pattern in different bindings
… modbus has endianess
… URI variables could be another use case
Cristiano: I would say this is a great starting point for using the new process of creating features in TD
Ege: merging PR
TD next
<kaz> (Ege leaves)
<kaz> TD next agenda
Koster: Last time there was little attendance, so the last real meeting was two weeks ago
… today, we should have a look at how the organize the work and refactoring
Project Management
Koster: We need to get to the point at which we can generate PRs and issues
… (looks at the Work Items document)
<kaz> work-items.md
Koster: the first thing we wanted to look at was restructuring
… I think we need to have a definition of some of these items under restructuring
… there should be a common definitions section
… is anyone aware of a better structure of these items?
<mjk_> https://
Koster: (switches to the TD-specific document)
… this is a breakdown of the items we have
… nevermind, it is not a very good breakdown of the items
Kaz: I have two questions:
… first: what is the relationship between the two documents?
… work-items.md should probably be the first starting point
… second: Maybe we should clarify what we mean by "usability" and "design work"
Koster: I agree, we need to improve that and refine the definition of these work items
… so, I think it seems like Binding Mechanism and Binding Submission Mechanism are something different than restructuring
… seems to me like that bindings are more like a feature in general
… maybe we can start with some of the items lower down on this list
… like inline security and better TM integration
… not sure about normative parsing, although it seems like an interesting concept
… I suppose the idea behind restructuring was to create a new structure before integrating some of these other things.
… how should we get this going?
… we probably need to have someone go through the document and create a list of issues we need to address
… I think we probably need a better definition of the things we need to do here
… (starts editing the file)
… we might want to just add new items here
… specifically, what is a common definition section
… maybe we can add a subsection
… (adds a subsection "Document reorganization")
… and then we add an item "Common definition section"
… (adds it to the document, alongside of "Grouping of normative requirements")
… do we have anything else to add here? I guess we are not yet prepared to discuss this
… as a next step, we can collect "Reusable Elements"
… like the Reusable Connections, similar to how MQTT connections are organized in Node-RED
Luca: Another aspect are reusable data schemas, for example using JSON pointers
… we could also refactor the security schemes as they are our current blueprint for reusable elements
Koster: Do you think they use a good pattern?
Luca: I am not sure if the pattern is really good, but the security scheme and connections use a similar pattern and are closely related, on the logical level they are the same thing
Koster: Yeah, all of these reusable elements should use the same pattern
… normalization when processing a TD should more or less work the same across the whole document
Koster: Another item for Document reorganization is the start of a TD design document
Luca: Refactoring-wise, I think we should make the affordances more uniform, they should apply the same patterns, e.g. when observing
Koster: That is a great point, I think we had an ealier discussion about that
… what should we call it? That the state machine should work the same?
Luca: We have two parts:
… one is expressing the same kind of capability across the three affordances
… should not matter what kind of affordance it is, observing should work the same
… cancellation of events does work fairly different than observing, that should not be the case
… also, we should express relationships across affordances, this is also something that got requested
Koster: That is the say, that an action might affect the state of a property
Luca: Exactly
Cristiano: I think we have something like the list you are currently making somewhere else, should we maybe search first?
Luca: I think this is the list we have and we are just reorganizing it
Cristiano: There should be a list with issues
Koster: I think we looked at that one. Let's finish this work for now, and then see if we can reuse something we had ealier
… this is an attempt to put everything into one place, although it feels somewhat redundant
… this is trying to create an index, but let's try not to spend too much time on this
Kaz: Among those subsections currently listed
… I think reorganization is clear
… but reusable elements and state machines are a bit complicated. I think we should have a clarified environment and context for these two features
… the question is how to combine different affordances based on each environment and setting
… for example, ECHONET has certain restrictions in this regard
… maybe we need to have a look at existing standards and documents
Koster: We need to have a design document and have a look at current best practices
Kaz: I personally think we could use the ordinary Use Case template and its procedure to clarify those points (i.e., Reusable Elements and uniform pattern/state machine between actions/events/properties
Koster: We should use the use case document as a basis, that makes sense
… when creating a design document, we could end up with a lot of documents, but documenting things avoids the same work twice
… the design document is more like a redesign document
… explaining the rationale and reuse of patterns, e.g. from OpenAPI
… there is one thing I wanted to bring up again, let's say "properties vs actions"
… the fundamental difference is that you need an operation to access the data with actions and events
… furthermore, a lot of people ask when to use an action and when to use a property
… we should talk a bit more about the semantics of the two concepts and explain them better
… for example, properties do not have input and output in contrast to actions
Cristiano: I wonder if this topic also touches the problem of URI variables
… for example, if you have URI variables in properties, then they can act similarly to an action
… but I guess this is more refactoring or a new feature that deprecates the old one
Koster: I agree with that
… and it has impact on how we solve others issues as well
Koster: Can someone explain a bit better what the issue is with TD versioning?
… do we not have a version scheme that works with TDs or was this something else?
Cristiano: To be honest, I am not sure
… I think the question was how to uniquely identify different versions of a TD
… something like a hash to identify or sign a TD
Koster: Like an md5 hash
… but I think that also implies that there is some cryptography involved, not just a simple md5
Cristiano: I suppose we need to ask the original author
<luca_barbato> https://
Luca: The RDF canonicalization working group has published their recommendation
… this is one of the areas where it is good to not invent the wheel from scratch
<cris_> +1
Koster: I would have preferred something for JSON, but whatever we do not have to reinvent is great
Koster: I would add a category "Normative Consumption" to the list
… do we want to prescribe how TDs are processed beyond the text part, if that makes sense?
<cris_> good point +1
Luca: I would care a lot about a normative degraded consumption rule
… see my presentation from TPAC, make all consumers make behave the same way when it comes to degradation
Koster: Maybe this is also relevant for constrained devices, e.g., if the TD is too big to process as a whole
… now I am wondering what we should do with binding mechanism
… maybe it should become its own category
Cristiano: I agree, there is a lot of stuff to consider here
Koster: (adds a new "Protocol Binding" subsection)
… now we have Usability and Design Work Items that make more sense as a separate category
… I think the rest of it is pretty clear
… so there are four work items here
… but maybe we want to start with the Document Reorganization and Reusable Elements first (?)
Cristiano: I agree, the first state should be to prioritize work items
… maybe start with the easier ones first
Koster: (saves the file and goes over the list once more)
… Document Reorganization and Reusable Elements are mostly mechanical
… do we have any issues that relate to these two?
… do we want to create labels to categories the existing issues? We have a lot of issues by the way
Cristiano: If we create new issues, then we should close older ones and add a comment that they have been superseded
… there is also the question, how the process relates to the one presented by Michael McCool
… is this related to the Use Cases and Requirements process presented by Michael?
Koster: A lot of these items are related and motivated by use cases and requirements
… some of the issues in the TD repo are already labelled as TD 2.0, so we can probably filter them
Cristiano: Another kind of refactoring work item is understanding the toolchain for creating all the documents, is it there already?
… we had a discussion regarding a single source of truth, at the moment the process is pretty complicated and cumbersome
… as it also uses tools we cannot control
Koster: I'll add it to the list
… will avoid the problems Ege had to fix recently
Cristiano: Not sure if it is easy to fix the process without using strange tooling
Koster: Yeah, the key to solving this problem is to close the gaps in the tooling
… (updates the document)
Koster: We have a lot of "Defer to TD 2.0" issues
… there will be some work involved to categorize all of them
… this where we need to have some kind of project management solution
Issue 1889
Koster: This is one issue we should really have look at, creating a design document
… we need to figure out how to assign people and create action items
… I'll this issue as a link to the list
Jan: Maybe we can really use that Github Projects feature to organize the issues
Koster: Ege, kaz, and I already looked into it, we will discuss it soon
… next meeting we should start assigning people and start the work
AOB
Koster: Any other business?
Kaz: I already mentioned it some time ago, if we really want to use the projects feature, we should have a look into how it is organized across the W3C
… we should not overcomplicate things
<kaz> w3c strategy repo as an example (but we need to define some specific procedure)
Koster: Yeah, we need a policy and should keep the process as lightweight as possible
<kaz> [adjourned]