Meeting minutes
AMM
Ted: Adnan, welcome back from vacation - sorry to have been harassing you but we're keen on getting demo of BMW's VISS at AMM
Adnan: we'll be there, trick will be timing
Ted: Ulf has presented VISS a couple times. point we're at is trying to get wider feedback, encourage experimentation or adoption
… I've been harassing Peter about Volvo's experiment and trying to learn from Erik what Bosch intends since they implemented v1
Peter: conversation resuming, there is interest in VISS
… how many do we need to advance?
Ted: two
Adnan: need to get a green light from our communications department
Paul: wouldn't this fit as part of CVII track on Thursday?
Ted: yes
Ulf: Ted and I would be fine with a half an hour
Adnan: we could do 20-30 minutes, have about 8 slides and could include our GraphQL version and vehicle emulator
Inverse Range Filtering
https://
Ulf: in filtering we support either open or bound range
… my thought was it would be interesting to have inverse filtering, receive values when outside of boundary region
… that isn't possible today but could be with this proposal
… you can have two bounding expressions logically OR
… we didn't have operand expression before, it was always implicitly AND
… we discussed before but wanted to give people time to reflect more
Peter: I think it is worth having
… do you want it in there now or later version (v3)?
Ulf: it is fairly minor to add to spec or implement so would prefer it now
Peter: I'm for it
Erik: my potential concern is "is it sufficient?" or do we need to support more complex scenario
Ulf: I see some value for rudimentary inverse boundary
previous discussion of this issue
Erik: I agree it is useful, question is whether we should support more advanced use cases
Ulf: that we can discuss more in v3 perhaps instead of trying to define now
Ted: my comment previously was similar to Erik's, ability to handle more complex but fine if we do that later
… other question was whether this feature is mandatory or optional?
Ulf: I think it depends on whether range itself is mandatory. my proposal is to make a PR and present back
Adnan: do you also look at frequency of updates, say every 10th value you want back?
Ulf: we do time interval
Adnan: on change supported as well?
Ulf: yes, we have such a filter when a value changes more than some set number
Erik: I just added a comment to this issue, would it be worth having an XOR?
Ulf: I wanted to keep it simpler for now, avoid too much complexity to implement
Erik: this approach might be helpful if we later want more capability
Ulf: I want to hear more from early adopters on what is needed or useful before adding
… they're quite interesting ideas but still think not now
… we're in agreement on moving forward
PR
https://
Erik: it is more or less just link fixes
Ulf: yes, looks like just cross linking
… earlier Wonsuk improved cross-referencing links which we accepted and inclined to do the same here
Erik: can we see the result easily for this PR to be able to check they do what they're intended
Ulf: I think it is possible to test with rawgit rendered based on the branch
Ted: the links should work against current, published version (spot check confirms)
Ulf: let's accept then