Agenda Building

giuseppe: Agenda is in three sections - Past, Present (before and after lunch), Future
... We may also have a discussion about the workshop being planned.
... Any questions about the agenda?

Web&TV Intro

giuseppe: Starting with introductions
... Goals of the charter are to identify requirements and gaps in Working Groups
... To review deliverables of other groups and liaise with other organisations.
... The IG does no spec work - it is different to Working Groups
... It creates requirements and brings them to other WGs. This is to avoid having TV-specific specs

<yosuke> [slide: Web & TV Interest Group Work Flow]

giuseppe: We have the flow User cases -> Requirements -> Gap analysis
... We then send requirements to existing WGs or create a new WG (Working Group)
... If your idea/requirement is not clear, a Community Group could be created to draft a spec.
... In the past, we've had a few task forces

<yosuke> [slide: Closed TFs]

<yosuke> [slide: Home Networking TF (closed)]

giuseppe: We had a Home Networking Task Force dealing with discovery and control of devices.
... It was felt that the DAP WG was best for sending our requirement to.
... A draft spec, called Network Service Discovery API, was created.
... It's still in that WG. Some implementors have raised security concerns.

<yosuke> [slide: Service Discovery]

giuseppe: This can use existing service protocols to communicate with services.

<yosuke> [slide: Media Pipeline TF (closed)]

giuseppe: The other task force was the Media Pipeline Task Force.

Mark_Vickers: The work continues to go on, however.
... These things take time to get into browsers
... Media Pipeline is the definition within HTML5 for video, audio and data streams and how they are defined.
... Originally in HTML5, the media streams were fairly simple
... We worked out requirements for more sophisticated streams
... We firstly did a gap analysis when HTML5 was close to Last Call
... Side note: Last Call is an important time to get bugs fixed in a spec
... We sent a series of bugs to be fixed
... For example, no way to pass metadata for media to the user agent
... If it's covered by the spec in a broad spec but not implemented correctly, you can send a bug report.
... The pipeline was greatly improved because of this - they're already being implemented in browsers.
... In some other cases, there were new cases that didn't correspond to HTML5
... The HTML5 chairs said they should be extension specs.
... They are optional add-on capabilities
... One was adaptive bitrates. This was more than a bug report - an entire document and its requirements.
... They were pushed to a new spec called Media Source Extensions, which is now in Last Call
... It already has early browser support.
... Here's an example - this is the Media Source Extensions (MSE) specification.
... Similarly, the other requirement identified was content protection. We wrote a series of requirements for this.
... This looks like a spec document.
... We have code for use cases
... We also had a MSE proposal which was an early draft.
... This could also be done by a Community Group (CG)
... This is called EME - Encrypted Media Extensions
... It's an HTML5 Extension document
... So most of our bugs and requirements have been taken on board.
... Here is a new Community Group called Media Resource In-band Tracking
... It has mapping to MPEG-2 and other formats
... Work is planned for mapping to WebM and OGG
... This is good work - I encourage you to join in.
... It's in a Community Group (CG) because it's objective is to draft/write a spec.

<jcverdie> Media Resource In-band Tracks Community Group: http://www.w3.org/community/inbandtracks/

giuseppe: An additional comment is that if things are not followed through, nothing will happen.

olivier: The fact that our work needs to be followed up to have an impact, does that mean we shouldn't close the TFs?

giuseppe: That's the case for any group. There have to be people with similar interests to keep things going.

Mark_Vickers: Some of the IG members who wrote the requirements wrote the extension documents, e.g. Mark Watson and Dave @@@

olivier: The work has been followed up because we've been involved in other groups.
... But for e.g. In-band tracks, the IG was not aware of the work going on.

Mark_Vickers: A lot of the work for In-band tracks was in bug reports. There were many bugs that were reported and some of use followed those.
... But there hasn't been a particular method for following those.
... That's a good question - I don't know whether we can track a bug automatically?

<Ruinan> help

Ruinan - can I help you with something?

giuseppe: Maybe one option is to CC the IG if the bug is filed by the IG.
... Any questions? Please press "q+" in this chat if you have a question.

Mark_Vickers: At the end of today we'll talk about new groups.
... We'll ask for ideas for new Task Forces so please think about suggestions.

<Ruinan> ddavis - sorry for my mistake type, I'm not familiar with irc command

<jcverdie> can't see anything, can't hear anything... gonna be great :)

Ruinan - that's fine. You can type whatever you like and I can fix it if necessary. Please don't worry about making a mistake - we're happy for any contribution.

olivier: Metadata, Terminal Control, Record & Download - these are the combined TFs (Task Forces) that make the Media APIs Task Force
... We built upon existing work such as requirements for home networking, terminal capabilities...
... The Task Force is working in iterations. That means its working from use cases -> requirements -> Gap analysis -> feedback to WGs
... We expect that we will have several iterations like this.
... Scenarios are here - http://www.w3.org/2011/webtv/wiki/Media_APIs/Use_Cases
... We need to discuss whether our focus is too broad.

http://www.w3.org/2011/webtv/wiki/Media_APIs

Olivier: Everything so far has been done in public. All our work is publicly available on the wiki
... We have use cases and requirements documented there
... We now have a demo by Franhofer

ChristianFuhrhop3: Sorry - the demo is not working.

olivier: You can see it at the break if you like.
... From that list of requirements we worked on cross-referencing user cases and requirements.
... the idea is to see whether our use cases were well represented in the requirements.
... The current work is the most interesting & useful - gap analysis
... This is working out what is being worked on in W3C and how they relate to our requirements.

