- From: Matt Hammond <matt.hammond@rd.bbc.co.uk>
- Date: Mon, 22 Aug 2011 09:06:02 +0100
- To: "Giuseppe Pascale" <giuseppep@opera.com>
- Cc: "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
Hi Giuseppe, here is my perspective on the relative priorities of requirements. Some stand out as a common requirement that underpin everything else. These would seem obvious candidates to be high priority. Specifically: ... Security considerations (for applications, users and content): 1.7.5.1 Application trust level 1.7.5.2 Access to home network services 1.7.5.3 Prevent leaking of information 1.7.3.8 Content Protection ... And the basics of discovery of services and content: 1.7.2.1 Service Discovery 1.7.2.2 Content Discovery 1.7.2.3 Content Players Discovery 1.7.2.6 Media Identification I believe Media Identification should be considered a higher priority. It is a prerequisite for applications to be able to properly relate items of media content to a wider web of data/content. This was at the core of most of the BBC's second screen scenarios and demos described in Berlin. These alone are insufficient to fulfill most of the use cases and user scenarios identified. The use cases that seem most straightforward to address next and which also show the most immediate utility are those that support the ability to control and query media playback: 1.7.1.1 Compatibility with widely deployed standards 1.7.3.1 Control of content players 1.7.3.2 Playback of content 1.7.3.3 Playback of live content 1.7.3.4 3 Box model 1.7.3.5 Time-synchronization The requirements listed above focus on enabling applications to utilise existing home network services. The remaining requirements all enable use cases and scenarios that are of great interest, but could be considered a "next step" of making it possible for applications to advertise and/or offer services. I therefore would consider these to be of lower priority. 1.7.2.5 Services Advertisement 1.7.2.4 Content Advertisement 1.7.3.7 Application communication 1.7.4.1 Push migration 1.7.4.2 Pull migration Going for high accuracy time synchronisation enables a smaller set of scenarios than achieving some less precise degree of time synchronisation. It is also probably harder to do well. I'd also class this as lower priority. 1.7.3.6 Accurate time-synchronization regards Matt -- | Matt Hammond | Research Engineer, BBC R&D, Centre House, London | http://www.bbc.co.uk/rd/
Received on Monday, 22 August 2011 08:07:00 UTC