Meeting minutes
agenda
<kaz> agenda for today
Ege: longer discussion on binding templates
… then on the TD next
… we will discuss about how to manage the process
… and finally on the IANA registry
… anything else to add?
minutes
<kaz> Nov-22
Ege: we fixed the minutes
… anything else to be fixed?
… minutes approved
td call slot
<kaz> Doodle
Ege: we have input from toumura
Cristiano: we pass the dates
Ege: people can't vote for the past
… it is problematic
… I record inputs we have
Kaz: do we need any more additional participant?
Ege: maybe only Kudzai
Kaz: ah in that case we can close it and check directly with them
Ege: we will start with the new slot after holidays
TD 1.1
Ege: most of the issues got deferred to TD 2.0
… we need to categorize them
… I closed very obvious issues
… please check you emails for closed issues if you have any remarks let us know
transition request
Ege: it will happen next week
… we will have a publication soon
… 5th
<kaz> Transition Request
Kaz: the transition request has been approved, we are working on the final details
… expected publication date is December 5th
binding templates
PR 318
<kaz> Issue 118 - Introduce contentType byte order
Ege: last week we agreed to clean up URI schemes
… dogan did that
… and we merged the PR
… it fixes some points in the bacnet binding
… with this there a still some small fixes to the bacnet that needs to be done
… use the label to search for them
… we can close issue 302
… it was fixed by 318
issue 319
<kaz> Issue 319 - Better Explaining the current use case of the Modbus Binding
Ege: it is not clear in the introduction what we are talking about
… it is better to explain better use cases for non-experts and explain that is about modbus tcp
Cristiano: I can do it
Ege: I can also help
PR 320
<kaz> PR 320 - Minor modbus improvements
Ege: it is about modbus prefix
… plus a smal fixes in the examples
Cristiano: fixed the prefix, minor fixes in the example, and fixed the context url
Ege: looks good
Kaz: I'm ok with the fixes
… but why do we prefer modv instead of modbus
Ege: it is from Manu Sporny recommendations
… we basically put a v to avoid people get confused with actual modbus protocol
… and it also aligned with the others
Issue 293
<kaz> Issue 293 - [Modbus-binding] type conversion based on byte and word order
Ege: we dag deper in the implementations to understand how to deal with the types in modbus
… the final outcome is promising
… there are lot of fine details to keep in mind
… I evaluated the one word and three word approach
… they both have pro and cons that we discussed in the issue
… we have evaluated different libraries
… I made all findings available in the comment
… defaults are easier in the three words approach
… byte swapping and endianess are the same
… the problem is that different communities use the same term for the same concept
… I like sebastian's proposal
… instead of using Change I would use another term like lowWordFirst
Kaz: having this kind of detail discussion is important. As I mentioned last week, I'm still not really sure what level of data binding we have to support
… we should discuss some more expected use cases and requirements before diving into this level of details.
… for example, we can concentrate to the ASCII mode as a starting point
… but if we want to go for the bytes
… we have to understand the length to be handled at once for some specific use case.
… modbus sensor can be polled
… implementations can store the data for one day
Ege: ok it is a nice use case, but for now let's keep it simple
… I agree for a real web thing we should have a streaming discussion
Kaz: ok, I'm not objecting to this simple starting point
… but we need to clarify (1) now we're concentrating on a simple mechanism of one-shot request/response with one byte or two for both the TD producer and the TD consumer. And also we need to clarify (2) further possible use cases on how to use Modbus data, e.g., recording multiple data for one whole day and process it at once, to think about the requirements for existing IoT systems. to think about future use cases too
Luca: In the end modbus is all about dealing with 16bits registers
… all the perceived complexity is about the fact that you can read multiples registers
… we have also coils single booleans
… those are the basic building blocks
… and we have to describe them first.
Ege: int32 is very common, but everything more complicated is out of scope right?
Luca: modbus has the ability to read/write multiple registers but at the end we are dealing with 2 bytes (16 bit)
… we have to describe endianess
… and when we lamp them all togheter it stars to have additional problems
… we should try to keep naming as simple as possible to allow newcomers understand
Cristiano: I would prefer something else than wordOrderChange, but something more evocative
<dape> +1
Sebastian: we don't have to over complicate this
… but we have to support the use cases and this use cases are pretty common
… there is no good guideline unfortunately
… that is the reason why we are talking about this
… are we going to provide this information?
… one word approach is very compact
… if you have a lot of datapoints it is more compact
… there is no perfect term anyway
… let's find the words and explain them very well
Ege: ideally if we have to define the order per device, you will have one word per form
Sebastian: what is the default though?
Ege: for that I would wait for TD 2.0
… the common connection field
… we can put the information there
… default big endian
… no word swapping
Sebastian: I like Ege's proposal
Cristiano: +1
mk: Modbus spec talks about registers and multiple registers?
Luca: there are multiple commands to do different stuff
… and you cannot read more than X depending on the configuration
mk: it doesn't really address the idea of having oderning
… do we really need swapping?
Ege: you are right
… but it is very common
… if you don't putting in the TD you have to do manually
Luca: you start having the problem when you try to map a double
… and then you stumble upon the swapping problem
Cristiano: +1 with mk observation. in the future we should have a more systematic approach.
Daniel: I'm in favor of what Michael proposed, mostSignaficatByteFirst
<JKRhb> I would also be in favor of "least significant" or "most significant"
Kaz: I agree with previous points, what kind of data should be described? If possible should be aligned with actual use case descriptions for TD 2.0..
Ege: +1
Ege: anything else?
<luca_barbato_> +1
+1
Ege: let's go with the proposal and wait for a PR in the next week
Kaz: maybe the names are good at the moment, but I'm not sure if it's really good at the moment.
… can we use them as candidates?
Ege: yes we can iterate in the future
Sebastian: any alternative?
Kaz: I don't really know but we can revisit the naming in the future
PR 298
<kaz> PR 298 - Add additional explanations to vocabulary creation guide
Ege: not a lot to be done at the moment
… Jan is adding a guide on how to create binding template document
… it binds with the tooling discussion
… there were some reviews to be tackled
… any questions?
Jan: no questions yet
… regarding Mahda's comments, I hope I addressed them
… thank you for the reviews
Ege: we use activate
… accessing is not used
Cristiano: how much should be follow the current approach?
Ege: I'm not sure how much we will comply with the current process
<sebastian> sorry, I have to go. bye
Mahda: the wordings are different between the context.jsonld and the ontology
Cristiano: yeah so basically this is done by loading the context.jsonld into a RDF database and use it to convert between the ontology
Kaz: in the end the document will be included in the html?
… or do we want to keep this as separate?
Ege: I don't have a quick answer
… it might be fine to include it in the spec
… it might go there
Kaz: this description as MD is fine as a starting point, but thinking about the final location and structure within the spec HTML would be useful to consider how to improve this description.
<kaz> scribenick: cris_/
Jan: think we the creation guide we want to capture the status quo that we have right now
… we can later refine
… and make it more user-friendly
TD next
<kaz> TD Next work items.md
Ege: ege worked on linking work-items from sub documents, converted lists to headings and then in the work items we can see the links to them
… any opinions on this from others?
… ege would work on simplifying the items
<kaz> PR 1160 - TD Planning: Linking Work Items from Sub Documents
IANA registries
<kaz> registry-analysis/Readme.md
Cristiano: IANA has a range of possibilities, in the previous text we were mentioning some examples, having such text is fine, IANA has defined some rules to be used in registries
Ege: so IANA has a common approach?
Cristiano: IANA says you are encouraged to use the policies, but could happen that this doesn't happen
Ege: I think the generic consideration is good, but wouldn't bother with the other ones
… websocket is relevant and the media types
PR 1161 - docs: IANA procedures for registries summary
Cristiano: all the submission goes through email
Ege: maybe the initial submission happens via the form and the rest via email
… for the official W3C mechanism we are waiting for Michale Koster
merged PR w3c/
Kaz: on Thursdays, sometimes there are project review meetings regarding technical meetings, maybe it might make sense if we want to talk about and how we want to use the registry, or questions, or improvements
… I have organized several times about W3C updates, it might make sense to talk about registry track
Ege: is it weekly?
Kaz: any members can join
Ege: maybe we join after we merged the PR from cristiano
Ege: I talked to some persons on tpac, they gave good inputs
Kaz: I will talk with them about this
project management
Ege: get input on what people like to see, how you'd like to structure the evolution of the specification workflow, how to take issues into account, and how we plan to address PRs
… if anyone has experience on this, we can improve our way of working
Koster: I think we have alot of work items and potential need to prioritize, have been done a good job until now in prioritizing? I personally think we are doing a bit better
… we need to manage a set of features, we have alot of ideas, we don't know whether they all fit
… what are requirements and use cases for project management
… having an agenda items is helpful, but maybe having something more formal is helpful
… maybe something lightweight, we need to think about something that is a bit more systematic
Ege: the current approach is not well organized
… recently we used the github issue and assigned it to people
<mjk_> ackmjk
Mahda: personally, I loose track when the number of issues that I have to work on gets too much, and would prefer to have an overview
Cristiano: assigning an issue definitly helps, but probably assignee would happen if you know that this will happen in a quick manner, 1 week, and that it digestible in one week. Sometimes there are issues that need more weeks, and something with a higher organization could help
Ege: ideally we assign when we know that this person can do the best, best fit, but what if there are some issues that need to do by one persons
… kanban board could help
… we make sure in a one week time frame that the person works on 1-2 issues per week
Cristiano: if we have the kanban, we can generate the issue PR discussion by just loooking at it
Ege: I saw one of the groups in TPAC planning the agenda using something similar to a Kanban board
Jan: splitting issues that is larger into smaller chunks could also help to distribute the workload
Jan: I had issues with an overwhelming task with the use cases and requirements
<kaz> an example of wot-usecases Issue 236 - Associate Discovery Requirement with Use Cases
Ege: the issue should be small
Jan: mentioned the task list of github
Kaz: think about this kind of workflow for our standardization discussion is good. On the other hand, I personally think WoT WG has been working on spec generation for two versions of specs, so there are already enough resources and information to clarify better procedure for our spec generation.
… Then I'd like to suggest we think about the basic procedure to generate specs starting with the use cases first, then extract requirements, then analyze gaps with the existing version of standards, then think about necessary features based on those considerations.
Ege: I agree, the pipeline we are talking should be taken into account
… one thing I can do is to document the procedure to explain what has been happening so far
… e.g., when there was a feature in TD, node-wot would try to implement it
Daniel: I wonder in the future how we want to select and rank the isssues
Ege: we cannot mandate how fast someone should work, I don't think we won't give specific deadlines to people
… we actually had a plan on this, how to handle all those issues, we talked about this with kaz and Michael Koster
… the initial plan is to categorizing the issues, new features are prioritized, while the tooling is getting settled
<kaz> [adjourned]