Gap analysis document: https://docs.google.com/spreadsheet/ccc?key=0AvACjV6qSvmxdEctdjYwa2JOalZLOG10elE1LVRZNlE#gid=1

olivier: We make sure we have at least one piece of technology fulfilling each requirement.
... Green (check) means we've looked at the technology and it does fulfill the requirement.
... The most interesting ones now are the red (cross) ones. They show that the technology should fulfill the requirement.
... These are my opinions for discussion points - how do we avoid re-inventing the wheel?
... We've used previous task force work and have re-written use cases even though some of this had been done before.
... How do we keep momentum? It took us a lot of time to get started.
... giuseppe said that our TFs are short-lived. How do we make sure it keeps momentum?
... Is our scope too broad for the TF?
... Interacting working with CGs (Community Groups) needs looking into.
... And better use of the output of the Broadcasting Business Group.
... One of the outputs of that group was a broadcasting service handbook.

<jcverdi__> document worked yesterday at BG's face to face meeting: http://www.w3.org/community/webandbroadcasting/wiki/Handbook_of_Web_Standards_for_Broadcasting_Services

olivier: There seemed to be some overlap with our work so we should look at how we do not duplicate effort.

giuseppe: So should we go from the top one - "How do we avoid re-inventing the wheel?"
... Requirement documents have been published so we could maybe make the wiki better to make tracking easier.
... Over the next year, we could clean up the wiki.

Mark_Vickers: One of the challenges was it requires TV industry knowledge, but the gap analysis requires deep knowledge of the W3C - both specs that have been published and specs in the pipeline.
... It's actually an opportunity to educate people and learn the process.

giuseppe: Another issue is that many people were new.
... Most of the participants of this task force were not participants of previous task forces.

Sheau: We experienced this a bit yesterday in the Broadcasting BG. For example, you couldn't have TV experts doing analysis of existing specs.
... In other organisations, sometimes we kick off a couple of ad-hoc groups that exist only for the gap analysis phase.
... I personally don't know what's going on sometimes so it's good to have two or three people to bounce ideas off.

giuseppe: We can continue discussions within the task force and if necessary, generate specific questions.

Mark_Vickers: We could also make better use of staff especially in the gap analysis phase.

Jean_Pierre: I can see the IG and the BG - who is doing what and when.
... Some of the aspects in this group seem to be technical but should it be done by th eBG?
... Also, I said I'd work on the Metadata but I ran out of time, so maybe if there's a deadline it might be better.
... It makes it difficult to contribute.

giuseppe: Regarding the deadline issue, with the last phase of this TF we identified dates.
... After the deadline which we set, we could have no more new use cases.
... We should set dates in advance for three or four iterations per year. Your concern is valid and we're trying to address it.

Mark_Vickers: In some companies, some engineers were assigned for most of a year to work just on specs and W3C work.
... That means that the work of the TF is aligned with a corporate goal.
... Hopefully, these things in this TF are that important that we can have a dedicated engineer working on it, because some things take a lot of time.

giuseppe: If the use cases are refined enough then it's easier to get experts from related groups.
... Otherwise it's more difficult to get help.

Web&TV IG and Web&Broadcasting BG

