See also: IRC log
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
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 ]