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

On 24/5/11 10:45 , Giuseppe Pascale wrote:
> 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
> follows:
>
> 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?
JCD: I agree.


>
> ** 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 think?
JCD: I agree we have been lazy on the motivations, and we need to make 
more effort.


>
>
> ** Service User Interface (ISSUE-4) **
> Comments:
> - 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.
JCD: Fine with me.


>
>
> ** Document Responding to Requests (ISSUE-13)**
> Should we rephrase this as in "applications in the HN being able to 
> exchange messages"?
JCD: Fine with me.


>
>
>
> ** 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.
JCD: I understand some people are saying: I am OK with being generic 
about supported technologies, but I want to make sure this set of 
features of my choice technology is supported.
So Russel's use case with a list of supported cases sounds closer to a 
list of support requirements.
How about treating them as such ?
Best regards
JC

>
> Another possible approach would be to just list as a plain list both 
> high level and low level usecases.
>
> What do people think?
>
> /g
>
> [1] 
> http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Requirements#Use_cases
>


-- 
JC Dufourd
Directeur d'Etudes/Professor
Groupe Multimedia/Multimedia Group
Traitement du Signal et Images/Signal and Image Processing
Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France
Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144

Received on Wednesday, 25 May 2011 09:45:06 UTC