yosuke: Regarding the BG (I'm the chairperson) and the IG, when I started the BG it was still early stages of the IG.
... When broadcasters brought requirements, it was just from broadcasters point of view. The IG had much broader scope.
... So the TV IG can't cover completely the broadcasters' viewpoints.
... I wanted to have a forum for broadcasters to express their viewpoint and provide that info to the IG or other WGs.
... That's a good separation of discussion and work place.
... If you feel we now have lots of overlap, then maybe the environment has changed and maybe we can review/restructure the relationship.

Mark_Vickers: My own opinion is that my focus has been the TV IG. Sheau has attended the Broadcasting BG meetings but not me.
... I believe there were also language issues initially, so the BG had mainly Asian members.
... It must be a challenge to listen to technical discussions in a foreign language.
... But we want to make the IG work for everyone in the TV industry.
... The difference between cable/IPTV/broadcaster/media companies are blurring and going away.
... A tablet is effectively a TV today.
... The data that we can get from a broadcaster could be coming over IP or over broadcast or other.
... I see the Web and TV IG as a great place for convergence from all backgrounds.
... I believe in the end we have functionality that is very similar and converges so I'd like to keep this open for the whole industry.

giuseppe: If there is a need for individual groups, then we could follow up in the IG.
... One issue we have is that it's difficult to find time slots for calls, etc.

Mark_Vickers: Also, in the first year, our meeting times were very inconvenient for Asia. We've re-aligned them to be better for Asia to make it open.
... I'd like to see us merge back together because of the overlaps. We could have separate sub-meetings for other languages.
... If can merge together, we can all work on one set of requirements.

nigel_: Regarding the tablet is a TV point, you mentioned that the target is browser - I don't think it's obvious. The target is a variety of devices.
... A browser on a TV is not similar to what people think of as a browser on e.g. their PC

Mark_Vickers: What we're trying to do is affect products in the field. In W3C, the end goal is sometimes just to complete a spec.
... I don't think PC browsers are not the end goal - sorry if I sent that message.
... Whether products are built-in browsers, embedded devices, whatever.

giuseppep: The browser is a broad thing, a user agent.

jcverdi__: I wanted to mitigate the idea of merging the IG and BG.
... There is a big overlap in the documents being worked on, but there are a lot of people who were not there yesterday.
... The BG is working in English, so if the goal is to address language issues, it's not working.
... I'm fine with redefining the goals of the group.
... The work that was done yesterday in the BG is really IG content.
... We're discussing the same use cases sometimes with the same people.

sheau: The group focusses heavily on broadcasters, so whether we end up taking the form of a BG or some other group, there needs to be a tight collaboration.
... Not simply merging it because that will extinguish the focus on broadcasters.
... Nevertheless that focus on broadcasters is very valuable to the IG and I would hate to see it disappear.

giuseppep: What about having that as a sub-group or task force within the IG?
... So many things are overlapping

sheau: The beginning concept - the language issue - seems to have gone.
... From yesterday's BG meeting, the group is trying to reach worldwide broadcasters now.
... NAB is member of the BG which is good.
... We should capitalise on that.

giuseppe: I have the same goal

yosuke: One of the reasons why I created the Broadcasting BG is the member fee .
... Public broadcasters and non-profit orgs have a relatively low fee.
... Commercial broadcasters have to pay full membership fee to join this IG.
... It's attractive for them but the other work in the W3C is not really.
... One of the reasons for creating the BG is a good step to join the W3C. If they do good work, they could move to full membership.
... It's an important gateway for commercial broadcasters - so not just a regional or language issue.

jcverdi__: To clarify - we cannot move the BG to IG simply because of the subscription problem and patent issues.

giuseppe: We could make the IG into a BG

<Mark_Vickers> +q

jcverdi__: I was told the broadcasting BG was the only BG that was working. I invite everyone to look at the BG's document produced yesterday.

olivier: One proposal - I want us to assert that W3C is here for us to work. If the organisation is not working then we have a way to suggest a fix.
... If payment is an issue and the reason for joining a BG, we can surely solve that by allowing non-members to join an IG for a small fee.

Mark_Vickers: The patent issue is not an issue - the IG does not have patent commitments.
... There is no patent commitment when you join W3C or when you join this IG.
... Any work that comes out of a BG or CG does have patent issues.
... Also, we do 95% of our work in public on the public mailing list. Anyone can join. Only members can join calls but we can invite people.
... Also, as you can see here, we're quite liberal about who can turn up to F2F meetings.
... If it's felt that broadcasters value meeting together that's good, but we do need to get something where there's a good forum and that avoids duplication of effort.
... Also if there are two groups, we need to get better at sharing information between the two groups.

<jcverdi__> +1 to offline handling of the discussion from there

kaz: As W3C staff contact, it would be better if all broadcasters join W3C

giuseppe: We should continue this discussion offline.

olivier: Later today, talking about future work, we could discuss rearranging future scope.

Mark_Vickers: Community Groups are open to non-members

ddavis: And CGs are very focussed which can help with the broad focus of the IG (which I think is not a big problem)

giuseppe: When shall we discuss gaps and potential new WGs, Task Forces?

olivier: We're not done with the gap analysis

giuseppe: Let's have a break and continue in 35 minutes at 11:00 local time.

<kaz> [ break ]

Note - the call will be restarted in 30 minutes

Media APIs TF

<olivier> For the next session - we will be looking at https://docs.google.com/spreadsheet/ccc?key=0AvACjV6qSvmxdEctdjYwa2JOalZLOG10elE1LVRZNlE#gid=1

<olivier> feel free to load it, please do not make any modification

+south_sea

<jcverdie> scribe: jcverdie

ChristianFuhrhop3: demo of advertisement with different bandwidth
... multiscreen with ad insertion using DASH

giuseppep: back to media api TF
... discuss some of the use cases the one mature enough
... until lunch

<ddavis> Media APIs TF page: http://www.w3.org/2011/webtv/wiki/Media_APIs

(olivier showing the GAP analysis spreadsheet)

<ddavis> Gap analysis spreadsheet: https://docs.google.com/spreadsheet/ccc?key=0AvACjV6qSvmxdEctdjYwa2JOalZLOG10elE1LVRZNlE#gid=1

olivier: our goal is to review the gap analysis table. crosses mean we want to validate there's a gap between what we want to achieve and existing technology.
... red means we have not identified technology allowing us to achieve our use case
... let's start with service expiry mechanism (line #5)
... we have not found specs fitting with the use case. we think it should fit in NSD or manifest for web apps (but this one is going to be deprecated)
... is there a spec that we are not aware of which would allow us to enable service expiry?
... do we need to talk to NSD?

giuseppep: nobody talks about discovery within W3C, if this is what we're talking about we're out of scope

<gmandyam> gmandyam = Giri Mandyam, Qualcomm Innovation Center

gmandyam: @@@ socket api, we could conceivably build on top of it

giuseppep: assuming the req is covered by underlying NSD protocol, we could handle (but not enforce it?)

gmandyam: from NSD should we be able to monitor that a service appears or disappear?

giuseppep: the req is too vague

olivier: the TF should refine the req

<gmandyam> To clarify my comment: SysApps WG is defining a Raw Sockets API w/IP Multicast capability. A developer could (in theory) build their own service expiry mechanisms on top of Raw Sockets.

<ddavis> Local Access Control: There SHALL be a mechanism to authorize a subscriber to access the local networked services including contents that are appropriate to the subscriber's profile, such as age, subscription status, etc.

olivier: local network service protection mechanism

daniel, what is the syntax for action command?

<scribe> ACTION: narrow Service Expiry use case description [recorded in http://www.w3.org/2013/11/12-webtv-minutes.html#action01]

<trackbot> Error finding 'narrow'. You can review and register nicknames at <http://www.w3.org/2011/webtv/track/users>.

<scribe> ACTION: olivier to narrow Service Expiry use case description [recorded in http://www.w3.org/2013/11/12-webtv-minutes.html#action02]

<trackbot> Created ACTION-168 - Narrow service expiry use case description [on Olivier Thereaux - due 2013-11-19].

sorry Mark_Vickers I missed it

olivier: the use case was parental control initially

Mark_Vickers: it's implemented above the browser quite effectively today

giuseppep: some devices have native support
... at the application level you would have to check it for each application while you can have accross the system control

Mark_Vickers: abstraction for that capability makes sense

<scribe> ACTION: olivier to clarify the requirement following Mark's comment [recorded in http://www.w3.org/2013/11/12-webtv-minutes.html#action03]

<trackbot> Created ACTION-169 - Clarify the requirement following mark's comment [on Olivier Thereaux - due 2013-11-19].

<scribe> scribe: ChristianFuhrhop3

Going to channel identification and tuner control.

Sung Hei Kim (ETRI) Requirements from two use cases

<ddavis> Tuner Control - There SHALL be a mechanism for the application on set-top box to control TV's tuner.

Need to be able to identify channels.

<ddavis> Channel Identification - There SHALL be a mechanism to support channel identification.

Two use cases proposed.

From these follow two requirements.

olivier: Gap analysis shows we don't have any apis that clearly fulfil requirments.
... None work for channel identification. Might have been NSD as a useful API for that,
... But answer from the group was no - probably not the right spec.
... Need seperate specification, most likely.
... Contribuiton from Guiseppe exists about requirements for tuner control.

<Mark_Vickers> http://tools.ietf.org/html/rfc2838

Guiseppe: Might work as URL to represent the tuner setting. (Or URI)

Mark: Such a solution was deployed in the UK on cable boxes. Has been sitting around since then, but would be a suitable approach.
... But has gone one out usage - requires domain name associated with each channel - needs registry.
... Channel name alon would not work, as there are, for example, multiple boradcasters named ABC.

<giuseppep> ack

Guiseppe: Would need liasion with other groups, finding out whether there are use cases or whether it is just an academic exercise.

jcverdie: There are tons of solution for this problem - do we want to specify something or rely on existing solution.

mark: One of the question - why wasn't it widely adopted back then? Possibly ahead of its time.

Guiseppe: It is probably not something we can re-use as is. The need is there, though. Might just require comman agreement.

giuseppe: Might be a good starting point for collaboration with external groups.

olivier: Two questions. One: Is this pushing another requirement, maybe on NSD, to other services?
... Given the discussion today - should we need to get back to the task force?

Giuseppe: On first question. We aready decided it's not really suitable for NSD, so probably not.

<ddavis> +1

<Zakim> jcverdie, you wanted to say CG _must_ be the option (not shall)

Mark: Starting a CG would only make sense when requirement analysis has finished.

jcverdie: Talking to external groups is a good situaton, as it would allow us to open up the discussion and avoid we come up (again) with different solutions.

Mark: Such discussion could of course also be handled in a CG.

Nigel: Channel tuner - in the real world channels are often quite related to each other.

<ddavis> nigel: Wondering if this group has a clear definiton of the meaning of channel.

Mark: As used in program guides (from use cases). And used in hybrid TV example, so broadcasters could align HTML code distributed with the broadcast and be able to refer to other channels (most likely the same broadcaster).

Like a BBC 1 hybrid app referencing 'now on BBC 2'.

<kaz> close q

Giuseppe: We can probably refine this more, but I don't want to spend years doing gap analysis.

<Zakim> jcverdie, you wanted to clarify if we're talking about 17 only or 17+18

Giuseppe: Maybe it's good to start to write it down as a spec and see how it is reacted to.

jcverdie: 17 and 18 (Tuner control and channel identification) are closely related and should be seen as one topic
... But is this group the best to do this?

Giuseppe: Technically not, since we, as an IG, can not do the spec.

jcverdie: Let us try to write a technical spec, but we can't do this within the IG, we need another placeholder.

olivier: Could we just start a CG now and get workig, taking this off the TF.

<kaz> close the queue

olivier: CG can then decide on whether to write a spec.
... Abut ten minutes left.

<kaz> open the queue

olivier: Going to Media Content Protection (offline) issue

<ddavis> Media Content Protection requirement - There SHALL be an ability to:

<ddavis> store video content in a protected format, as applicable.

<ddavis> store content licenses of protected video contents for offline playback.

<ddavis> view previously stored protected video content, e.g. via the HTML5 Encrypted Media Extensions.

<ddavis> transfer media in a single operation (not copy-then-delete).

<ddavis> account & verify the number of coexisting instances of the media.

olivier: Does media protection offline (recorded/downloaded) other requirements than online video.

oliver: Download-and-go scenarios.

<jcverdie> ChristianFuhrhop3, I can resume scribing if you want

Oliver: EME probably doesn't quite allow offline content protection. Need to ask Mark or ddorwin.

ddorwin I think it might work but hasn't really been discussed.

olivier: Reason why I am bringing this up is that part of the gap analysis is limited by our limited knowledge in EME.

Giuseppe: Isn't the EME based on talking to a license server, so it's not applicable offline.

ddorwin: Of course, you have to talk to the server at some point, but offline could be used following that initial exchange.

markw: But it is strongly aimed at streaming services, so it might not be readily adaptable to offline use.

Mark: Wasn't completely clear from the APIs by looking at them.
... Maybe record part is closer but needs some implementation experience.
... The download and go might not be able to be done on top of existing implementations.

gmandyam: There could be a gap when we ever doe recording of EME content - most recording discussion currently assume unprotected content.

olivier: We should wrap up due to time.
... Please join the TF if you are interested in this work.

<ddavis> Break now - come back in 90 minutes (13:30 local time)

<ddavis> -South_sea

Giuseppe: Back at 1:30.
... We will take group picture directly after lunch.

<kaz> [ lunch at the same restaurant ]

MORNING SESSION ENDS

<kaz> [ and will take a group photo after lunch ]

<kaz> rsagent, draft minutes

<kaz> scribenick: kaz

Testing TF

mark: next going to talk about the testing tf
... led by Clarke Stevens
... same kind of diagram as the Media APIs TF

(Testing TF (closed) )

mark: sent a survey from the IG to 10 related groups
... most important is the survey results
... as a table

(Testing TF slides)

(The Web&TV Testing TV Goals)

mark: use cases and gap analysis

(Results)

mark: gap analysis is not yet ready
... want to comment on a couple points
... active liaisons
... exercise the relationship more
... communication via the liaisonship
... towards "One Web"

(Google Doc table)

mark: programming requirements
... asked the groups
... and got scores
... combined the two surveys, IG result and external result
... there are different level of support
... corresponding to "Mandatory" or "Not"
... and got a priority list
... which should be tested first/mandatory
... considering which we should close or continue
... questions?
... log of participation

ddavis: how many "Mandatory" features?

mark: need to see
... this list is the one for the moment
... provide input for the testing effort

tobie: this list is similar to the one for the Mobile area
... and useful
... very close
... the other thing is
... how many tests are needed

<Mark_Vickers> I counted 35 Mandatory specs

tobie: I have a set of slides
... for AC on Thursday
... any questions so far?

<ddavis> https://www.w3.org/2013/Talks/1112-testtwf/

tobie: located under the member-only area

("Test the Web Forward" slides)

tobie: I'm a W3C fellow from Facebook
... Test the Web Forward is an initiative supported by Adobe
... now officially under the W3C Test effort

(Current State of browser testing)

tobie: grass roots efforts

(Grass roots efforts)

tobie: feature detection
... e.g., WebGL properties

(W3C WG tst suites)

tobie: not testing implementations

(Browser vendor test suites)

tobie: contributions from browser vendors
... end up on some repository
... until recently, no common framework
... organized by how vendors implemented
... not all of them are open-source

<scribe> (New W3 Testing Effort)

tobie: interoperability between browser implementations

(Scope)

tobie: performance
... out of scope now

(Plan)

tobie: infrastructure and common process
... test development

(Infrastructure)

tobie: 9 points
... a single repository on GitHub
... streamline test contribution
... gathering coverage
... building tools
... consolidating/expanding docs
... test framework for easy work

(Migrate to a Single GitHub Repository)

tobie: only missing is CSS test suites

(Stremline test contribution & review processes)

tobie: regardless of member or not

(Gather coverage data & measure progress)

tobie: how many tests with how much cost

(Build Review Tools)

tobie: cut down review time/cost

(Consolidate & expand documentation)

tobie: canonical doc center
... in late Q3

(Complete Overhaul of the Test Framework)

tobie: automated framework for reference test

(Collect and Share Test Results)

(Simplify test suite use for 3rd parties)

(Leverage & improve idlharness.js)

tobie: chunks of WebIDL
... massive time saver

(Test Development)

(Coverage)

(Coverage Analysis Methodology)

tobie: list items: RFC2119 keywords, algorithm, WebIDL, CSS

(Multi-Year Budget)

tobie: something like finishing all the CoreMob profile
... 5 million USD effort
... backward compatibility test as well
... maintainance 20% FTE
... this information is online
... test backlog
... (click "test backlog")
... (and skim the table)
... TV profile and mobile profile
... number of spec are missing
... (go back)
... questions?

dan_sun: not sure how it works

tobie: someone send their effort to the repository
... if the HTML is not written properly
... back to the reviewer
... check if the spec is implemented

mark: certification by multiple vendors is one of the issues
... consumer electronics and service model for certification
... TV world and mobile world are the examples
... aside those areas, cost for test is important for industries

(Test Development)

tobie: how to get there?
... vendor contribution
... crowd sourcing
... e.g., Test the Web Forward
... 600 more events like the Shanghai event would be needed
... W3C fellowship is another possibility
... cost-cutting measures

mark: something we're looking into approaching is external training
... companies using tests
... help for funding
... just starting
... about fundraising
... interested in how to get them involved
... questions?

nigel: looks very interesting
... from the TT perspective
... captions/subtitles are totally relevant
... having a common approach with that kind of features would make sense

tobie: 40 specs total
... not sure about the exact cost yet
... 40k-100k
... that's one thing
... another is
... precise content of the test
... so far succeeded to get fund
... learning more cost-cut
... much effort to build the center
... if you have questions, please reach out me
... if there is questions specific to your group, please discuss them within the group

mark: another thought
... let's say 70k for ttml

<nigel> c/700k/75k

tobie: Google is now publishing tests

<scribe> ... new specs

UNKNOWN_SPEAKER: overall budget for long term would meet

yosuke: could you please give us any sight on performance?
... recommendations/strong points, etc.
... where we can help you or where you need help

tobie: testing activity hasn't been active
... using ML
... think the best way is
... as an industry, submit tests and certify them for HTML5
... provide resources
... fund or engineers
... 2 key ways
... create test suites under the common license

yosuke: you're the contact. right?

tobie: yes. at the moment

mark: very helpful talk
... now we need fund program

(tobie leaves)

Timed Text TF

ddavis: brief announcement
... EME on Thursday in HTML WG
... Web Criptography on Thu/Fri

<ddavis> s/Web Cryptography on Thu\/Fri/Web Cryptography on Friday/

pierre: timed text tf created during the Lyon meeting
... scope was creating input for TTWG
... from the web&tv perspective
... consensus input for the TTWG charter

<ddavis> http://www.w3.org/2011/webtv/wiki/Tt

(TT TF wiki)

pierre: charter went to the AC immediately before this TPAC
... no additional agenda for the TF
... thanks to all the TF participants' contribution
... questions?

mark: quick review on the two results?

(TT TF wiki again)

pierre: WebVTT and TTML efforts

<ddavis> http://www.w3.org/2011/webtv/wiki/Tt/TTWG_Consensus_Input

<ddavis> http://www.w3.org/2011/webtv/wiki/Tt/Timed_Text_Efforts

pierre: single focus within the new TTWG

nigel: good work
... very helpful
... presented three points

(revisit the wiki)

http://www.w3.org/2011/webtv/wiki/Tt/TTWG_Consensus_Input

mark: we faced the issue of having two formats
... hoped semantic mapping
... appreciate your work
... favor in having a unique format

pierre: tx

<ddavis> Stereoscopic Web 3D TF: http://www.w3.org/2011/webtv/wiki/3dweb

<ddavis> Dong-Young: We have proposed our spec but have not have much feedback.

<ddavis> ... so our work has sort-of stopped. However, there has been some academic interest about continuing this in a Community Group.

<ddavis> open the q

giri: did you look into media apis?

dy: could include 3d contents

mark: application would read the tags?

dy: we don't expect ua automatically handles that

mark: e.g., messages of "now you should take the 3d glasses"
... 3D mimetype might be available

dy: dap part

mark: isn't it essential to have a mime type?

dy: theoretically yes

mark: how devices could describe what is needed when

ddavis: controlling the need for 3D-ness

mark: e.g., the second feature "stereo-order-type", lr or rl
... read only property for ua

dy: right
... in relative, sometimes we need those features
... picture module within the ua needs them

mark: the system knows about the mime type
... isn't there a need for controlling the depth of the image?

dy: using 3d transforms

Payments

manu: quick talk
... chair of RDF WG, Web Payments CG
... transforming the CG to WG
... we're looking at use cases
... broadcasting and tv
... online stores which may be used on TVs
... (explains a possible use case)
... don't need any credit card info
... ideally the browser could handle all the info
... large/small banks, PayPal, etc.
... some ideas
... if anybody is interested, please join the breakout session tomorrow
... any questions?

mark: what do you think about user experience requirements?

manu: talking with stakeholders
... need simple procedure and would like your comments
... security is important
... accessing a certain TV
... from a certain area

mark: what would be the way to learn a bit more about the work done so far?

manu: put a URI on the IRC
... workshop planned in March next year
... participate in the workshop and provide your ideas
... tx

<m4nu> Links for Web Payments

<m4nu> How to join/lurk on the Web Payments work: https://payswarm.com/intro

<m4nu> woops, that was the intro

<m4nu> Intro on Web Payments work: https://payswarm.com/intro

<m4nu> How to join Web Payments work (keep up with what's going on): https://payswarm.com/join

<ddavis> Stopping for break - back in 45 minutes - 16:00 local time

<m4nu> W3C TPAC Web Payments breakout session: http://www.w3.org/wiki/TPAC2013/session-web-payments

<ddavis> Topics for final session are what to focus on next year and workshop discussoin.

[ group picture / afternoon break ]

<ddavis> scribe: Daniel

<ddavis> scribenick: ddavis

Mark_Vickers: We've looked at the past, looked at our present work.

<jcverdie> WAKE UP FOLKS

Mark_Vickers: Let's look at the future - the 2014 plan. It's time for the audience to help.
... Is the Media APIs task force continuing its work?

olivier: I believe so

Mark_Vickers: As we talked about it for 2014, I think we're interested in increasing our liaison effort.
... We'd like to continue the communication we started in the Testing TF.
... Let's think about what we can do with liaison surveys. Is there anything more active we can do?
... Are there external groups where it would be worthwhile having meetings?
... Does anybody have any ideas? Suggestions please.

kaz: We had a discussion before and some people were interested in MMI - Multi-modal interactions.
... If some participants are interested, please join our WG meeting this week.
... Also, we use Adobe Connect so I'd like to remind the group about that technology.

Sheau: I deal with ATSC and they are currently working on their plan. It would be useful to communicate more pro-actively.
... Last time we just said to them "Here's what we're working on"

Mark_Vickers: Is there are opportunity there?

Sheau: My suggestion would be to reach out to them but to a sub-committee. It would be more effective at not too high a level.
... I can give an introduction

Mark_Vickers: Please do.

Giri: ATSC is developing ATSC 3.0 and they responded to the Testing Liaison in terms of their 2.0 spec.

gmandyam: I'm partly involved and am involved in the liaison effort. What's going on in HTML5 is fast-moving so it would be difficult for a liaison to educate ATSC to current developments. A meeting is better.

giuseppe: A workshop, which we have planned, is good for this. If we reach out before a workshop we'll be prepared in advance to have a productive discussion, not starting from scratch.

Mark_Vickers: Having the workshop on a specific date is motivating and pushes work forward.
... Maybe we should assign somebody to have a goal to set up a call to answer questions leading up to the workshop.
... I can volunteer to take on the DLNA group.

gmandyam: I can do that for ATSC.

yosuke: I can do IPTV Forum Japan

giuseppe: I can do HbbTV

fan: I come from a cable TV company in Shanghai. I see several discussions here that overlapping.
... One is FOBTV - this is used in China.
... We discuss with them ultra-high definition. We should add them.
... Also we should add ITU which has a focus group on Smart TV
... three months ago we gave suggestion to ITU describing use case for multi-room and home networking.
... We have similar use cases to what we saw this morning.
... They are use cases which don't specify how to fulfil the requirements.

Mark_Vickers: Would you be able to do that liaison?

fan: We can work together with ITU, FOBTV and W3C

jcverdie: Maybe we should include STVA (global version)
... I agree with giuseppe that it would be useful to reach out before the workshop. We could gather all the use cases, put them in a nice form, to avoid re-inventing the wheel.

<kaz> fyi. W3C Liaison list: http://www.w3.org/2001/11/StdLiaison

<fan> not me

jcverdie: We can send it out to the groups, asking if we've missed anything.

Mark_Vickers: Yes, the use case documents are just a step along the way, but should be maintained for liaison communication.

jcverdie: We need to maintain them for ourselves anyway.

kaz: We recently got an updated statement about DASH by MPEG

Mark_Vickers: One was an update (FYI) on DASH standards.
... The other was that DASH would start testing and they were asking for input from our group.
... Is anyone interested in this?

<Zakim> kaz, you wanted to remind of the liaison statement from MPEG on DASH experiment

giuseppe: MPEG seems to be at a different level so I'm not sure if it's worth including them.

Mark_Vickers: I think most of the companies here have an interest in video, codecs, formats, etc.

<jcverdie> +1

Mark_Vickers: I misunderstood - yes, maybe MPEG should not be included in our shortlist for liaisons.

jcverdie: I could contact SBTVD but HTML5 is very marginal for them (at the moment)

Mark_Vickers: Another action item I've thought of (for Clarke?) is that we did a testing activity, sent out liaisons, got feedback so we should send them our results.
... Clarke led that activity so maybe he could do that.

giuseppe: Can I assume that the chairs and moderators are going to follow this up? Bin and I will do this.

jcverdie: By the way, we should come up with a long-term maintainable solution - not just a Word document.

giuseppe: The wiki is a good place for that.

+1

Mark_Vickers: Moving on to task forces, do people have other ideas of tasks forces or areas we should work on.

<jcverdie> problem with the wiki is doing a quick and clean export to send it to external people, but it's definitely a good place to maintain it

<jcverdie> ddavis: what about performance? a Chinese guest asked about this.

Mark_Vickers: There is a Web Performance Working Group.
... Is it APIs they're working on?

giuseppe: Their scope was broad but they've been focussing on measuring performance including network performance.

<jcverdie> ddavis: some of the issues was about CSS rendering for instance

<jcverdie> ... how to reach good performance on low level hardware

giuseppe: Actually this was brought up by me in the past.

<jcverdie> giuseppe: is the question is how do I measure performance or how do I achieve good performance. the latter is irrelevant

giuseppe: You need some measurement you can trust, and this is something that is being discussed in other areas, not just the Web Performance WG

<Zakim> jcverdie, you wanted to talk about Media API - Performance liaison :)

Mark_Vickers: I don't really see what a task force could do on this.

jcverdie: We all know there are some issues with performance for broadcast, e.g. the number of seconds to switch from channel to channel.
... We need to think how to let people control and measure this.

giuseppe: I assume this kind of measurement is what's being done by the Web Performance WG.

<jcverdie> ACTION: jcverdie to look at the testing spec to check if it's fit to measure things like channel switching timing [recorded in http://www.w3.org/2013/11/12-webtv-minutes.html#action04]

<trackbot> Created ACTION-170 - Look at the testing spec to check if it's fit to measure things like channel switching timing [on Jean-Charles Verdie - due 2013-11-19].

Mark_Vickers: I think it's a good thing to look into.

<jcverdie> ACTION: mark, giuseppe, yosuke and jcverdie to agree on a stable and sustainable way to present and maintain use cases [recorded in http://www.w3.org/2013/11/12-webtv-minutes.html#action05]

<trackbot> Error finding 'mark,'. You can review and register nicknames at <http://www.w3.org/2011/webtv/track/users>.

Sheau: Maybe it's too early before tomorrow's second screen CG meeting, I'm wondering whether there is any need for a very focussed multiscreen task force.

giuseppe: That CG is not looking at multiscreen - it's a very precise use case.

<jcverdie> ACTION: jcverdie to cowork w/ mark, giuseppe, yosuke and agree on a stable and sustainable way to present and maintain use cases [recorded in http://www.w3.org/2013/11/12-webtv-minutes.html#action06]

<trackbot> Created ACTION-171 - Cowork w/ mark, giuseppe, yosuke and agree on a stable and sustainable way to present and maintain use cases [on Jean-Charles Verdie - due 2013-11-19].

giuseppe: It's one user agent showing some content on a separate screen.

Sheau: We've done quite a lot of work in the Media APIs TF - is there something we haven't covered?
... How do you author a piece of content that is mean to be delivered in different pieces, for example?
... Is there something to be discussed further?
... The CG is about things like Miracast - very specific. Do we see any gaps and should analyse them?

Mark_Vickers: They probably haven't looked at every possible issue, but maybe we can look at other use cases and see if there are gaps.
... If Hybridcast has some use cases that are not being covered, the first thing to do is to compare them - not necessarily the Media APIs TF.
... Are you volunteering, Sheau?

Sheau: I'd prefer to have somebody familiar with Hybridcast.

jcverdie: Yosuke is better to answer this.

<Zakim> jcverdie, you wanted to suggest to add NHK to the reachout list

yosuke: Hybridcast uses IPTV Forum Japan spec so I can take on looking at the gaps.

<jcverdie> ACTION: yosuke to check the Hybridcast use cases compared to Media API TF [recorded in http://www.w3.org/2013/11/12-webtv-minutes.html#action07]

<trackbot> Created ACTION-172 - Check the hybridcast use cases compared to media api tf [on Yosuke Funahashi - due 2013-11-19].

kaz: JC's point earlier implies not just performance but also channel synchronisation/channel switching.
... So do we want to consider time synchronisation as well?

Mark_Vickers: I think it's already one of the use cases for the TF.
... Are there other areas we think need working on?

Sheau: In response to kaz, when we talk about synchronisation we just say there should be a means.
... Some other groups are looking at a number of use cases, such as frame accuracy.
... That's a very different issue that we're not addressing.

giuseppe: For me, that's another use case that can be added to the next iteration.

yosuke: This is not a TF idea, but I'd like to suggest that we monitor the testing activity as a continuation of the Testing TF.

<olivier> ACTION: olivier to bring back f2f feedback to Media APIs TF,delegate ACTION-168 and ACTION-169 [recorded in http://www.w3.org/2013/11/12-webtv-minutes.html#action08]

<trackbot> Created ACTION-173 - Bring back f2f feedback to media apis tf,delegate action-168 and action-169 [on Olivier Thereaux - due 2013-11-19].

yosuke: NHK created their Hybridcast service in September and interoperability is a big issue for them.
... So I'd like to suggest we monitor testing activity and see where we can contribute.
... It's a continuous effort that is important.

Mark_Vickers: That's important. The main issue is the need for funding.

giuseppe: Or the need for test cases.

Mark_Vickers: If there's a deadline for e.g. a Japanese company, perhaps they can contribute test cases or funding.
... I encourage you to follow up with Tobie and suggest NHK, etc. help.

jcverdie: What Yosuke said about Hybridcast is a worldwide problem.
... Putting a good test suite together is tricky. We try to avoid divergence in HTML5.
... Instead of writing individual test suites for different standards, having a single one would be better.

Mark_Vickers: Yes, in DLNA we agreed we wouldn't create competing tests - it's the same as having competing specs.
... We can talk about further task force work on the mailing list.

TV Workshop

<jcverdie> Please every body check https://www.w3.org/2011/webtv/track/ issues have been added all day long and it's a good way to track activity

<jcverdie> scribe: jcverdie

giuseppe: let me summarize the idea of the workshop. it would be a 2 days workshop around 3 areas
... #1 how W3C, Web & TV IG works, relevance wrt industry (EME, MSE, ...), testing
... #2 coordination, standard alignment
... not what they're doing (we know), but which one are the issues
... #3 forward looking session, what's the long term vision
... location and time: TBD. Tentative late March or April / Geneva

<ddavis> or elsewhere in Europe

or another date, daniel ;)

Mark: we had 3 workshop in the past: Tokyo, Berlin, Hollywood
... it's been good for content presentation, driving the IG

igarashi (sony): how do you plan to coordinate the standard bodies in the workshop

giuseppe: goal is to reach out ahead of time and buy their interest. Something like "are you trying to use HTML5? What issues do you face? Do you plan extending the specs? Please don't, it can be done in one place".
... Highly likely all these groups are planning similar type of extensions

thanks shoko

igarashi: another suggestion is education, good to explain what we do in the IG and how W3C is doing

giuseppe: agreed, the questions sometimes comes up

<ddavis> jcverdie: This is part of topic 1 - education.

giuseppe: we can use real world samples, e.g. css navigation

<ddavis> giuseppe: Another example is CSS navigation properties (nav-left, etc.) They were marked at risk by the CSS WG so we had to let them know that there are real implementations.

<ddavis> giuseppe: This is an example of the process we follow in W3C.

Mark: another example is remote keycodes (color keys, ....)
... in may be 2010 it's been included in DOM3 Event but as of 2013 it's still not really implemented

igarashi: is coordination with vendor specific services also in scope?

giuseppe: it's easier to talk to standard bodies but of course it's open to individual companies who are willing to talk

AOB

Mark: anything else people want to bring

<ddavis> jcverdie: I'd like to talk about the Web and Broadcasting BG.

Mark: we're meeting with the staff tomorrow

<ddavis> jcverdie: We should make sure we resolve it so we don't have the same issue - 2 similar day meetings - next time we meet.

Mark: so hopefully we come to a resolution on this pretty quickly

silence, some distant snoring

(Mark thanks people for joining and oversells how great other sessions are)

(while we all know this is the only interesting group)

[ MEETING ADJOURNED ]