[HOME_NETWORK_TF] Comment on the usecases (open and closed) and on the requirement document

Hi all,
this mail list several comments on all the open/closed discussions so far.
Please take a look, I'll try to touch on this during tomorrow call as well
but if you have any comment before that, feel free to reply.

** generic, use of word document **
First of all a generic comment about the use of the word "document".

All usecases are currently defined as "A document" doing something.
This seems to create some confusion for some usecases where is not clear
which resources are associated with the document and what is the state of
the document.
I was wondering then if we should generalize and talk about "an
application" doing something. In this way we are more generic and leave to
later specifications to define if the usecase can be implemented just
extending the document or if additional mechanisms are needed (e.g. a
concept of state)

So the Usecases U1 and U2 [1] (already approved) would be rephrased as

U1. Discovery Content Host
An __application__ as host for discovered content: e.g. an __application__
displays content provided by a local, discovered device or service.

U2. 3-Box model
An __application__ can coordinate action between other services. In the
most obvious example, an __application__ discovers media content sources
and media players. The __application__ allows the user to select a source
and a player, then control playback (Play, pause, rewind, etc.) of the
content to the player.

Same applies to all open usecases.

@JC, Clarke,
what do you this of this rephrasing?

** generic, motivation section **
At the moment, each use case is supposed to contain a Motivation: section
that should describe (among the other things) "Why were you not able to
use only existing standards to accomplish this?";
I think nobody is really addressing this point. So either we add this to
open and closed usecases or we drop the motivation section and we include
any benefit to the ecosystem in the description (if needed)

I think that for some usecases could make sense to underline why you
cannot achieve that already with existing web standards. What do people  

** Service User Interface (ISSUE-4) **
- change document into application
- do we need to distinguish between devices and services? Isn't this too
UPnP specific? Is probably more generic to talk about "services"

A possible rephrasing:

An application interacting with a service; in this use case the
application provides a remote user interface for a service available on
the network; some example are: light switch, hifi volume control, radio
station chooser,remote control of a media player, etc.

** Document Responding to Requests (ISSUE-13)**
Should we rephrase this as in "applications in the HN being able to  
exchange messages"?

** High level use cases VS specific use cases **
At the moment we have some high level usecases that seems to cover  
basically all possible scenarios (expose a service, interact with a  
service, discover a service).
On the other end these seems to be a bit too high level and someone infact  
proposed some more specific ones (see Jan and Russell proposals).

So I'm wondering what is the best approach to cover both needs, i.e. both  
describe some generic usecases and point to some more specific  
services/usecases we want to be able to cover.

My proposal would be the following: we split the usecases section in two:  
first we list some high level usecases (i.e. the ones from Jean Claude)  
and then we go into some "sub use cases" were we list some more specific  
usecases we want to cover.

Another possible approach would be to just list as a plain list both high  
level and low level usecases.

What do people think?



Giuseppe Pascale
TV & Connected Devices
Opera Software - Sweden

Received on Tuesday, 24 May 2011 08:48:12 UTC