Re: [HOME_NETWORK_TF] Some comments on the open issues

Hi Matt, comments inline

On Fri, 03 Jun 2011 18:00:52 +0200, Matt Hammond  
<matt.hammond@rd.bbc.co.uk> wrote:
>
>> ** Media identification (ISSUE-19)
>> I agree that the use cases is a valid one but I have few question:
>> - isn't this already implicitly included in the use cases listed above?
>> - is the use cases only about being able to query a unique identifier  
>> for content/programs or also about standardize this identifier?
>
> It is not clear to me which other use case you feel already addresses  
> this - perhaps you refer to the Service User Interface use case?
>
giving it a second thought, I withdraw this comment.


> Yes, this use case aims to demonstrate a need for an identifier to be  
> standardised to some degree. It is necessary for the scenario described  
> that such an idenifier for a programme has meaning outside of the scope  
> of the device serving or presenting that programme. For example, a home  
> media storage device could allocate its own self-generated identifiers  
> to distinguish one item of content from another; but such identifiers do  
> not allow association with any other content outside of the domain of  
> that device.
>
> For a simple remote control application, it is sufficient to be able to  
> use identifiers to only distinguish one programme from another; and to  
> associate them with metadata such as programme title, scheduled  
> broadcast time, file size and format, etc. But if that application  
> wishes to relate a programme to content available from an external  
> source (such as a web service on the internet) then if the only  
> identifier available is locally assigned as just described, it would not  
> be possible to do this. The scenario described in the use case needs to  
> be able to do this.
>
> That standardisation could be quite lightweight - as described in the  
> implementation notes of the use case - using URI style schemes to allow  
> different parties to still use their own schemes of identifiers, but  
> subsumed within a namespace, so that they can be distinguished from the  
> scheme being used by another party.
>
I'm fine with the use case.

/g

>> ** TV Querying and Control (ISSUE-20)
>> This seems to be the same as Issue-4, even though issue-4 is probably  
>> too generic while this give one particular example of control. I'm not  
>> sure how we should handle these usecases, if we should keep both, only  
>> the generic one or only the specific ones. IMO we should keep both
>
> ...
>
>> ** Time Synchronisation (ISSUE-21)
>> Looks fine to me. Same comment as above apply (generic vs specific)
>>
>> ** Lip-Sync accuracy Time Synchronisation (ISSUE-22)
>> Looks fine to me. Same comment as above apply (generic vs specific)
>
> I would be happy to merge the use cases if there is agreement that this  
> is appropriate. What is important for me is that the scenario that  
> exemplifies the use case is still supported.
>
> I believe it is important to capture these scenarios since it has been  
> established in previous discussions that simply enabling access to UPnP  
> services that exist and are documented at this moment in time, does not  
> support this. I believe the TF's aim is to identify where work needs to  
> be done (either in the W3C or elsewhere) to enable services combining  
> Web and TV - and so this has to be informed by scenarios for actual  
> usage.
>
My comment was more a generic one for the group.
Personally I'm fine to keep them as separate use cases.

Thanks,
/g


-- 
Giuseppe Pascale
TV & Connected Devices
Opera Software - Sweden

Received on Tuesday, 7 June 2011 13:31:47 UTC