See also: IRC log
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.
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
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.
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.
<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
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.
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]
