See also: IRC log
Bin: First meeting of our group
in 2015.
... Francois is from W3C, joining us today. Ryan Davis is from
iHeartMedia in Automotive BG, joining us as well:
Ryan: Hi. I had reviewed before
the TV tuner requirements and mapping table to see
commonalities.
... There does seem to be commonalities. That's why I think
it's good to be listening here, learning for you guys.
tidoust: I was at the beginning
of the Web and TV IG, working for the W3C then.
... I've been back at the W3C for the past 9 months interested
in TV work.
Daniel: A question to Ryan. The TV control API is what we're working. Why would that be appealing for Automotive people?
Ryan: I think of it as a media
tuner API.
... TV is a source of media. Could be radio or so on. The whole
point is the focus on "tuner".
daniel: Indeed, one of the things that got raised at last Web and TV IG F2F was that the API should not focus on broadcast streams of a particular kind, perhaps including broadband streams as well for instance. That resonates well with what you're saying.
Ryan: Right. I don't want to hijack the work of the TV Control API CG, here.
Kaz: Note I work for the Automotive BG as well and mentioned the TV Control API CG there. It should be useful for both groups to collaborate together
<Bin_Hu> http://www.w3.org/community/tvapi/wiki/Main_Page/Agenda_Telco_Jan_20_2015
Bin: Let's move on with the agenda.
ACTION-9?
<trackbot> ACTION-9 -- Sung Hei Kim to Link to the requirement and circulate the skeleton document -- due 2014-08-12 -- CLOSED
<trackbot> http://www.w3.org/community/tvapi/track/actions/9
Bin: Action to circulate the skeleton document is now done. Sung was instrumental in that, thanks a lot! Great work and great discussions!
ACTION-21?
<trackbot> ACTION-21 -- Bin Hu to Contact hbbtv regarding their specification -- due 2014-12-02 -- OPEN
<trackbot> http://www.w3.org/community/tvapi/track/actions/21
Bin: About contacting HbbTV,
Francois got in touch with IRT. Don't know if they are around
today, but that's going in the right direction.
... Good to have HbbTV presence in the work of the CG.
Bin: Good discussions. Sean has
updated the specification, available on GitHub, and shared
yesterday.
... Thank you for everybody who contributed to the discussion
on fixing references to Promises, now part of ES6.
... I'll leave the floor to Sean to present the draft spec.
Alex: Sorry to interrupt, this is Alexander Erk from IRT. First call for me. For me and my colleague Michael Probst, it's new. Just wanted to raise the fact that we've started a RadioWEB in RadioDNS and looking for participation in that group.
Bin: Thanks a lot Alex for the
introduction.
... We are a very open group and are looking forward to your
contributions to the group.
... You're very welcome!
Sean: The current draft is
characterized by a few components.
... We have a TVManager that gives a list of TVTuner with
several TVSource that give access to the EPG.
... In turn, we get access to channels and programs.
... Also, some support for scanning channels.
<kaz> TV Control API draft on Github
Sean: I think that's it for now.
Bin: The current spec is a subset
of the requirements that we have come up with.
... General channel and program requirements are well covered,
I think.
... For EPG requirements, there's perhaps still a gap
there
... That's a very good starting point.
... Next step for the group is to review the current
specification and to identify the gaps in terms of meeting the
requirements.
<kaz> Requirements wiki
Bin: I'm particularly interested
from people from other companies who have not yet contributed
to the discussions.
... Also, there might be some interest to adjust
requirements.
Paul: I don't see parental lock
in the current API.
... Are we expecting more?
<Bin_Hu> http://www.w3.org/community/tvapi/wiki/Main_Page/Requirements_Mapping
Sean: For parental controls, at
the time when we did some gap analysis, the Mozilla TV API had
some parental control stuff but we felt the features were not
quite ready yet so we trimmed them out of scope.
... I think it's just a time gap between the gap analysis and
the development of the API.
... Now the goal is to evolve the baseline that we have right
now.
... We don't have parental control in this draft. I think
that's one item we should mark as "orange" and not as
"green".
Paul: OK, I was looking at work items that we still had to work upon, but see it's not necessarily accurate anymore.
<Zakim> kaz, you wanted to ask if we should add marks to the requirements wiki saying which is included in the spec
Kaz: We might want to add one more column to the mapping table that represents our current spec
Bin: That's a good point,
yes.
... That will help measure the progress of the spec.
... Who wants to take this action?
... Maybe Paul?
Paul: I cannot take it right now. I don't have the bandwidth, I'm afraid.
Daniel: I can have a look
<scribe> ACTION: Daniel and Kaz to add a column to the mapping table to measure the progress of our specification. [recorded in http://www.w3.org/2015/01/20-tvapi-minutes.html#action01]
<trackbot> Created ACTION-22 - And kaz to add a column to the mapping table to measure the progress of our specification. [on Daniel Davis - due 2015-01-27].
kaz: I can help
Bin: Any other question?
Alex: A very generic question.
Sorry if it's out of scope. Right now, you're very focused on
TV. Assuming that the API you're specifying runs on a DVB platform,
that could include radio services. To what point can we reuse
the current spec?
... It might be just a matter of renaming interfaces.
Bin: Very good question. My
understanding of how the API can support radio: the scope of
the group is to define an API that is agnostic of the
underlying technology.
... So indeed, it should support signals of different types and
formats, including radio.
... It should also be able to manage channels of a given
type
... Need some way to advertize the fact that a channel is pure
audio or audio and video.
Alex: so an implementation for radio is in scope for this group?
Bin: It's not out of scope. Same type of scenario as playing TV channels.
Francois: Based on that, should we start renaming things within the spec? They're currently using "TV".
Bin: I would wait until we have a
mechanism to identify the type of channel, which Alex could
perhaps contribute.
... I would rather focus on features before worrying about
names
Kaz: I think Bin's response is reasonable at this point. I would add an editor's note in the meantime to the spec to clarify that the goal is not to exclude radio. Then, at some point, we can change the name.
Alex: Thanks, we will have a
closer look at the current draft. As said earlier, we submitted
last week our first draft in the Radio WEB group. If it's ok
with you, I would try to complete the mapping table from a
radio perspective.
... I agree with your point about leaving naming problems for
the end. The architecture of the spec is more important.
Ryan: Indeed, we can place
placeholders in the spec as suggested.
... The task force is from the Automotive and Web Platform
Business Group. I'll share links when we have them.
<cpn> http://www.w3.org/community/autowebplatform/
Bin: Ryan, I haven't seen a lot of activity over there. Could you introduce the Media Task Force? Background, goals?
<kaz> [ a link should be added to the BG's wiki page at: http://www.w3.org/community/autowebplatform/wiki/Main_Page ]
<inserted> [ cpn, the above is a use case of Obigo, one of the BG participants ]
Ryan: We just kicked this off,
right before the holidays. Our focus is to create an open media
tuner API specification for the vehicle.
... Right now, we're still in the middle of scope.
... There is kind of an infinite scope in the automotive world.
Part of the discussion is trying to understand what the
differences are so we can write requirements around it.
Bin: I'm looking forward for news
on your side.
... Any other suggestion?
... If not, I encourage you to take a look at the spec, and
send comment to the mailing-list. Meanwhile, Daniel and Kaz
will survey gaps in the mapping table.
... Talk to you in about 4 weeks!