04:57:00 RRSAgent has joined #auto 04:57:00 logging to http://www.w3.org/2017/02/28-auto-irc 04:57:02 RRSAgent, make logs public 04:57:02 Zakim has joined #auto 04:57:04 Zakim, this will be 04:57:04 I don't understand 'this will be', trackbot 04:57:05 Meeting: Automotive Working Group Teleconference 04:57:05 Date: 28 February 2017 04:58:04 ted has changed the topic to: call coordinates for 20170728 2G-VIS call https://lists.w3.org/Archives/Member/internal-autowebplatform/2017Feb/0006.html 04:58:31 PatrickLue has joined #auto 04:59:23 hello, what are the call coordinates for today? 04:59:42 the webex link behind the link above points to the 6th of march 04:59:48 hira has joined #auto 05:00:50 PatrickB has joined #auto 05:01:27 urata_access has joined #auto 05:02:47 Present+ PatrickB, Hira, Ted, PatrickLue 05:03:01 scribenick: ted 05:03:11 Present+ Urata 05:03:27 fulup-iotbzh has joined #auto 05:03:52 Present+ Paul, Fulup 05:04:34 paul has joined #auto 05:06:42 Did the meeting number changed ? I cannot get in. 05:08:03 Paul: I believe we were planning on focusing on access and the data 05:08:19 … there was interest in notifications but that hasn't been released as part of viwi yet 05:08:55 PatrickB: they are not yet released but think we can in another week or so. in the meantime we can look at media 05:09:14 … very different from vehicle signals 05:11:21 https://www.w3.org/Submission/2016/SUBM-viwi-service-media-20161213/ 05:11:31 https://www.w3.org/Submission/2016/01/ 05:11:40 https://www.w3.org/community/autowebplatform/wiki/ViWi 05:13:22 PatrickB: we shared these descriptions in Burlingame based on this json format file 05:13:33 … here we are talking about the media library service 05:13:46 https://www.w3.org/Submission/2016/SUBM-viwi-service-medialibrary-20161213/ 05:14:46 … we always have a service (media library), resource and here you can see artist, song, album cover 05:15:32 … under medialibrary/tracks i can find all my local music indexed 05:17:11 … you could do a GET on all tracks 05:18:01 … a track has a name, id, uri, it can have an image, links to other items such as folders, artist, album 05:20:06 [demonstration on webex shared screen] 05:20:52 PatrickB: as you can see this is all condusive to REST and HTTP 05:21:08 … it is intuitive to web developers 05:21:28 Paul: how did you come up with this structure, where there any influences? 05:22:55 PatrickB: based on common web apis 05:24:23 … pretty much most music services use a similar model 05:25:55 Paul: I could see slight variations if people are allowed to bring their model to this architecture could be problematic 05:26:42 PatrickB: all the parameters mentioned are optional, sometimes you might not have album information 05:27:15 … we have this implemented at present 05:28:14 … you have a resource level end point that you can GET at the end 05:28:56 … POST can be used when relevant 05:29:39 … it is possible to use to adjust ID3 information on a track 05:31:39 … you can subscribe to a resource query and get a socket back 05:31:54 Fulup: I was comparing with Spotify's and it is pretty similar 05:32:38 … in your context how to intend to interact with those various vendors? they will adopt your api, you to theirs, a translator... 05:32:46 For info Spotify API is here 05:32:53 https://developer.spotify.com/web-api/endpoint-reference/ 05:32:55 PatrickB: we built adapters 05:33:50 … Spotify can register itself as a source and put it in the medialibrary 05:34:19 … it could handle queries and bring back resulting links 05:34:47 … it can easily be integrated into a media browser library 05:35:16 Fulup: this means you intend to have a server on the car responding to this api or in the cloud? 05:35:38 PatrickB: it could be either, just need the port 05:36:21 PatrickLue: we can have a proxy in the vehicle as well 05:36:40 Fulup: presently we are using @@1 in AGL reference implementation 05:37:20 PatrickB: there is different levels of involvement, some things are being handled by Tier 1s 05:38:07 … for some systems it is our developers, and sometimes we hand specs to a supplier of what we want 05:38:19 … here we had LG implement 05:39:18 Fulup: I would need to propose a reference implementation within AGL 05:41:06 Paul: it needs to be proved to work for them to adopt it 05:42:04 … the code needs to be able to run against our test suite 05:42:33 … for AGL they need some [linux] distro with runnable code 05:42:55 Fulup: if I cannot proove that then I cannot get it accepted at AGL 05:44:54 PatrickLue: can we point to production vehicles as proof? 05:45:33 Fulup: we need workable code as a starting off point 05:46:12 Ted: need for implementations doesn't come up until later for W3C's spec process 05:46:50 Paul: you want something that people can run on as a development environment 05:48:11 PatrickB: we have only opened up a more substantive than the mock server we provided to in house developers and third parties 05:49:21 … we build HMI and applications in mock server environments and then bring together into a test vehicle 05:50:52 … with this model instead of multiple RPC calls you can send all the parameters you want, track, time offset, volume.... 05:51:35 Paul: what is the feeling of other people on the call. how do we unify signals and media or do we choose not to? 05:52:53 Fulup: we would need to see if we could get this could work with our identity model 05:53:03 … these are very different services with different requirements 05:56:10 … at a low level they can use the same mechanism 05:58:48 PatrickB: there are use cases for wanting to be able to subscribe here too 05:59:42 Urata: this library's data model could be done in vss data model too 06:02:00 … in case of vehicles you have only 2, 4 or so doors, number of wheels etc that is very different from a large media library 06:02:22 … vss and media do not have to be integrated together 06:02:53 Paul: I hear need for two models and separation 06:03:15 Fulup: there is clearly a very different strategy on structuring the data between VSS and ViWi 06:03:42 … it would be much easier to map to ViWi in AGL at present but both are possible 06:04:12 … we could decide to use a similar approach in handling media 06:05:05 Paul: you presently allow for extensions and can have different data models 06:05:33 … due to the varied cars 06:05:36 … do you expect to differences in media models? 06:07:12 PatrickB: you need to design your api to be flexible as Urata was saying. all the doors have the same attributes like windows that can be lowered (or not) 06:09:21 … you can access all or a particular door. this works well with object representation 06:09:49 Urata: Thank you 06:10:23 PatrickLue: we should discuss next topic before we adjourn 06:10:27 Paul: Fulup brought up questions of the auth model 06:10:59 PatrickB: you can send it the same way you would an external service with tokens 06:11:34 Fulup: yes but there are more complicated with the different services (spotify, iheart...) 06:11:55 PatrickLue: they do vary 06:13:42 Paul: use cases are very different for signals and media services 06:15:48 Fulup: I want to know how go to the lower level signals as that approach is too varied 06:16:12 Paul: I am not against it 06:16:50 PatrickLue: it seems out of scope. the lower level protocol is so varied by manufacturer and why we are even trying to coordinate at a higher level 06:17:01 … we can provide examples 06:17:56 Paul: we have some of these sorts of conversations with Genivi 06:19:09 PatrickB: we many different platforms across VW Group 06:19:22 … CAN vary widely, some have MOST 06:19:36 … different from model year even 06:21:59 Fulup: agree it is very hard to try on a lowel level 06:23:04 Paul: we need two implementations for W3C process and those could be AGL and Genivi 06:23:17 kaz has joined #auto 06:25:57 urata_access2 has joined #auto 06:26:01 PatrickLue: I don't see a clear path yet towards standardization 06:28:59 Paul: we have a few topics worth covering such as auth 06:29:13 Ted: notifications and identity 06:29:37 … and then start on proposal 06:30:43 s/we have a few topics worth covering such as auth/this tf is to make a recommendation to the WG on possible path forward. we have a few technical topics worth covering such as auth/ 06:31:51 PatrickB: we could decide to advance some of the other domains such as media while VISS progresses 06:33:05 AGL adopted OpenXC for CAN low level signal mapping. We need something to implement application high level API. As today ViWi looks the easiest path as it is very close of current AGL model. If people are interested in proposing code, I would be more than happy to work on a draft implementation. 06:34:39 PatrickB: including possibly an implementation 06:35:09 Ted: we aren't required to produce an implementation ourselves but could 06:35:41 Paul: if people are willing to implement then you can more easily entice others 06:35:53 Fulup: that is something we can collaborate on 06:37:29 Paul: I encourage people to put together their thoughts for a proposed path for the next call 06:37:45 Urata: I wanted to discuss scheduling 06:38:16 … we can perhaps discuss integrating VISS and ViWi at the Genivi F2F meeting in May 06:38:38 … there we can decide our strategy going forward 06:38:48 Paul: correct, that was the timeline people found acceptable 06:39:38 I have made the request to generate http://www.w3.org/2017/02/28-auto-minutes.html ted 06:39:58 leaving. As of this point the attendees have been PatrickB, Hira, Ted, PatrickLue, Urata, Paul, Fulup 06:39:58 Zakim has left #auto 06:40:00 I see no action items 16:32:13 RRSAgent has joined #auto 16:32:13 logging to http://www.w3.org/2017/02/28-auto-irc 16:32:15 RRSAgent, make logs public 16:32:15 Zakim has joined #auto 16:32:17 Zakim, this will be 16:32:17 I don't understand 'this will be', trackbot 16:32:18 Meeting: Automotive Working Group Teleconference 16:32:18 Date: 28 February 2017 16:34:00 Present+ Philippe_Robin, Philippe_Colliot, Ted, Gunnar, QingAn 16:34:17 Topic: Genivi Developer Platform 12 16:34:23 agenda+ LBS 16:34:37 agenda+ Genivi Developer Platform 12 16:34:57 agenda+ Genivi AMM 16:35:01 agenda+ Payments 16:36:01 Present+ Rudi 16:36:29 scribenick: ted 16:36:36 Chair: PhilippeR 16:36:42 PhilippeR: GDP12 16:37:42 … perhaps first explain to W3C your role within Genivi 16:38:07 Gunnar: I am stepping down as lead architect role and hopefully a replacement in March 16:38:37 … my new role is full time focus on GPD and support around that 16:38:44 … it is a key part of the Genivi work 16:39:11 … including reaching out to companies for resources (engineering, other) 16:39:32 … we are ramping up GDP development going forward 16:39:58 … this should compliment the specification work taking place in W3C 16:40:53 QingAn has joined #auto 16:42:26 [discussion on making document presented public. it will be forwarded and will check if resource is public. features list can be minuted] 16:43:23 Gunnar: chromium integration is progressing rapidly and obviously pertinent to this work 16:43:33 … SOTA is ongoing and should be delivered by that time 16:43:52 … we are doing package based SOTA with full system update next 16:45:33 Ted: Delphi has expressed interest in standardizing around SOTA. back in Paris we discussed and decided it was not worth trying to standardize at the moment and to let it progress, perhaps revisit 16:46:11 Gunnar: there is some discussion around standardizing pieces 16:47:15 … this could be part of web components work. unsure where standardization of native linux platform should take place 16:48:06 PhilippeR: we are talking about integrating GDP with W3C VISS 16:48:27 … we have been discussing FrancaIDL to JSON 16:48:55 PhilippeC: the idea is to generate web API from the same content defined in Franca 16:49:12 … for the next release all the content of Franca file has been aligned with the API 16:49:33 … there will be only one reference for DBUS and Franca 16:50:04 … we will have a mature API. the next step would be able to generate automatically the web API from the Franca files 16:50:18 … including POI 16:50:28 Gunnar: it is a good step for transitioning into W3C 16:50:45 … is the main desire from W3C WebIDL? 16:50:55 PhilippeC: that was the thinking in the beginning 16:51:59 Gunnar: is that your understanding as well Ted? 16:53:43 Ted: correct, we are focusing on a service definition at present. there is interest in a client API which VinLi has drafted and would interact with service specification. [summary of advantaged/rationale] 16:54:19 Gunnar: and the status of that work? 16:54:56 Ted: we have a draft specification, on track with respect to our timeline and there are already implementations from Baidu+NewSky, Melco and I believe Access 16:56:16 Present+ Paul 16:56:26 zakim, next agendum 16:56:26 agendum 1. "LBS" taken up [from ted] 16:56:33 zakim, take up agendum 3 16:56:33 agendum 3. "Genivi AMM" taken up [from ted] 16:57:11 PhilippeR: are you planning on having a W3C F2F meeting at Genivi AMM? 16:57:31 Ted: yes, working on schedule with chairs and Karin. we have various conflicts that week 16:58:32 PhilippeR: it would good to give a W3C presentation again 17:00:14 Ted also will be part of Security Expert Group meeting and their workshop at AMM 17:04:00 zakim, take up agendum 4 17:04:00 agendum 4. "Payments" taken up [from ted] 17:04:32 Ted summarizes Auto/Payments discussions and will send additional information in minutes 17:04:36 @@pay 17:04:54 PhilippeR: is BlockChain in scope for Web Payments? 17:04:59 Ted: yes, very much a part 17:05:23 PhilippeR: we are looking at how BlockChain would work into other parts of Genivi landscape 17:05:55 Gunnar: we are not sure yet how it will fit into automotive, we will be interested in learning more based on payments 17:07:53 Ted: on 14 March there will be a 1/2 presentation during our next BG call from Ian Jacobs who is leading Web Payments at W3C 17:07:55 https://www.w3.org/community/autowebplatform/wiki/Main_Page#Call_info 17:08:51 s|1/2|1/2 hour| 17:10:01 I have made the request to generate http://www.w3.org/2017/02/28-auto-minutes.html ted 17:10:44 leaving. As of this point the attendees have been Philippe_Robin, Philippe_Colliot, Ted, Gunnar, QingAn, Rudi, Paul 17:10:44 Zakim has left #auto 17:10:45 I see no action items