17:10:16 RRSAgent has joined #auto 17:10:16 logging to http://www.w3.org/2017/01/23-auto-irc 17:10:42 Meeting: Automotive BG - VIWI/Convergence 17:11:43 kaz has changed the topic to: webex for jan. 23: https://mit.webex.com/mit/j.php?MTID=m07c5fb9ecd299d368ebd5c53d3885d3f 17:13:06 present: Kaz, Adam, Rudi 17:15:21 Patrick_B has joined #auto 17:16:13 present+ patrickB 17:18:27 regrets: Ted 17:18:58 hira has joined #auto 17:18:58 rudi: wondering which group this call is associated 17:19:01 ... BG or WG? 17:19:07 kaz: should be BG 17:19:11 rudi: ok 17:19:35 present+ Hira 17:21:44 hira: might want to make this call a bit earlier 17:21:50 ... it's 2am in Japan 17:22:00 PatrickLue has joined #auto 17:22:17 present+ patrickL 17:22:35 rudi: can see it 17:23:00 ... unfortunately, we have various participation and it's difficult to find a perfect time 17:23:16 ... let's do another doodle poll at some point 17:23:51 pl: depending on the attendees who participate in the discussion 17:24:19 ... getting knowledge about VIWI the key 17:25:03 ... would be OK to have a second call which fits Asia better 17:25:22 rudi: setting up another doodle is a good thing 17:25:58 pl: about use cases 17:26:07 ... more or less concrete example on protocols 17:26:20 rudi: maybe we should talk about logistics a bit more? 17:26:33 ... every week or every 2 weeks? 17:27:16 ... will put the option as well into the doodle poll 17:27:28 ... the last item is who would like to lead the discussion? 17:27:34 ... BG Chairs? 17:27:38 ... or somebody else? 17:28:10 ... BG leads should agree with who to run the call 17:28:34 pl: can lead the discussion for today 17:28:50 topic: Use cases 17:29:31 pl: 5 categories for use cases 17:30:15 (patrickB to present slides) 17:30:31 pb: (Vehicle API Use Case analysis - a proposal) 17:31:36 ... (Interesting Use Case for a Vehicle API 1/3) 17:31:44 ... Vehicle information and configuration 17:32:00 ... wheel speed, engine speed, battery status,... 17:32:34 ... air conditioner, temperature, ventilation mode, seat position,... 17:33:00 ... things we see in vehicle information 17:33:09 ... setting configurations 17:33:20 ... (Interesting Use Case for a Vehicle API 2/3) 17:33:24 ... notifications 17:33:41 ... broader scope than the WG work 17:33:59 ... sending notifications from a WebApp or an external device 17:34:17 ... and registeration for notifications 17:34:26 ... notifications are inteeractive 17:34:45 ... if getting an email, there will be a button to "read email" 17:34:56 ... there are different types of notifications 17:35:08 ... also companion apps 17:35:24 ... indirect access for pandra 17:35:36 ... managing the player queue 17:35:47 s/apps/apps for media handling/ 17:36:02 ... and LBS, Media Tuner 17:36:14 ... (Interesting Use Case for a Vehicle API 3/3) 17:36:18 ... LBS 17:36:25 ... accessing vehicle location 17:36:30 ... adding a POI to the map 17:36:36 ... sending a destination 17:36:43 ... tracking route progress 17:37:01 ... companion apps would use the information 17:37:07 ... Media Tuner 17:37:13 ... browsing station lists 17:37:20 ... tune into a station 17:37:27 s/tune/tuning/ 17:37:33 ... scanning a band 17:37:43 ... program guide 17:38:14 kaz: some specific program guide like EPG for TV? 17:38:24 pb: we can discuss what is expected 17:38:37 ... and how could be adopted 17:39:07 rudi: media tuner group? 17:39:39 kaz: TV Control WG is working on tuner API 17:40:18 ... they're handling media tuning in general 17:40:36 ... so we can share use cases for media handling 17:41:35 rudi: asked since the Media Tuner TF wiki is not very active 17:41:58 adam: how to extend VSS for media? 17:42:10 rudi: think that would be possible 17:42:51 ... current VSS has simple data types, though 17:43:42 kevin: VSS can't handle complex data types at the moment 17:43:49 present+ Kevin 17:44:22 rudi: yeah, but it should support complex data types as well 17:45:41 pl: do you want to see it for VIWI as well? 17:45:49 ... what's your opinion? 17:46:49 ... comparing the VIWI data model and to VSS 17:47:08 pb: can help you 17:47:49 kaz: comparing the data model of VIWI to VSS would be useful 17:48:08 rudi: would be helpful to have list of data types 17:48:22 ... which query returns which data types, etc. 17:48:40 pb: member submission already includes some information 17:48:46 -> https://www.w3.org/Submission/2016/01/ VIWI submissions 17:49:02 pb: we're defining services and objects 17:49:13 ... VIWI doesn't support very complicated data types 17:49:25 ... how to model it? 17:49:38 ... complex or not complex within VSS 17:49:56 ... streams for vehicle signals? 17:50:05 ... request/response? 17:50:37 pb: I explained 5 areas of interest 17:50:48 ... maybe we should start prioritizing them 17:51:14 ... are there any opinions about that? 17:51:30 rudi: vehicle information and configuration is what VSS started with 17:51:35 ... good point to start with 17:52:32 pl: good idea to use concrete use cases 17:52:49 ... let's compare them during the next call 17:52:59 pb: about vehicle information and configuration? 17:53:03 pl: yes 17:53:17 pb: quite interesting is notification from my viewpoint 17:53:24 rudi: ok 17:53:47 pb: opening APIs public for notification 17:54:19 kaz: so we need to think about security and permission for that 17:54:23 pb: yes 17:54:33 ... and important for vehicle information in general :) 17:54:46 ... access right 17:54:52 ... and API management 17:55:00 ... would become a big issue 17:55:17 kevin: we focused on pure vehicle signals 17:55:31 ... maybe there is an agent consuming the data 17:55:45 ... websocket server itself could mention that 17:56:39 ... in reality the client agent/service agent consuming the vehicle data 17:57:17 ... we're just exposing data 17:57:36 pb: VSS is for vehicle signals but not for media, etc. (currently) 17:57:47 ... in that case, we need another instance for media 17:58:15 ... for Android, etc., we could have a separate agent 17:58:32 ... on the other hand, we could combine media handling capability with VSS 17:58:58 kevin: interesting comparison, isn't it 17:59:03 s/it/it? 18:01:42 adam: we had been working on high-level API spec 18:02:02 ... but got feedback it would be better to have a low-level method 18:02:09 s/method/interface/ 18:03:13 ... non-normative section on agent for the service spec 18:03:38 pb: how shall I send the slides? 18:03:59 kaz: sending the slides to the public list (public-autowebplatform@w3.org) 18:04:04 ... would be great 18:04:36 pb: so we'll discuss vehicle signal part during the next call. right? 18:04:38 rudi: yes 18:04:41 kevin: sounds good 18:05:00 [ adjourned ] 18:05:05 rrsagent, make log public 18:05:12 rrsagent, draft minutes 18:05:12 I have made the request to generate http://www.w3.org/2017/01/23-auto-minutes.html kaz 18:06:04 i/wondering which/topic: Logistics/ 18:06:06 rrsagent, draft minutes 18:06:06 I have made the request to generate http://www.w3.org/2017/01/23-auto-minutes.html kaz 18:06:32 Chair: Rudi, PatrickL 18:06:34 rrsagent, draft minutes 18:06:34 I have made the request to generate http://www.w3.org/2017/01/23-auto-minutes.html kaz