TV Control CG/WG call

03 May 2016


See also: IRC log


Francois, Chris, Kaz, Bill_Rose, Jo_Woodward, Sung_Hei_Kim, Alexander_Futasz, Andreas_Bosl, Bin_Hu, Tatsuya_Igarashi, Chris_Poole, Steve_Morris, Younsun_Ryu
Francois, Kaz


Chris: Welcome everyone to the call. This is the first joint call between the Community Group and the Working Group.
... The scope of the work is about sourcing audio/video streams.
... [going through the agenda]


Chris: Working for BBC R&D. Chair of the TV Control WG. The interest we have here is the convergence between TV and the Web and in particular in how we can source audio/video sources into the Web browser.

Alexander: We have been part of the CG to bridge the gap between TV and Web industries. We have pushed Mozilla to adopting the spec, with little success. Unfortunately, we recently lost the editor of the spec from Mozilla.
... We're monitoring the interest.

Bin: Working for AT&T. Involved in the CG since it started. We have published the first version of the spec at the end of October last year.
... Great achievement for the community group, thanks for everyone involved!
... We fully support the work, although for some internal reasons we cannot join the WG for the time being.

Andreas: from IRT, R&D for broadcasting in Germany ... Interested to to support radio in the API.
... We also implemented a small prototype of the current spec on an Android device, to get the DVB-T signal from a dongle.

Jo: I'm From Eurofins testing. We do test materials for TV specifications such as the TV Control API. My interest is to see how things progress here.
... We have experience from HbbTV in particular.

Chris_Poole: colleague of Chris in the BBC R&D. I've been involved in connected TV standardisation in the last few years.
... HbbTV and national standardisation in the UK.
... Interested to see how the API evolves, and on whether it duplicates what already exists in the connected TV world or whether it approaches the topic differently.

Igarashi: I work for Sony. I have been involved in several iTV organizations, recently ATSC.
... Many iTV systems define their own API, but I think we need a global one.
... Interested in making the TV Control API a Web standard.
... I think we need to think about the secure aspects of TV Control.

Chris: I fully agree with respect to the security questions.

SungHeiKim: From ETRI, in Korea. I was involved in standards for Smart TVs. This group is highly relevant for us.

Steve: I'm Steve Morris from Espial, based in the UK. We've involved in various standardisation activities including the HbbTV. Willing to become more engaged now that the WG has been created.

Bill: Consultant working for Comcast, NBC Universal.
... Making the delivery of content more efficient. Watching how this work is doing just to see how it intersects with the GGIE.
... Also looking at intersection with WAVE.
... WAVE looking at HTML5 and other Web technologies to create universal media content.

chris: Youngsun, how about you?

youngsun: from Samsung, working for standardization for TV
... hope to make this spec work

Kaz: I've been working for the CG since the beginning. I work for the Automotive group, which is interested in the radio tuner. Big overlap between the group on this topic.

WG procedure

fd: Kaz and myself are W3C staff contacts
... my role is helping Chair and the group
... what I'd like to do within a few minutes is let you know about how W3C work
... WG will work based on 3 main documents
... 1. W3C Process
... 2. W3C Patent Policy
... 3. TV Control WG Charter
... which defines the scope of the group's documents
... these documents are to be followed by the group
... if the group is wondering something, we should follow the documents
... they're set of rules
... the main emphasis is that W3C is an organization based on consensus
... now we're working as a WG
... to generate a Rec Track document, TV Control API
... FPWD is important for disclosure of essential claims
... and then we'll generate several WDs
... it may take time
... would note about the horizontal reviews
... TV Control API spec needs to get reviews by Internationalization, Accessibility, TAG, etc.
... can't be on our own
... the Editor is going to edit the spec
... one or more Editors can be assigned
... right now the group doesn't have official editor
... and need scribes for taking minutes for meetings

Charter and scope of work

TV Control Working Group Charter

Chris: The charter defines the scope of the group. It tells us what the group is able to work on. [reading out scope]
... The scope really includes most of the functions that a typical TV receiver or set-top box device includes.
... If you read the draft spec, you'll see that a lot of these features are covered already in the work of the CG.

