[apis] minutes - 2 October 2013

available at:
  http://www.w3.org/2013/10/02-webtv-minutes.html

also as text below.

Thanks a lot for taking these minutes, Daniel!

Kazuyuki

---
    [1]W3C

       [1] http://www.w3.org/

                                - DRAFT -

                          Media APIs TF meeting

02 Oct 2013

    [2]Agenda

       [2] 
http://lists.w3.org/Archives/Public/public-web-and-tv/2013Sep/0050.html

    See also: [3]IRC log

       [3] http://www.w3.org/2013/10/02-webtv-irc

Attendees

    Present
           Daniel, Kaz, Giuseppe, Giridhar, Bin, Igarashi, CyrilRa,
           SKim, WHyun, Olivier, Mark

    Regrets
    Chair
           Olivier

    Scribe
           ddavis

Contents

      * [4]Topics
          1. [5]Use cases
          2. [6]TPAC
          3. [7]ATSC 3.0
      * [8]Summary of Action Items
      __________________________________________________________

Use cases

    Bin_Hu deadline for use case discussion

    giuseppe: We should finalise the use cases and decide which can
    be finished, and which can be deferred.

    <olivier>
    [9]https://docs.google.com/spreadsheet/ccc?key=0AvACjV6qSvmxdEc
    tdjYwa2JOalZLOG10elE1LVRZNlE#gid=0

       [9] 
