W3C

Automotive Business Group 2G-VIS

06 Mar 2017

See also: IRC log

Attendees

Present
Ted, Paul, PatrickLue, Rudi, Adam, PatrickB, Fulup
Regrets
Chair
Paul
Scribe
Ted

Contents


<scribe> scribenick: ted

<scribe> scribe: Ted

Paul: last week we discussed where we are trying to go with these discussions
... the outcome is for the TF to come up with a recommendation to the WG for a next generation of specification
... it is more of a next round than a next generation
... last week PatrickB gave us a tour of their approach to media and how it compares to the various spotify, iheart, etc
... we previously stated the timeline of trying to have this ready before F2F

Ted: a proposal should focus on the broad strokes. the more technical granularities would be the scope of a rechartered WG. for signals we'll need to consider backwards compatibility

Fulup: there are some elements that can be used across interfaces such as authentication schema
... the lower level we try to go the harder it would be for normalization
... from an AGL point of view we need to go the full spectrum from lower level signals to developer applications
... same for music, weather, etc
... I have to propose something to AGL for this year's implementation

Rudi: as far as the signals are concerned there is W3C's VISS

Fulup: I presented this strategy to different people and not convinced I can get adoption
... whereas I see ViWi as easier
... problem will be big tree on the signals

Rudi: you can implement branches. it doesn't mean a vehicle has to expose all those signals
... ViWi is similar with end points

Fulup: I do not think that is an issue. we are not going to change how we handle signals but can map

Rudi: VISS has a pretty structured way of doing this, it is meant as a replacement to a fat API
... you do not want to have to constantly revise the specification when new signals are added. this allows them to move forward separately
... hopefully there will a core subset of signals that we will see widely exposed over time
... there will be signals that some oems will want to keep private

Fulup: we have separated high level and low level signal

Rudi: how the signals in the tree are handled by underlying system is up to implementers
... as far as moving foward we are continuing with VISS and need to discuss the next generation
... we have agreed on using web sockets for this version with discussion on the pros and cons of http or web sockets. the next version would likely be both

Fulup: ok with either transport. is there a reference implementation?

Rudi: I think four, Access, Mitsubishi, Inrix, ETRI+OCF

Paul: Inrix doesn't have an implementation

Fulup: any of them open source?

Paul: I think Peter's (Melco) is

[also I think Vin.li plans to, they demoed at Genivi CES showcase]

Paul: Newsky has one

Ted: done with Baidu

<Paul> https://github.com/newskysecurity/vswss

<Paul> https://github.com/PeterWinzell/vehicle-carsignal-examples

<Paul> https://github.com/aShinjiroUrata/vehicle-signal-server-spec/commits/master

Paul: I will work on a proposal along the lines of what Ted described, broad strokes

Adam: does this mean everything is back on the table including data model and auth mechanism?

<fulup-iotbzh> Shift of Luck look like no C/C++ reference implementation

Paul: I think so. Fulup had some input on security

Rudi: I hope it is more enhancing and extending than starting over completely

Paul: agree

[discussion of keeping the more technical specifics out of a general proposal for how to go forward. what to leverage from one, the other or an alternate approach would be in WG after general proposal is accepted]

[benefits of keeping signals' data model separate from the spec]

Fulup: you have variation in media as well

Rudi: we can agree on a higher level abstraction layer

Fulup: if you do not fulfill the media services' criteria for ip concerns you won't get the data (music)

Paul: I would like to see us to look at the next most useful domain, media and poi
... they may bring up additional security or digital rights issues
... access models should try to be similar
... I would like to see something like VISS or ViWi get adopted
... then when you know you are on a Genivi, AGL or other platform that implements it you know what is available
... we allow for extensions on signals
... this will allow app developers and integraters to operate independently

Rudi: let's tackle the next domains
... explore their use cases

Fulup: I need to know something works before I can propose it

Paul: by April we are suppose to have a Candidate Recommendation with test cases

https://www.w3.org/2014/automotive/charter-2016.html#deliverables

Fulup: I presented AGL's signal recently. we're pretty far along including test cases and benchmarking and that takes quite a bit of time
... we are going to continue monitoring this and may implement
... if any of the implementations were open source and in C then it would be easier

Ted: we do not require implementations be open source, only proof it is implementable by 2 parties along with a test case
... in AGL's case I think you wouldn't be able to take an implementation as is, you'll be doing more of a mapping

Rudi: it may be a little too early to look for a reference implementation

Paul: I agree it is desireable to know something will work before adopting
... we need to provide specifications, tests and encourage implementations

Rudi: let's use the wiki as the platform for drafting a proposal

PatrickB: we built our protocol first and as general as possible before designing the domains
... it would be good to get LG input on their implementation. not sure they are the same people at Birlingame who implemented

PatrickL: they are

Paul: I believe they are still part of the group

Ted: they are and we should encourage them to attend some calls

Paul: we should reach out to them

https://www.w3.org/community/autowebplatform/wiki/2g

Page for proposal. Anyone participating on these calls is welcome to contribute. We can see by revision history who suggested what

Summary of Action Items

Summary of Resolutions

    [End of minutes]

    Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
    $Date: 2017/03/07 00:54:17 $