<inserted> TV Control API draft spec

Chris: However, we need to be aware that this is a Web specification that we're building, and therefore we need to define the relationship between the device-capabilities that the device will have and what the Web browser will have.
... This ties us back to privacy and security issues.
... What sort of features are compatible with a Web runtime environment.
... Note we'll need to look at accessibility issues as well, and on the relationship between the API and the underlying broadcast protocols.
... Where we're using a particular transport, e.g. DVB, how do the entities that we have in the API get sourced from the underlying delivery format?
... Things that are not in scope: the actual sourcing technologies, developed elsewhere.
... We may be interested to look at mappings though, as just said.
... Another thing that is out of scope is presentation technology, and finally profiling of the specification to particular device limitations.
... We want to keep the API as useful in the generic case as possible without introducing constraints such as the number of streams that may be viewed at once).
... We may need to look at what happens when a device can only source one stream at a time, though.
... At the moment, we've only identified one specification, the TV Control API spec, but the group may produce more specifications if needed, e.g. use cases and requirements, primer, etc.
... The last piece that I'd like to cover is the timescale that we've set for ourselves. From the charter, you'll notice that we said we'll have a First Public Working Draft during Q2 2016, CR in Q3 2016.
... This seems quite an ambitious timescale, and we'll see how we can go through the different horizontal reviews that Francois mentioned.
... Any question?

Kaz: Just wondering about the relationship between the Cloud browser task force within the Web and TV IG and this group.
... There may be some overlap.

Chris: That's possible.
... I've been following the Cloud browser discussions. There's a local part that runs on your local device, and a remote part that runs on the cloud.
... The TV Control API would run on the cloud part, probably. We have not had any discussion with the Web and TV IG yet, but that's certainly something we can do.

Kaz: I agree.

Chris: There are a number of groups that are listed in the liaisons section in the Charter, including the Automotive Business Group, the Device APIs and WebRTC WGs as we touch on the MediaStream interface.
... Also HTML Media Extensions WG for the HTMLMediaElement, the Schema.org CG to align vocabularies used in the API with the TV ontology defined by the schema.org CG.
... Also note external organizations.

Group process and tools

Chris: We have a new mailing-list for the Working Group which is separate from the Community Group: public-tvcontrol@w3.org.
... Initially, we should cross-post to both mailing-lists (public-tvapi and public-tvcontrol) as the transition progresses.
... We also have a new Wiki but there's not much content there.
... I'll add more content and share the link once ready.
... In terms of issue tracking, so far we've used the W3C tracker tool.
... I have a proposal: I'd like to use the GitHub issue tracker to ease tracking issues against the specification, edited on GitHub.
... Does that sound ok to everybody?

Alexander: This sounds reasonable. Maybe make a difference between issues that relate to the specification and other kinds of actions. Maybe use the old tracker for them?

Chris: I agree. If it's an action that comes out of a meeting, e.g. "look at radio requirements", we could continue using the existing task tracker.

Kaz: Because I work for Web of Things and Automotive groups as well, I'd like to suggest we only use one issue tracker and rather use labels to flag issues.
... Recording issues on separate tool locations could be confusing.

[+1 to Kaz!]

Chris: Does GitHub work well with such actions?

Kaz: Yes, it's fine.

Chris: Happy to work that way, then.

Kaz: I note I personally like the old tracker very much :)

Alexander: I trust your experience.

Chris: Any other point of view? My recommendation is to start using GitHub issues.

Kaz: In that case, we're going to create a specific repo for this group?

Chris: That's a good question.
... Right now, we have w3c/tvapi

Kaz: This is related to how we manage the two groups
... If the CG is to continue, maybe it's better to create another repo.

Chris: Right, this relates to the transition we need to discuss.

tidoust: we can clone the repository from tvapi to tvcontrol
... definitely depends on what the CG would like to achieve
... if we want we can keep it
... easy to do either way

