See also: IRC log
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> 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>a; +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 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> 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 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> Requirements document
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?
olivier: One thing to think about is the face-to-face
<kaz> TPAC page
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.
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 ]