- From: Francois Daoust <fd@w3.org>
- Date: Tue, 31 May 2016 16:40:33 +0200
- To: <public-tvcontrol@w3.org>
- Cc: <public-tvapi@w3.org>
Hi,
The minutes of today's call are available at:
http://www.w3.org/2016/05/31-tvapi-minutes.html
... and copied as raw text below.
Recorded actions from the call:
ACTION: Chris to update the TV Control WG wiki to collect use cases
ACTION: Alex to provide radio use cases in the Wiki page, once created
ACTION: Kaz to handle liaison with Automotive Business Group regarding radio use cases
Alex also offered to review the schema.org vocabulary for TV/Radio to see whether it would address radio needs and whether the spec could align to it.
Thanks,
Francois.
-----
TV Control CG/WG call
31 May 2016
[2]Agenda
[2] https://lists.w3.org/Archives/Public/public-tvcontrol/2016May/0013.html
See also: [3]IRC log
[3] http://www.w3.org/2016/05/31-tvapi-irc
Attendees
Present
Youngsun_Ryu, Chris_Needham, Francois_Daoust, Alex_Erk,
Kaz_Ashimura, Tatsuya_Igarashi, Steve_Morris, Bill_Rose
Chair
Chris
Scribe
Francois
Contents
* [4]Topics
1. [5]Spec status
2. [6]JS API vs. network resource approach
3. [7]Next call
* [8]Summary of Action Items
* [9]Summary of Resolutions
__________________________________________________________
Chris: Welcome to this joint call between the TV Control CG and
WG.
... [going through the agenda]
... Any other topic to add to the agenda?
[none heard]
Spec status
Chris: Thanks Francois for organizing our GitHub repository.
... This follows from the discussion we had on the
mailing-list.
... The consensus there was that the WG should have a new
repository for the TV Control API spec to keep it separate from
the CG.
<cpn> [10]https://github.com/w3c/tvcontrol-api
[10] https://github.com/w3c/tvcontrol-api
Chris: with a note in the CG repo to redirect users towards the
WG.
... Please check the new repository.
... I started to record some issues on the specification, the
first one being on the need to write an introduction.
... I think we should do that before we go to FPWD.
... Anyone interested to provide text for that should feel free
to draft a pull request.
... A comment which was made last time by Youngsun was that the
spec needs a much wider review.
... Please everyone take time to review the specification.
... Does it need your needs? Any missing functionality?
... I'd like to build a list of things we feel need to change,
or to be added.
... And then we can decide on which of them need to be
addressed before publication of the FPWD, and which can be
deferred until later on.
... In the CG, there was some feedback from Sangwhan from Opera
about the spec, e.g. control of non-TV input sources (e.g. HDMI
inputs).
... This is something that I don't think that we discussed in
depth.
... Any particular view as to whether this should be included?
Alex: Andreas already had an extensive look at the spec and we
made a prototype application in an Android application that
contains the necessary code to attach a DVB-T tuner.
... The only difference to the actual implementation right now
is that there is no TV MediaStream.
... The feedback from Andreas is that it's quite fine. It
addresses our needs.
... Some clarifications on the notion of channel and source
might be warranted.
... One question on radio use cases.
... How can we proceed with that?
... Main difference is the EPG metadata of DAB is quite
different from TV one.
Igarashi: I remember some discussions about HDMI and radio use
cases. Looking at the charter, video is of course in scope.
Regarding sources and audio, additional specifications may be
considered.
... So it's in scope of the Working Group.
Chris: I agree.
... What I'd like to do is to identify the nature of the
changes that you'd like to make to the specification to include
this thing.
Alex: The radio use case, most of it, could be added as a new
type of tuner.
... Which would deliver audio-only streams. It should pretty
straightforward.
... The main question is around handling of the metadata.
Chris: Do you have anything written down already?
Alex: Yes, I can share what we did in RadioWEB and we can start
from there.
... It contains a list of use cases.
Chris: That's a very good point. I'd like to gather radio use
cases in the Wiki.
-> [11]https://www.w3.org/wiki/TV_Control TV Control WG wiki
[11] https://www.w3.org/wiki/TV_Control
<kaz> [12]CG wiki
[12] https://www.w3.org/community/tvapi/wiki/Main_Page/Phase2_Technical_Use_Cases
Chris: I'll work with Francois to structure the WG wiki and
we'll create a page that can then be populated.
Alex: Excellent. I'll link our RadioWeb spec from there as
well.
Chris: On the subject of radio, what I should mention is that
there is radio-based work going on in the Automotive Business
Group.
<kaz> [13]IVI radio use wiki
[13] https://at.projects.genivi.org/wiki/display/PROJ/IVI+Radio+Use+cases
Kaz: I just pasted the URL of the Genevi radio use cases.
... IVI stands for In-Vehicle Information.
... Ryan Davis, not here today, has been working on this.
... As Alex mentioned, IRT and other broadcasters interested in
radio and TV side are welcome to exchange with the Automotive
Business Group.
Chris: What's the best way for us to proceed to explore the
commonalities?
Kaz: Ryan is quite busy at this moment. It may difficult for
him to join this call regularly.
<scribe> ACTION: Chris to update the TV Control WG wiki to
collect use cases [recorded in
[14]http://www.w3.org/2016/05/31-tvapi-minutes.html#action01]
<scribe> ACTION: Alex to provide radio use cases in the Wiki
page, once created [recorded in
[15]http://www.w3.org/2016/05/31-tvapi-minutes.html#action02]
<scribe> ACTION: Kaz to handle liaison with Automotive Business
Group regarding radio use cases [recorded in
[16]http://www.w3.org/2016/05/31-tvapi-minutes.html#action03]
Chris: I guess my question to the group is, now that we have
more activity regarding radio use cases, how does that affect
our work towards publication as FPWD?
... Should we address this before publication, or can this wait
until after publication?
... The charter says that FPWD is due Q2 2016.
Kaz: FPWD is just a draft, it can be published at any time.
Francois: Right, it triggers a call for exclusion, so it's good
to get the scope right, but discussion here suggests that the
API won't change much (on top of metadata-related properties)
<igarashi> +q
Youngsun: Our development team are reviewing the spec, but they
still need some time, probably a couple of weeks.
... Before publication as FPWD, I'd like to give them some time
to review the spec.
Chris: OK, so maybe we could set a deadline for next call in
four weeks.
Igarashi: I do not understand the problem around EPG. Is that
about radio EPG or TV EPG?
Alex: I'm talking about radio EPG. The radio EPG currently has
some structure that is not supported by DVB EPG.
... For instance, there is a second level, offline content,
etc.
... It supports much more features than a regular DVB EPG.
... The main issue is whether we can make the EPG metadata
exposed by the spec flexible enough.
Igarashi: Right, my concern about the EPG is that it's really
messy.
... Each one supporting their own metadata.
<kaz> [17]HTML version of the github draft
[17] https://w3c.github.io/tvcontrol-api/
Igarashi: In case of radio, is it possible to get some common
vocabulary? The best we can do is probably to define a minimal
set of metadata and let people extend it.
Alex: Yes, that sounds like a very good approach.
... Maybe it's much easier for developers to have a simple API
to access basic metadata and leave it up to developers to
access more extended metadata.
... I'm not pushing for a particular solution, just pointing
out that we'll need to get it more thoughts to include radio
use cases.
<cpn>
[18]http://blog.schema.org/2013/12/schemaorg-for-tv-and-radio-m
arkup.html
[18] http://blog.schema.org/2013/12/schemaorg-for-tv-and-radio-markup.html
Chris: At this point, I think I should point out the work done
at schema.org to define a vocabulary for TV/radio programs.
... It would be interesting to see whether that mapping could
work for us.
Igarashi: does schema.org also cover radio metadata?
<cpn> [19]https://schema.org/RadioEpisode
[19] https://schema.org/RadioEpisode
Alex: If it tries to align stuff with existing vocabularies, it
probably covers some of what I need.
Chris: There are specific classes about radio. Alex, that would
be useful if you can take a look.
... and see how useful it could be for us.
Alex: OK, I'll have a look.
Chris: All of this reminds me that we still have the editor's
position that is open.
... Anyone interested would be very welcome to do so. It's an
important role. Without an editor, we would struggle to keep
the momentum and update the specification.
Francois: Should I setup the notification tool so that the
mailing-list gets notified when activity happens on the GitHub
repository?
Chris: Yes, I think that is a good idea.
... Otherwise people would have to subscribe to the GitHub
repository.
JS API vs. network resource approach
Chris: There's been some discussion on the mailing-list
regarding the TAG feedback.
... I wonder, at what stage of the process should we invite a
review from the TAG?
<igarashi> +q
Francois: Since they already reviewed our work, I would just
wait until publication as FPWD.
... On the topic itself, my takeaway is that there is no "best
solution", there are good arguments to choose API or
network-resource approach.
Chris: Yes, Colin has made some good arguments on the
mailing-list on the network-resource approach.
<kaz> [20]automotive issue
[20] https://github.com/w3c/automotive/issues/85
Kaz: I may have mentioned this the other day as well, but the
Automotive WG has the same problem and the conclusion from the
Paris F2F is that they will continue the API direction that
they have already published.
... They are looking at network approach in parallel.
... The basic understanding is that there are several levels of
interfaces.
... The highest application level interfaces should be JS APIs
for developers.
... Some middleware developers might prefer a Websockets
interface.
... That could be applied Web browser vendors, theoretically.
... Then some Web runtime vendors might want to define some
lower level interface.
... JS API and middleware have use cases for developers.
Igarashi: In my understanding, the issue is whether we need an
extension of the browsers or not. In case of JS API, we need
support from browser vendors. In case of network interface, we
can use browsers as they are and simply use WebSockets to
communicate with the tuner.
... The Automotive discussion is going towards requiring an
extension.
Kaz: The group has discussed the issue for about a year :) If
you would like to use browsers as-is, that amounts to build a
specific runtime for TV-related activities.
... There are use cases in the Automotive WG that need JS APIs.
Igarashi: I understand the conclusion, but I'm not sure
Websockets are not enough in their case.
Kaz: Developers want to use JS APIs.
Igarashi: That is not a technical reason. More business reason.
... TAG will review the spec and wonder whether WebSocket
approach is not enough technically.
Kaz: I don't think so.
... The thing is there is no "best solution" as Francois
mentioned, so TAG is unlikely going to take a strong stance on
this.
... The WG is the one who decides.
Igarashi: If we ask the TAG, we should ask for technology
aspects.
Kaz: I'm not suggesting we should ignore TAG proposals :)
Francois: One thing that could be interesting is to understand
how a network approach would affect the API. It does not seem
easy in our case, e.g. because of the need to expose the
MediaStream
<kaz> chris: +1
<kaz> kaz: +1
<Youngsun_Ryu> +1
Youngsun: Regarding this issue, I think there are pros and cons
both ways.
... Not every TV device supports WebSockets for instance.
Igarashi: Our TV Control is not only about controlling a
channel. The output of the tuner is also rendered in an HTML5
object. If we use a WebSocket, we also need HTTP to render the
output. It's obvious that there is overhead.
Chris: I agree.
Igarashi: In case of audio/video, it may be easier to separate.
Audio may not be integrated with HTML content as such.
... [comments on Automotive WG]
Kaz: That level of discussion depends on the technical
architecture, so we need to talk about the technical
architecture. WebSockets is not the mandated solution, it can
be TCP/UDP connections. We cannot discuss which solution is
better without discussion the technical architecture.
Igarashi: Yes, that we agree with.
Chris: Maybe we should add some notes on the architecture in
the specification. My assumption is that all of the TV APIs are
essentially part of the same runtime environment that pages are
using.
... This leans on security and privacy discussions that we've
raised before. Do we want to expose metadata, preferences and
so on.
... That is something that we need to analyse a bit more. Maybe
we need a different runtime environment, one for Web pages that
you can view on the device, another for control of the tuner
and rendering of its output.
... I think that is something we should do more analysis on.
<Zakim> kaz, you wanted to point out that depends on the
architecture of the system
Igarashi: Is it possible to ask the TAG to review our current
working draft?
... They have not reviewed the community draft, right?
Chris: No, it's up for us to invite them to review the spec
when we think it's ready.
Igarashi: OK, I think they may miss the fact that we're
integrating the tuner output with media elements in HTML5, as
in WebRTC.
Chris: Possibly.
Igarashi: So outcome is publish FPWD, then go to the TAG and
ask for feedback?
Francois: Yes, that sounds good.
<kaz> [21]TAG minutes March 30
[21] https://etherpad.w3ctag.org/p/30-03-2016-minutes.md
Chris: We're running over time now, so wrapping the call would
be good.
Kaz: FYI, the TAG recognizes that they should review the TV
Control API spec.
Next call
Chris: Now that the work has transitioned to the Working Group,
I don't think that there's any separate work going on in the CG
right now, so my suggestion is to have WG-only calls from now
on.
... Is it ok with anyone?
[no objection heard]
Chris: OK, thanks very much for joining and for the discussion.
... Let's work towards publication of our FPWD.
... Please create issues on the issue tracker if you have
feedback on the spec!
[Call adjourned]
Summary of Action Items
[NEW] ACTION: Alex to provide radio use cases in the Wiki page,
once created [recorded in
[22]http://www.w3.org/2016/05/31-tvapi-minutes.html#action02]
[NEW] ACTION: Chris to update the TV Control WG wiki to collect
use cases [recorded in
[23]http://www.w3.org/2016/05/31-tvapi-minutes.html#action01]
[NEW] ACTION: Kaz to handle liaison with Automotive Business
Group regarding radio use cases [recorded in
[24]http://www.w3.org/2016/05/31-tvapi-minutes.html#action03]
Summary of Resolutions
[End of minutes]
Received on Tuesday, 31 May 2016 14:40:42 UTC