Automotive Business Group RSI Teleconference

https://github.com/GENIVI/vehicle_signal_specification/

https://github.com/w3c/automotive-bg/issues/59

Patrick: example is lat, long etc of location in a single structure that you can apply regex or other filters to
... we are thinking of adding a complex type on RSI level that can be treated as a primatite
... you would not be able to subscribe to latitude along but the complex type
... it will not be treated the same, sort of like structs in C++

Ted: are you planning to have a full structure? if so I would be interested in comparing it to VSS

Patrick: to allow a larger subscribe of json tree would be complex to implement and break RSI model
... there are logical components eg door window and lock state that could be bundled together
... there could be 3-4 levels from JSON structure that could be treated similar to a primative, receive all the information together as a JSON object
... you'll have other limitations as a result

Rudi: geolocation it makes sense to bundle. for the door model you might want to get the status of all doors at once before allowing the car to drive away
... you do not want to make a fixed assumption on how to bundle, an app might want all the data on a single door or lock status of all doors
... differing grouping options can be powerful

Patrick: you could do a GET request on the individual doors of all the available doors
... we wouldn't do this in RSI this way

Rudi: we have VSS in YAML and translation into JSON objects
... in the end you have all three geo values together that can be subscribed as an object

Patrick: as an object I agree
... our experience with rolling this out to more services is more complexity you allow for objects the more difficult it is to implement
... point is to make it easily digestable
... once we have this in RSI spec then it would allow structured data and find a way to bring VSS tree and RSI together
... we would want to find logical root nodes. geo is a good example where a JSON struct should be handled by the server as a primative
... that is when we should be able to bring things together

Ted: it sounds like you will be able to restructure and will not necessarily be bound by the current depth limitation which is great. as this will be internal negotiations in addition to potentially in VSS itself it would help if Rudi can elaborate one external existing dependencies on VSS. that will help Patrick's argument within VW

Rudi: Visteon as an example is relying on VSS for their framework
... of course JLR is building around VSS
... Genivi in general
... I understand the grouping model as a logical structure
... we purposely avoided complex data structures. at the end a leaf node is a primative
... the object is more or less created by the tree (or subset)
... it can be extended and translated into anything
... we there is some notion that heavily used signals can be aliased so it is easier to bundled but that hasn't been used/explained much
... example being geo
... you would be able to get them by going through the tree too
... I understand the complexity of the tree but it is well organized and common computing concept

Ted: are there others who are using VSS as that will help Patrick persuade VW@@

Rudi: I am not sure I can disclose that

Ted: perhaps ask them
... sounds like next steps are to start seeing how flexible VW might be in changing their structure, perhaps provide current structure thoughts as examples for consideration
... Rudi will see if he can get other parties to state their interest and usage of VSS

Rudi: it may be possible to use the aliasing mechanism to give an alternate tree view as well

Ted: that would mean VW might need to change at all provided we don't throw developers too much. if they ask for something at one location and get it back somewhere else with a different structure it may or may not be cumbersome