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> 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?

TPAC

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.

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 ]