Logistics

rudi: wondering which group this call is associated
... BG or WG?

kaz: should be BG

rudi: ok

hira: might want to make this call a bit earlier
... it's 2am in Japan

rudi: can see it
... unfortunately, we have various participation and it's difficult to find a perfect time
... let's do another doodle poll at some point

patrickL: depending on the attendees who participate in the discussion
... getting knowledge about VIWI the key
... would be OK to have a second call which fits Asia better

rudi: setting up another doodle is a good thing

patrickL: about use cases
... more or less concrete example on protocols

rudi: maybe we should talk about logistics a bit more?
... every week or every 2 weeks?
... will put the option as well into the doodle poll
... the last item is who would like to lead the discussion?
... BG Chairs?
... or somebody else?
... BG leads should agree with who to run the call

patrickL: can lead the discussion for today

Use cases

PatrickB's slides

patrickL: 5 categories for use cases

(patrickB to present slides)

patrickB: (Vehicle API Use Case analysis - a proposal)
... (Interesting Use Case for a Vehicle API 1/3)
... Vehicle information and configuration
... wheel speed, engine speed, battery status,...
... air conditioner, temperature, ventilation mode, seat position,...
... things we see in vehicle information
... setting configurations
... (Interesting Use Case for a Vehicle API 2/3)
... notifications
... broader scope than the WG work
... sending notifications from a WebApp or an external device
... and registration for notifications
... notifications are interactive
... if getting an email, there will be a button to "read email"
... there are different types of notifications
... also companion apps for media handling
... indirect access for pandra, etc.
... managing the player queue
... and LBS, Media Tuner
... (Interesting Use Case for a Vehicle API 3/3)
... LBS
... accessing vehicle location
... adding a POI to the map
... sending a destination
... tracking route progress
... companion apps would use the information
... Media Tuner
... browsing station lists
... tuning into a station
... scanning a band
... program guide

kaz: some specific program guide mechanism like EPG for TV in you mind?

patrickB: we can discuss what is expected
... and how could be adopted

rudi: media tuner TF's work?

kaz: Ryan Davis is working with the TV Control WG, which works on tuner API
... they're handling media tuning in general
... so we can share use cases for media handling with them

rudi: asked since the Media Tuner TF wiki is not very active

kaz: the main place of media tuner discussion is done within the TV Control side these days

adam: how to extend VSS for media?

rudi: think that would be possible
... current VSS has simple data types, though

kevin: VSS can't handle complex data types at the moment

rudi: yeah, but it should support complex data types as well

patrickL: do you want to see it for VIWI as well?
... what's your opinion?
... comparing the VIWI data model and to VSS

patrickB: can help you

kaz: comparing the data model of VIWI to VSS would be useful

rudi: would be helpful to have list of data types
... which query returns which data types, etc.

patrickB: member submission already includes some information

-> https://www.w3.org/Submission/2016/01/ VIWI submissions

patrickB: we're defining services and objects
... VIWI doesn't support very complicated data types
... how to model it?
... complex or not complex within VSS
... streams for vehicle signals?
... request/response?
... I explained 5 areas of interest
... maybe we should start prioritizing them
... are there any opinions about that?

rudi: vehicle information and configuration is what VSS started with
... good point to start with

patrickL: good idea to use concrete use cases
... let's compare them during the next call

patrickB: about vehicle information and configuration?

patrickL: yes

patrickB: quite interesting is notification from my viewpoint

rudi: ok

patrickB: opening APIs public for notification

kaz: so we need to think about security and permission for that

patrickB: yes
... and important for vehicle information in general :)
... access right
... and API management
... would become a big issue

kevin: we focused on pure vehicle signals
... maybe there is an agent consuming the data
... websocket server itself could mention that
... in reality the client agent/service agent consuming the vehicle data
... we're just exposing data

patrickB: VSS is for vehicle signals but not for media, etc. (currently)
... in that case, we need another instance for media
... for Android, etc., we could have a separate agent
... on the other hand, we could combine media handling capability with VSS

kevin: interesting comparison, isn't it?

adam: we had been working on high-level API spec
... but got feedback it would be better to have a low-level interface
... non-normative section on agent for the service spec

patrickB: how shall I send the slides?

kaz: sending the slides to the public list (public-autowebplatform@w3.org) would be great

patrickB: so we'll discuss vehicle signal part during the next call. right?

rudi: yes

kevin: sounds good

[ adjourned ]