RE: [apis] Cross-review of HNReq document and current list of use cases

Thank you Olivier for reading the use cases, and comparing them with HNReq. Please see more specifics responses inline starting with [BH].

In general, I would suggest that it may not make sense to compare the use cases with HNReq, because it is just like comparing mandarin oranges with tangerines. Sure, some use cases may look "very similar", and some may look "very different". But the similarity or difference of the use cases doesn't necessarily mean the requirements are the same or different. So the comparison of use cases won't lead us to any further progress in terms of gap analysis.

Speaking of "gap", in my view, the gaps are the "requirements" that haven't been addressed by any technical specification yet. HNReq is not a technical specification, but more like a set or collection of proposed solutions. Let alone it is also not clear whether those solution-looking use cases in HNReq are "gaps" or not. I personally don't think so. That's why comparing our use cases with HNReq won't help us at all. It will just end up with "my solution can solve your use case".

I suggest that the more effective approach is to focus on "requirement" and related gaps.
- As the first step, it is more important to summarize the concrete requirement from those use cases. I mean the real "what to do", but not "how to do" as described in HNReq.
- Once we have requirement, at the second step, we should analyze which requirement have been addressed by which technical specification.
- After this analysis, at the third step, we will have a clearer picture of the "gaps", i.e. the requirements that have not been addressed by any specification yet.

i.e.: "abstract requirement from use cases (what) -> compare with technical specs (how) -> conclude gaps" is the right approach and work flow.

Hope it helps
Thanks
Bin

-----Original Message-----
From: Olivier Thereaux [mailto:Olivier.Thereaux@bbc.co.uk] 
Sent: Thursday, July 04, 2013 9:23 AM
To: public-web-and-tv@w3.org IG
Subject: [apis] Cross-review of HNReq document and current list of use cases

Hello,

At the most recent teleconference of the Media APIs task force, we agreed to review our proposed use cases in light of the existing work of the (now closed) Home Network Task Force. In particular, we all committed to review the list of use cases and requirements published at http://www.w3.org/TR/hnreq/ (abbreviated in this message as HNReq).

I would like to start this discussion with the following review.

Let me stress that it is a *strawman* review, meant to elicit a conversation. My interpretation of the matches between the various documents and their coverage is very much open to disagreement. My goal is for us to determine remaining gaps we may want to focus on.



** From Media APIs/Use Cases
   ( http://www.w3.org/2011/webtv/wiki/Media_APIs/Use_Cases )


1. "Use Case One - Tablet Joins Home Network"

This use cases seems to be fully covered by the HNReq use cases:
 - U2. Discovered Content Host
 - U6. Application Exposing a Service
 - U7. Application Discovering a Service

I can see no obvious gap between the use case and what is already documented in HNReq.

[BH] "U2. Discovered Content Host" looks more like a solution. But Use Case One doesn't have to rely on the "document" solution. And also Use Case One is not content discovery, but service discovery.
[BH] "U6 and U7" look similar to service discovery, but Use Case One has broader requirements to synchronize the service offering on different devices, meaning they may offer the same content, or related but different content on different device at different timing.

2. "Use Case Two - TV Triggers 2nd Screen"

This use case appears to be covert partially by the HNReq use cases:
  - U10. Media Identification

However, I could not find a clear mention of timed metadata in the programme stream, nor any mention of events triggered by metadata in a programme. These may be additional requirements.

[BH] U10 is also a solution, i.e. using media identifier. Why should we require a "Media Identifier" instead of a functional requirement such as "context-based service synchronization and content synchronization" in Use Case Two?

3. "Use Case Three - Tablet EPG"

This use case appears to mirror the HNReq Use case:
  - U15. Home Network Enabled User-Agent - Network Media Player

I can see no obvious gap between the use case and what is already documented in HNReq.

[BH] Sorry that I am afraid that U15 also looks like a solution, while Use Case Three requires not only to control the play in local device but also be able to control the play to transfer to another device.

4. "Use Case Four - Content Sharing"

This use case appears to be original. My interpretation of it, however, is that its specific requirements are all covered by the following HNReq use case:
  - U10. Media Identification

I can see no obvious gap between the use case and what is already documented in HNReq.

[BH] See my response above of Use Case Two.

5. "Use Case Five - Content Search"

My understanding is that this use case is covered almost entirely by a combination of the following HNReq use cases:
  - U4. Service Distribution
  - U8. Application Push-Migration
  - U10. Media Identification

I can see no obvious gap between the use case and what is already documented in HNReq.

[BH] All look like solutions. For example, Use Case Five doesn't require "application transfer" solution as described in U8 as long as another solution can support "content aggregation" and "service aggregation" functional requirement.

6. "Use Case Six - Tuner Control thru EPG Application"

This looks very similar to "Use Case Three - Tablet EPG". I would encourage the Use Case authors to detail how the use cases differ.


7. "Use Case Seven - Channel Bounded Applications"

This use case shares some similarities with the following HNReq use case:
  - U12. Time Synchronization

However, there seem to be some unique characteristics to this use case which I do not find in HNReq, such as the switching of applications on the "slave" device based on channel change in the "master" device. This could be an additional requirement worth exploring.



** From Media APIs/Terminal Use Cases
   ( http://www.w3.org/2011/webtv/wiki/Media_APIs/Terminal_Use_Cases )


1. "Channel"

This use case seems to be partially covered by the following HNReq use cases:
  - U10. Media Identification
  - U11. TV Control
  - U12. Time Synchronization

I believe, however, that there are some details in the use case not fully covered by e.g. the "U11. TV Control" HNReq use case. Expanding the TV Control use case may be an interesting next step.


2. recording

This use case is still WIP, but currently is covered by the following HNReq use case:
  - U18. Home Network Enabled User-Agent - Network Record Controller



3. Device capability information / conflict detection
4. Channel List
5. CA and CI
6. Video output control

These are WIP and it is hard to determine if their full scope would be covered by HNReq.


7. TV Applications

This use case looks like a collection of use cases. I would encourage its authors to split it into more atomic use cases which we could then analyse for gaps.


** From http://www.w3.org/2011/webtv/wiki/Media_APIs/Record_and_Download_Use_Cases

1. Download and Go

I could be wrong but this use case looks genuinely new to me, and not covered in any depth by HNReq.


2. Watch and Record

This use case looks in some aspects like a subset of the following HNReq use case:
  - U18. Home Network Enabled User-Agent - Network Record Controller

However, the Use Case also appears to be fundamentally different from anything in HNReq, largely because it is not situated in a multi-device home network but rather in a web/mobile context which could be in any kind of network. I suggest the group should look at the gaps this use case identifies as a prime candidate for our attention in the near future.



Any thought? Agreement, disagreement, different perspective? I would very much welcome others' take on a review, to see if we independently reach similar conclusions.

Thanks,
--
Olivier





-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

Received on Wednesday, 10 July 2013 05:34:10 UTC