W3C home > Mailing lists > Public > public-tvapi@w3.org > January 2015

[Minutes] TV Control API CG Teleconference - 20150120

From: Francois Daoust <fd@w3.org>
Date: Tue, 20 Jan 2015 16:10:36 +0100
Message-ID: <54BE6FEC.9060606@w3.org>
To: public-tvapi@w3.org
Hi all,

The minutes of today's teleconferences are available online at:


... and copied as raw text below. Feel free to yell on parts I missed or 
scribed incorrectly!


TV Control API Community Group Teleconference

20 Jan 2015



    See also: [3]IRC log

       [3] http://www.w3.org/2015/01/20-tvapi-irc


           Alexander Erk, Ryan Davis, Sean Lin, Chris Needham, Ted
           Guild, Kaz Ashimura, Paul Higgs, Bin Hu, SungHei Kim,
           Francois Daoust, Daniel Davis




      * [4]Topics
          1. [5]Roll call, Introduction and Call for Scribe
          2. [6]Review open action items
          3. [7]Status update of the draft of technical
      * [8]Summary of Action Items

Roll call, Introduction and Call for Scribe

    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: Let's move on with the agenda.

Review open action items


    <trackbot> ACTION-9 -- Sung Hei Kim to Link to the requirement
    and circulate the skeleton document -- due 2014-08-12 -- CLOSED


      [10] 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!


    <trackbot> ACTION-21 -- Bin Hu to Contact hbbtv regarding their
    specification -- due 2014-12-02 -- OPEN


      [11] 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.

Status update of the draft of technical specification

    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> [12]TV Control API draft on Github

      [12] https://github.com/w3c/tvapi

    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

    <kaz> [13]Requirements wiki

      [13] http://www.w3.org/2011/webtv/wiki/Media_APIs/Requirements

    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?



    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
    ... 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

    <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

    Bin: It's not out of scope. Same type of scenario as playing TV

    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

    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
    ... The task force is from the Automotive and Web Platform
    Business Group. I'll share links when we have them.

    <cpn> [16]http://www.w3.org/community/autowebplatform/

      [16] 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:

      [17] 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!

Summary of Action Items

    [NEW] ACTION: Daniel and Kaz to add a column to the mapping
    table to measure the progress of our specification. [recorded

    [End of minutes]
Received on Tuesday, 20 January 2015 15:11:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:45:12 UTC