https://docs.google.com/spreadsheet/ccc?key=0AvACjV6qSvmxdEctdjYwa2JOalZLOG10elE1LVRZNlE#gid=0

    giuseppe: For Use Case 6, I'd like to go through the comments.
    ... First is from me.
    ... We often talk about a set-top box but we should include any
    type of tuner. This was agreed by the authors.

    giuseppe: Also, it shouldn't matter in the use case if you are
    a paid subscriber or not.
    ... We should also cover any kind of application that wants to
    control the tuner, not just an EPG.

    gmandyam: When we talk about EPG being a web application, does
    it need to be accessible to the browser? Would it have to be
    retrievable by, e.g. XHR?

    giuseppe: In the scope of this use case, it was intended to be
    a web page containing EPG data, not fetching it from the
    broadcast stream.

    whyun: Are you saying the web page contains the EPG data? A web
    page can have a list of channels available, but we were
    thinking of something broader.

    Bin_Hu: It's OK, we carry on and come back to questions later.

    gmandyam: The use case doesn't say how the EPG data is made
    available to the web app. Is there an assumption that EPG data
    is retrievable through existing standards such as XHR, Web
    Sockets, etc.?
    ... Because it could also come from broadcast streams.

    giuseppe: The web page is designed to have that data included.
    It's probably not the focus of this use case but could be part
    of a metadata use case in future.
    ... So for now, EPG data is just some data that is part of the
    web app.

    olivier: EPG data seems too vague for our needs. Maybe it's
    better to specify it where possible, such as channel data,
    timing data, etc.

    giuseppe: We could use another term. What we're saying here is
    that a web app can tune into a channel and its data.

    olivier: but channel is only one part of EPG data.

    giuseppe: So we need to rephrase this, if we have another
    suggestion.

    giuseppe: Anyway, let's move on if there are no further
    suggestions.

    Bin_Hu: So Giuseppe, will you edit the use case to make the
    phrasing a bit clearer?

    <giuseppep> "The TV broadcasting service provider (or third
    party service provider) provides application such as EPG which
    can provide mapping information of the TV channel."

    giuseppe: The other has already clarified the wording so I'm
    happy to leave it as it is, with the comment.

    <olivier> (fine with me)

    giuseppe: The rest of the use case is fine with me.
    ... We don't need to use the word "installed" web application.
    ... I think we go ahead with this.
    ... Do we have an agreement on this?

    skim13: Yes, we just wanted to see what you think of our
    suggestions. We will update the wiki.

    giuseppe: Yes, I'm happy.
    ... For Use Case 7 it was similar comments.
    ... E.g. the subscriber issue, the general device, not just
    STB, etc.

    skim13: Do we agree, instead of using the word "set-top box" we
    use "device with tuner"?

    giuseppe: Yes, either we use "device with tuner" everywhere, or
    we specify it once and then say "device" after that.

    olivier: I think the second case is probably clearer

    <ddavis&gta; +1

    giuseppe: So I propose "user-activated device with tuner"

    skim13: I'll update use case 7 based on the comments.

    <olivier> assign actions?

    <scribe> ACTION: skim13 to update use cases 6 & 7 based on
    comments. [recorded in
    [10]http://www.w3.org/2013/10/02-webtv-minutes.html#action01]

    <trackbot> Created ACTION-146 - Update use cases 6 & 7 based on
    comments. [on Sung Hei Kim - due 2013-10-09].

    giuseppe: I'd like to ask about the use cases - are we going to
    work with all of those on the page or split some off to the
    next iteration?

    Bin_Hu: Not sure - what's your suggestion?

    giuseppe: I don't think all of them have requirements - only up
    to use case 9

    ddavis: For example, use case 12 is potentially large so could
    be for a different iteration.

    olivier: My suggestion is to keep the use cases but to
    prioritise based on the requirements. That's where our main
    work is.

    giuseppe: We have limited time, so if we don't have the time to
    go through all the use cases, we could move them to the next
    iteration.

    olivier: We've mostly done that already. We should look at the
    current list of requirements and see if we need to work on them
    or define them better.

    <olivier>
    [11]https://docs.google.com/spreadsheet/ccc?key=0AvACjV6qSvmxdE
    ctdjYwa2JOalZLOG10elE1LVRZNlE#gid=0

      [11] 
https://docs.google.com/spreadsheet/ccc?key=0AvACjV6qSvmxdEctdjYwa2JOalZLOG10elE1LVRZNlE#gid=0

    giuseppe: But use cases 10, 11, 12 are not in the requirements
    doc.

    olivier: You should be looking at the spreadsheet, that has the
    latest information.
    ... We have a number of crosses for use cases 8 and 9. Who
    worked on that? Was that discussed already?

    Bin_Hu: In the previous conf call, we decided to split Req 1.5
    into several requirements.

    olivier: Sheau is not on the call. It would be good to agree on
    this today to get rid of the red crosses and get it finalised.
    ... Shall we go through the red crosses in the spreadsheet?
    ... First is for Use Case 1 - Device discovery mechanism
    ... I agree there is an element of device discover so I would
    say yes. No objections?
    ... The bulk of issues are for use case 8 and 9, which both
    require authentication.
    ... Sheau's comment seems to be for any commercial service that
    requires authentication. So I would say yes to all six question
    marks.

    Mark_Vickers: There is non-commercial use of these things as
    well. Commercial use is valid but there will be cases for using
    this without commercial interests as well.

    olivier: Last was mutliscreen advertising.
    ... Question was about device discovery mechanism so this is
    very close to use case 1. You have several devices discovering
    each other so I'd say this is also a "yes".

    Bin_Hu: Some services running on a device can not be
    co-related.

    giuseppe: It depends what a service is.
    ... If you want to be generic, it doesn't really matter what is
    a service or a device.
    ... My impression was that if you say "service" you don't need
    to distinguish between service and device.

    olivier: There's no use case where you'd one (e.g. service) and
    not the other (e.g. device).

    giuseppe: People have UPnP in mind when thinking of this. There
    could be sub-services or sub-routines.
    ... So the main requirement here is that we need an API to talk
    with another entity - another device, service, app, something.

    olivier: So I think we can leave the requirements as they are
    for now.
    ... I think the main issue is 1. that we need to get this
    mapping back into the wiki.
    ... How do we make sure we have one clear source for this
    mapping. I like the idea of a table but it may not be best to
    have a Google spreadsheet as our main source.
    ... A proposal: I suggest we should remove the mapping from the
    requirements document.

    giuseppe: With the table, we can keep it in a Google doc and
    later put all this in a HTML page.

    <scribe> ACTION: olivier to edit requirements doc to remove
    mapping and add a link to the Google spreadsheet. [recorded in
    [12]http://www.w3.org/2013/10/02-webtv-minutes.html#action02]

    <trackbot> Created ACTION-147 - Edit requirements doc to remove
    mapping and add a link to the google spreadsheet. [on Olivier
    Thereaux - due 2013-10-09].

    <inserted> [13]Requirements document

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

    olivier: Next, how do we get from there to the gap analysis?
    Giuseppe - any experience to share from the Home Networking TF?

    giuseppe: I think we should go through the requirements and ask
    if there's a way to achieve this with existing specs.
    ... If so, which ones and do they have partial or full
    coverage?

    ddavis: This would require cooperation with other WGs

    giuseppe: If we determine which WG is relevant for unmet
    requirements we can then contact them.

    olivier: I'm not certain that going through them one-by-one is
    best.
    ... I suggest people on this call look at the requirements and
    volunteer to take one each.
    ... If each of us take one requirement and start looking at
    which technologies fulfil the requirement, if any, we can then
    come back to the group later.

    Bin_Hu: Yes, we can divide the work.

    olivier: If each person takes just one we can start small.

    giuseppe: We could do it like that, or I don't have a problem
    going through the reqs seeing which is covered by e.g. the
    Network Service Discovery API (probably more than one).

    Mark_Vickers: I think there's an advantage to having a
    discussion because it would increase everyone's knowledge.

    Bin_Hu: Giuseppe probably has an overall idea already of which
    requirement is satisfied by which spec.
    ... Maybe Giuseppe can take the first round quickly and see
    what is covered. Based on that we can narrow down the remaining
    requirements.

    giuseppe: Yes, not all of them but some of them.

    olivier: You mentioned the NSD API - are there other
    technologies that we should be aware of as big candidates?

    giuseppe: We could make another wiki page with the technologies
    and then list the requirements covered by them.
    ... I can try to send an initial mail about the specs I was
    thinking of, and then after people have looked at it we can
    discuss it in the call.

    kaz: In the MMI group we looked at a standard set of events to
    be used by several devices. These days, several vendors and
    hardware makers are joining the discussions.
    ... We've started to think we need a separate resource manager.
    So I agree with you - we can generate a first round of ideas
    and then follow up in conference calls.

    giuseppe: We can have a table with a column for each technology
    and put a cross for each one that is covered.

    olivier: You can see this now in the Google spreadsheet.
    ... It's in a new tab.

    giuseppe: So each one of us should start looking at this.

    olivier: Incidentally, requirements no. 24 does not have a
    link.

    gmandyam: It's OK, I'll do that.

    Bin_Hu: I suggest in column B, instead of listing the
    technologies one by one, we should call the column
    "technologies" and enter the individual technologies in the
    cells.

    <olivier> WFM

    Bin_Hu: This should be easier to work with.

    giuseppe: If you have more than one spec in a cell, you can't
    put status details in the cell in column C

    olivier: How about three columns - tech 1, tech 2, tech 3. If
    there's more, we add a new column.
    ... The idea is just to get an idea of how many technologies
    for each requirement.
    ... I agree with both of you - crosses everywhere could be
    tedious.

    giuseppe: It's probably better if people send an email to the
    list when they have technologies that cover a requirement.
    ... It's not going to be hundreds anyway.

    olivier: So, for homework, we should all send
    technology/requirement suggestions to the list.

    giuseppe: Yes, especially authors of the use cases.

    olivier: Anything else to work on?

TPAC

    olivier: One thing to think about is the face-to-face

    <kaz> [14]TPAC page

      [14] http://www.w3.org/2013/11/TPAC/

    olivier: If you haven't yet, please make your travel and
    especially hotel arrangements NOW!
    ... If you need a visa, get an invitation letter for it NOW!

    olivier: There is a discussion on the mailing list about the
    agenda. Do we need to bring anything to the whole group in
    addition to our existing work?

    kaz: Just to confirm, we should go head and make reservations
    for the hotel and start visa procedures as soon as possible.

ATSC 3.0

    gmandyam: Slight change of topic - some people on the call may
    know, the ATSC is working on version 3.0 of their tech.

    <gmandyam> ATSC has begun work on the ATSC 3.0 standard.
    Presentation layer and runtime requirements have been defined,
    and the group is examining HTML5 as a solution. Would it make
    sense to liase with the relevant subgroups in ATSC (e.g.
    written communication and/or joint meeting)?

    gmandyam: I can arrange a liaison if necessary.
    ... The group is not trying to re-invent the wheel. If both
    groups are doing similar gap analysis, it makes sense to avoid
    duplication.
    ... Also, HbbTV is another tech that leverages HTML5 as well.

    giuseppe: In terms of liaisons with other groups, we're very
    open to send and receive requests by individual groups.
    ... No formal permission is needed.
    ... Sometimes we have written to external groups, e.g. by the
    Testing TF, and got replies from various organisations.
    ... Also, some external groups like HbbTV write to us with
    info.

    gmandyam: There's a requirements doc in ATSC that's already
    been approved.
    ... The official liaison letter would have a list of those
    requirements.
    ... I imagine HbbTV is doing something similar. It would then
    be up to this IG to check through the list of requirements.

    giuseppe: We could certainly use such a list with things we may
    not have considered.
    ... About the agenda, we're not discussing that on the public
    list yet.

    olivier: But will be in due course.

    giuseppe: At TPAC, we should try to conclude this gap analysis.
    ... We could maybe also discuss new use cases if there's time.

    <olivier> +1

    olivier: Any further business?
    ... OK, we can adjourn.
    ... Next meeting is on 16th October, at the same time.
    ... If you can't make it, please send your regrets.

    <CyrilRa> Regrets oct 16

    olivier: Call is adjourned.

    <olivier> thanks all

    <olivier> good meeting

    <kaz> [ adjourned ]

Summary of Action Items

    [NEW] ACTION: olivier to edit requirements doc to remove
    mapping and add a link to the Google spreadsheet. [recorded in
    [15]http://www.w3.org/2013/10/02-webtv-minutes.html#action02]
    [NEW] ACTION: skim13 to update use cases 6 & 7 based on
    comments. [recorded in
    [16]http://www.w3.org/2013/10/02-webtv-minutes.html#action01]

    [End of minutes]
      __________________________________________________________


     Minutes formatted by David Booth's [17]scribe.perl version
     1.138 ([18]CVS log)
     $Date: 2013-10-02 14:27:04 $

      [17] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [18] http://dev.w3.org/cvsweb/2002/scribe/

Received on Wednesday, 2 October 2013 14:43:14 UTC