Kaz: We may want to talk about this issue on the mailing-list for a few weeks.

Chris: Yes, I'm just thinking to myself: the question is what is the nature of the work that will continue in the CG.
... It seems to me that in the Community Group, there is some topic, in particular around radio, that is not yet ready to be brought in the spec as things stand. So the question is whether to continue the work in the CG, or whether we transition the work in the WG.

Kaz: The Automotive group had their F2F in Paris last week. They separated trackers for the BG and the WG. The BG is concentrating on Media tuners and so on, initial discussions for new topics.
... If there is a clean separation like that, keeping two groups is fine, otherwise integration is probably better.

Chris: I agree, let's ask the CG about how it feels it should go.
... I think we have most of the active participants here.

Alexander: I would be fine reusing the same repository, but it's a good idea to give people a chance to give an opinion on this.

<scribe> ACTION: Chris to ask the CG about transitioning the GitHub repository to the WG [recorded in http://www.w3.org/2016/05/03-tvapi-minutes.html#action01]

Chris: About the conference calls, there's a list of times for the next calls for the next year. They are every four weeks. There has been some suggestion that they be more per calendar month instead.
... OK, seems like we're all happy with the existing schedule. So every 4 weeks, same timeslot, this time on Tuesdays.

Upcoming meetings

<inserted> scribenick: kaz

tidoust: once a year, W3C holds a Member meeting
... this year TPAC will be held in Lisbon, Portugal
... TV Control WG will meet during TPAC

<tidoust> http://www.w3.org/2016/09/TPAC/schedule.html

tidoust: the above is the current schedule
... our meeting is scheduled on Tuesday
... registration for TPAC will open next Monday

chris: tx
... and the Web&TV IG will meet on Monday as usual

tidoust: yes

chris: we don't have another meeting planned at the moment

Spec status

Chris: We already covered that topic to some extent
... Main question is how do we produce a First Public Working Draft out of the final report of the TV Control API CG.
... Question is whether there is an outstanding issue that we need to resolve before publication as First Public Working Draft.
... I've been thinking in terms of the security review that we initiated. As yet, we have not identified the impacts on the spec. I think we should pursue the work a bit further to inform the spec.
... Another area where we need to improve the spec is around setting the context. I would like to see at least some introductory text.
... This leads to the main concern actually: the editor of the spec is no longer with the group, so there's a gap right now.
... Can I ask all of you present on the call today whether that's something you might be willing to take on, or if there's someone in your organization who could do it?
... This is a very important role, we need an editor to make progress on the specification.

<kaz> CG Report

Youngsun: I have 2 comments. First of all, regarding the spec status, I think we need broad review. We need more time to review the CG report. Also, I am interested to joining the editing team.

Chris: Excellent! I agree with you. Your comments would be very welcome. If you want to raise those, just post them to the mailing-list while we figure out which issue tracking tool we're going to use.

Kaz: Theoretically, editor is the person who manages the editorial changes. If we use the GitHub environment, that would be the person who manages the Pull Requests.
... Sometimes, we simply say that all people are editors or authors, but we should be careful who should be the main manager and who would be contributing to the different sections.

Chris: Yes, the editor should be the one responsible for reflecting the consensus of the group into the spec, while any of use can be authors of contributions.
... Does that change something for you, Youngsun?

Kaz: Youngsun, you're interested in contributing concrete text, right?

Youngsun: Not sure, at this point.

Chris: OK, this does not have to be settled right now.
... Maybe that's another questions that I should be put to the mailing-list.

Current discussion topics

TAG F2F - Minutes from Day 1
TAG F2F - Minutes from Day 2

Chris: the TAG had a F2F meeting recently and the TV Control WG charter was on their agenda. They raised some interesting comments.
... They are wondering whether specific APIs such as the TV Control API or the ones coming to the Automotive group should be rather exposed as network resources.
... As far as I know, the TAG does not have particular guidance at this point. I assume this is a relatively new issue for them.
... I think we'll need to have a discussion with the TAG before long.
... We want to integrate with the rest of the Web platform as much as we can.
... That would be a good conversation for us to have with them.
... I'll pick up some of their comments.
... About the network resource vs. the JavaScript API approach, Yosuke was on their call the second day to give a perspective on what we're trying to achieve. Within the CG, we've not really discussed audio/video streams as network resources that we can control.
... There was some discussions in the TAG on whether we're doing Bluetooth, which is not the case, but I can understand why they may think that.

<cpn> https://github.com/w3ctag/spec-reviews/issues/111

Chris: I realize that they have an open issue for us.

Francois: I would summarize the TAG's comments on the mailing-list first, discuss them to create responses
... and then get back to the TAG

Kaz: I agree with Francois. I just wanted to mention related discussions in the Automotive group in Paris.

<kaz> automotive api levels

<kaz> WoT approach

Kaz: From the Automotive side, the two pictures I just pasted describe the 3 levels of interfaces for automotive systems. The lower level is system level, corresponds to C++ programming.
... The second level is between the Web runtime and the server, and this interface should be described by WebIDL, but some participants would like to use WebSockets here.
... The third level between the Web runtime and the application is described with WebIDL.
... This group could try the socket approach, that's possible. If the group wants to continue with the WebIDL approach, we can simply continue in that direction as well.
... e.g. because of the industry need, or people's opinions.
... The second picture shows a similar discussion in the Web of Things IG.
... It may make sense to concentrate on the TV Control part if needed.

Igarashi: I'd also like to know about what Kaz suggests, and on the network-approach impacts.
... This may not talk about an API abstraction layer, but rather as an interface gateway.

Kaz: Yes, this diagram is a simple way to express 3 main API levels.

Igarashi: So WebIDL is the highest abstraction, and Web sockets a middleware abstraction?

Kaz: Please don't be confused by the terms used here. WebIDL here is really used to mean JavaScript interfaces.
... JavaScript APIs, Websocket, C++ APIs could be implemented on top of the same API.
... It may make more sense to discuss these details in the Automotive group

Igarashi: Is the Automotive group going to provide some feedback to the TAG?

Kaz: Yes, they will.

Igarashi: I'd like to know.

Kaz: It may make sense to "join forces" between the Automotive and TV Control groups.
... The Automotive group felt that the TAG did not suggest to follow one of these approaches, just that it suggested to look into them.

Igarashi: The benefit of the Websocket API is that it may be easier to add to browsers.

[I think that matches what abosl did for the TV Control API prototype he's been building, by the way]

Chris: I think we should discuss this on the mailing-list to see what approach might work for us. As part of the discussion on security, the separation of features might be useful.
... What you showed Kaz is interesting and of interest to us as well.

Igarashi: Does any other working group define an interface between a browser and a server?
... Is the Automotive group the first one to do that?

Kaz: The Web of Things IG has been discussing along these lines as well. MMI to some extent.

Igarashi: I think this is more protocols for me than interfaces.

Chris: Security and privacy, which I've been looking at, I need to write up some notes and share with you on that. It really exposes challenges with exposing channels to arbitrary Web pages.
... I am not yet at the phase where I can suggest changes to the API itself.
... The last point on the agenda is related with the work that Ryan Davies has been doing in the Automotive Business Group around media tuners.
... Last exchanges were around zones.
... Ryan thought this could be applied to the home as well.
... to route audio output to different players in the home
... This is different from what we've been discussing so far, where we view the TV device as one device.
... I'm hoping that Ryan will come back.

Kaz: The Automotive group had discussions on the next steps last week, and want to reactive the media tuner discussions.


Chris: I realize we've run massively out of time... sorry about that. Any other comments?
... I'd like to thank you all to attend this meeting. Next one should be the 31st of May. I hope we'll have good discussions on the mailing-list in the meantime!

[Call adjourned]

Summary of Action Items

[NEW] ACTION: Chris to ask the CG about transitioning the GitHub repository to the WG [recorded in http://www.w3.org/2016/05/03-tvapi-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/05/03 15:33:55 $