Re: [HOME_NETWORK_TF] Priorities for requirements

In general, I think the criterion for feature priority should be the degree to which it enables applications, rather than a value judgment on one application vs another (which differs by individual). In other words, I'm less concerned over whether application A is more "important" than application B. I'm more concerned whether application A is possible (via HTML, JS app or JS library) while application B is impossible. By the enablement criterion above, a feature that enabled blocked application B is higher priority than a feature that provides an application-specific API for an already-enabled application A. A dependency chart could be made of how many blocked apps are enabled by each feature.

By this criterion, the service discovery feature is likely to enable more blocked HN apps than any other and may therefore be the highest priority.

Thanks,
mav

On Aug 22, 2011, at 11:46 AM, Bob Lund wrote:

> I agree with Matt's relative priorities with exceptions noted inline below.
> 
> Bob Lund
> 
>> -----Original Message-----
>> From: public-web-and-tv-request@w3.org [mailto:public-web-and-tv-
>> request@w3.org] On Behalf Of Matt Hammond
>> Sent: Monday, August 22, 2011 2:06 AM
>> To: Giuseppe Pascale
>> Cc: public-web-and-tv@w3.org
>> Subject: [HOME_NETWORK_TF] Priorities for requirements
>> 
>> 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
> I see this as secondary priority. If a low-level API is provided by the UA then this will have to be solved at JS which is an issue beyond the scope of the HNTF.
> 
>>     1.7.5.2 Access to home network services
>>     1.7.5.3 Prevent leaking of information
> I see this as secondary priority. If a low-level API is provided by the UA then this will have to be solved at JS which is an issue beyond the scope of the HNTF.
> 
>>     1.7.3.8 Content Protection
> I see this as a DRM issue, not HNTF.
>> 
>> ... 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
> This may be out of scope if a low-level API is provided by the UA.
>> 
>> 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
> While I understand this is viewed as a very important feature, I think the control protocol to exchange time synchronization information and the application logic to make use of this information are both outside the scope of HNTF.
>> 
>> 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
> I see this as high priority. If you don't have service advertisement I don't see how one does service discovery.
> 
>>     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 17:20:54 UTC