Meeting minutes
Publications
VSSo - published
https://
https://
VISSv1 - Discontinued Spec should be done this week
VISSv2 - should be setup with Echidna so on next commit it should go through, haven't tested
Issues and Pull Requests
https://
Ulf: I thought we had a sentence stating that sensors were read-only but couldn't find it so I found a place within the data model chapter to include it
Ted: I couldn't find it either and gave up
Ulf: I'm inclined to accept the pull request
https://
Ulf: handled with the last pull request
Carine: build process failed due to a markup error
(re Echidna)
… only Core was triggered by the commit. if you look at github actions you can see the details of the attempted build
… I'll look into it
Ted: we can send an email of the various checkers so we can verify before commits - markup validator, linkchecker and pubrules if we can get it working on dynamic Respec from github.io
Carine: you can use pubrules on github.io but need to supply parameters for the spec status for instance
https://
Ulf: we can add a range filter, >=, <=, <, =... and boundary
… a filter is met for instance if signal X > 5 reaches 6
… it is unbounded, no upper bound but if you have two expressions they are logically ANDed together
… what I was thinking about is you might the inverse to a bound range
… my thought was to be able to select AND or OR and my proposal is to add another parameter to this object, boundary-op
… you should only add this parameter when you have two complimentary expressions
Ted: it makes sense, is there a limit to the number of compound statement segments you can have, have speed for instance between 20 and 50 km/h and windshield wipers are on
Ulf: no, haven't but I can see a use case for it
Erik: a filter is mostly focused on a single signal. we have discussed more advanced rules but they come with challenges
… I could subscribe to speed and seatbelt or other individually but only want notification on the combination of filters instead of multitude if either condition met
… we might want to support something like this in the future. you will need your client to have access to all related signals and these filter rules could get quite complex
Ulf: we would have to wait and think this out fully, perhaps wait for VISSv3
… decide how big a step we need to take to support such functionality
… by that convention, we might want to wait on this proposal
… let's let this wait until next week
Ted: we have concept of mandatory and optional filters, mandatory for what was supported in v1. does that include range and then should this feature be optional
Ulf: good question, yes range was supported
… let's let this wait until next week
Ted: we have concept of mandatory and optional filters, mandatory for what was supported in v1. does that include range and then should this feature be optional
Ulf: good question, yes range was supported in v1
https://
Ulf: this is an old one we should settle
Ted: I'll respond to Wonsuk, don't believe we need to maintain a test suite for a discontinued spec and see if he is interested in porting to v2 and helping us there