- From: Francois Daoust <fd@w3.org>
- Date: Tue, 3 May 2016 17:35:18 +0200
- To: <public-tvcontrol@w3.org>, <public-tvapi@w3.org>
Hi all,
The rough minutes of today's discussions are available at:
http://www.w3.org/2016/05/03-tvapi-minutes.html
... and copied as raw text below.
Thanks,
Francois.
-----
TV Control CG/WG call
03 May 2016
[2]Agenda
[2] https://lists.w3.org/Archives/Public/public-tvcontrol/2016Apr/0005.html
See also: [3]IRC log
[3] http://www.w3.org/2016/05/03-tvapi-irc
Attendees
Present
Francois, Chris, Kaz, Bill_Rose, Jo_Woodward,
Sung_Hei_Kim, Alexander_Futasz, Andreas_Bosl, Bin_Hu,
Tatsuya_Igarashi, Chris_Poole, Steve_Morris, Younsun_Ryu
Regrets
Chair
Chris
Scribe
Francois, Kaz
Contents
* [4]Topics
1. [5]Introductions
2. [6]WG procedure
3. [7]Charter and scope of work
4. [8]Group process and tools
5. [9]Upcoming meetings
6. [10]Spec status
7. [11]Current discussion topics
8. [12]AOB
* [13]Summary of Action Items
* [14]Summary of Resolutions
__________________________________________________________
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]
Introductions
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. [15]W3C Process
... 2. [16]W3C Patent Policy
... 3. [17]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
[15] https://www.w3.org/2015/Process-20150901/
[16] https://www.w3.org/Consortium/Patent-Policy-20040205/
[17] https://www.w3.org/2016/03/tvcontrol.html
Charter and scope of work
[18]TV Control Working Group Charter
[18] https://www.w3.org/2016/03/tvcontrol.html
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> [19]TV Control API draft spec
[19] https://www.w3.org/2015/tvapi/Overview.html
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
[20]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> [21]http://www.w3.org/2016/09/TPAC/schedule.html
[21] 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> [22]CG Report
[22] https://www.w3.org/2015/tvapi/Overview.html
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
[23]TAG F2F - Minutes from Day 1
[24]TAG F2F - Minutes from Day 2
[23] https://etherpad.w3ctag.org/p/29-03-2016-minutes.md
[24] https://etherpad.w3ctag.org/p/30-03-2016-minutes.md
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> [25]https://github.com/w3ctag/spec-reviews/issues/111
[25] 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> [26]automotive api levels
[26] https://www.w3.org/2016/04/auto-f2f/28/DSC_0073_480x360.JPG
<kaz> [27]WoT approach
[27] https://www.w3.org/2016/04/auto-f2f/28/DSC_0075_480x360.JPG
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.
AOB
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
[28]http://www.w3.org/2016/05/03-tvapi-minutes.html#action01]
[End of minutes]
Received on Tuesday, 3 May 2016 15:35:28 UTC