See also: IRC log
Clarke: Anything to add to the
... Looking at the "issues" page, sent to the list earlier.
<Clarke> issues: http://www.w3.org/2011/webtv/track/products/4
Giuseppe: There's a link to the tracker at the top of the wiki page in the quick links.
<inserted> Web&TV wiki
Clarke: Let's go over raised issues first.
Clarke: Starting with issue 62
"Media source extension"
... They have all been included in the use cases.
... Bin, have they adequately been addressed?
Bin_Hu: Yes, I think it's already included in the use case document so that's good.
<inserted> (check the status of issues and actions)
<giuseppe> close issue-62
<trackbot> Closed issue-62.
<giuseppe> close issue-63
<trackbot> Closed issue-63.
<giuseppe> close issue-64
<trackbot> Closed issue-64.
<giuseppe> close issue-58
<trackbot> Closed issue-58.
<giuseppe> close issue-67
<trackbot> Closed issue-67.
<giuseppe> close issue-61
<trackbot> Closed issue-61.
<giuseppe> close action-108
<trackbot> Closed action-108.
<giuseppe> close action-109
<trackbot> Closed action-109.
<giuseppe> close action-110
<trackbot> Closed action-110.
<giuseppe> close action-111
<trackbot> Closed action-111.
Giuseppe: Should we use Google Docs instead?
Clarke: The tools we have already
do it in the correct format.
... But I'd be open to do it in Google Docs
Sheau: Google Docs works well in my experience.
Giuseppe: With Google Docs you can just share the link and make edits
Clarke: I'm happy to do that. Anybody opposed?
<scribe> ACTION: Clarke to move the requirements document to Google Docs [recorded in http://www.w3.org/2013/08/14-webtv-minutes.html#action01]
<trackbot> Created ACTION-131 - Move the requirements document to google docs [on Clarke Stevens - due 2013-08-21].
Clarke: We've now completed and closed the survey.
<giuseppe> close action-112
<trackbot> Closed action-112.
<giuseppe> close action-117
<trackbot> Closed action-117.
Clarke: That completes the action items. Next, let's talk about the table.
Giuseppe: Did you discuss how to aggregate the results in the last call?
Clarke: No, we wanted to have you here.
Giuseppe: OK, so it should be
clear what I've done and how I've put the sum of the votes from
... I haven't done any normalization or calculating averages.
... So we have two options - either we create two "mandatory" and "optional" choices
... or we create a ranking, ordering by priority
Clarke: I like the ranking
... If it makes sense, we could do ranking and whether it got one or more votes for "mandatory".
... I think ranking would be most useful for me.
Giuseppe: By the way, the table can already be ordered.
Sheau: Would it be useful if we normalized the internal/external vote because at the moment they're very different.
Clarke: I think that would be useful.
Giuseppe: Also, are the votes/ranking the same thing for internal and external?
Clarke: Would you suggest doing two separate tables or both ranking numbers in a single table?
Giuseppe: You can have two
columns in the same table for external and Web & TV
... You could then have the final ranking based on the sum.
Clarke: That makes sense for the
ranking and aggregate results.
... The columns after the "Category" - do we want to include those?
... CoreMob is not confidential. Is it useful to have that there?
Giuseppe: We can leave it in because it's something that they (Tobie's group) is already using.
Clarke: So "group", "category",
"CoreMob", maybe something that says "mandatory" for anything
that got at least one "mandatory" vote
... then something for external votes, then a composite ranking.
Giuseppe: I'd skip "mandatory" because it's difficult to measure
Clarke: So "group", "category",
"CoreMob", internal vote, external vote, final vote.
... Ranking should be 1 for the highest vote-getter? Or display a percentage?
... You'd get a little more information if you use percentage.
Giuseppe: We could just leave the numbers how they are, putting them in order, and explain how we got there.
Sheau: I find percentages easier
... Numbers feels like having my feet in two separate boats.
Clarke: I don't see any reason to
not use the raw numbers (percentages)
... If we have the total respondents in the header and then below a paragraph or two explaining our methodology.
... Now on to the Word document.
Giuseppe: Who's going to do the table work?
Clarke: Why don't you go ahead and finish it off.
<scribe> ACTION: Giuseppe to finish the table display/columns. [recorded in http://www.w3.org/2013/08/14-webtv-minutes.html#action02]
<trackbot> Created ACTION-132 - Finish the table display/columns. [on Giuseppe Pascale - due 2013-08-21].
<inserted> updated document (member-only)
Clarke: On to the next item and there are some changes.
Giuseppe: Regarding the document in general, there seem to be inputs from different mixed groups so I'm wondering how we should organise it.
Clarke: I'll put the doc on
Google Docs today and you can make any changes or organisation
suggestions on there.
... Look at section 5.2.11
... It looks like a requirement was not captured here before. Any comments about that addition?
Giuseppe: What's the point of
just listing one or two things for each spec?
... Maybe there should be a dedicated bit with these specs and why.
Clarke: Our objective is to look
at test tool requirements and communicate that in a logical
... What you're suggesting is a list of requirements and beneath that, a justification?
Giuseppe: We started listing
general requirements but now we have requirements for specific
... I'm not saying we shouldn't do it but we should say why we're doing it.
... Also, some specs (EME, MSC) are not in the table
... So there are some requirements here just for EME and MSC - why are we picking things only for these specs?
Clarke: One reason is that they
were listed as use cases.
... Generally we try to take use cases and extract requirements from those.
... I listed all the use cases we went over in the group. Admittedly they may not be completely normalized.
... I'm open to other ways of doing this.
... We had some general overview kinds and then we had some more specific use cases.
... I agree that it's not ideally presented so would be good if you had suggestions for improvement.
Giuseppe: OK, I'll write
something - that would be easier to explain.
... I'll put it in an email. I think we should have general requirements and for specific specs, a separate section.
... with an explanation why.
Clarke: What I want to say is
that these use cases exposed certain requirements for a test
tool that may not have been covered in other use cases.
... We picked out use cases that were relevant to web on TV in order to expose requirements for this are that may not be in other groups.
Sheau: Is it correct to say this reflects the group's gap analysis?
Giuseppe: Actually, we haven't
done a gap analysis.
... Although this was a bit special, we now have the use cases, we have generated a requirement.
... Next is to discuss ongoing work to see if there are some requirements not covered, during which we can do gap analysis.
Clarke: In section 6.1.4 there
are some comments specific to Media Source Extensions
... The comments cover splicing.
... I think our detail is a bit inconsistent - in this case we have a lot of detail.
Giuseppe: The content may be valid, we just need to justify why it's like this.
Clarke: No comments on this
... OK, that's all the additions that have been made.
... We were hoping to complete this by the end of the month which is still possible.
... In order for it to be a successful document, we need comments and participation.
... Let's move on to scheduling and anything general we want to cover.
Clarke: I'd like to have a list of requirements we can sent to the HTML testing group by the end of this month.
Giuseppe: We don't necessarily
need to wait. We have the table so we could send that out
before the requirements document.
... And regarding gap analysis, we can do that later
... after we've seen how the HTML group is testing, e.g. TV/STB devices which may have special requirements.
Giuseppe: Maybe we should look at
that aspect, such as do we need to have support for
... Maybe make a list of things to be aware of or what a device needs to support.
Clarke: That would be useful. Do you have any sample docs that could be used as a template?
Giuseppe: No, but we can make it
... It could start as an index, to have a starting point for the TV aspect.
Clarke: Good idea. Any other
... Let's get the table normalized and ready for publication before the next meeting in two weeks.
... Any other comments, I'll try to get them integrated by then.
... We can then publish the requirements after that.
Kaz: Do you want to make the requirements doc and table into an official note?
Clarke: I think it could be useful published as a separate note.
Kaz: Maybe we could publish it as a note including the whole requirements.
Clarke: There could be a tracking issue but I don't think we'll make changes because it's a survey.
Kaz: If needed we could merge the two notes later.
Clarke: Anything else?
Bin_Hu: So we'll talk about the schedule next time?
Clarke: Yes, there are a couple
of small things which are achievable in the next two weeks so
see where we are after that.
... The requirements doc may need extra work after that.
... OK, meeting adjourned - see you in two weeks.
<Clarke> Thanks for scribing, Daniel
<kaz> [ adjourned ]