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

On Tue, 24 May 2011 12:38:07 +0200, Jan Lindquist  
<jan.lindquist@ericsson.com> wrote:

> Hi,
>
> Creating a definition for application and service will be beneficial. It  
> will help clarify terms used across the the use cases.
>
> When it comes to splitting the use cases into two areas I would suggest  
> splitting into:
>
> 1. General framework, discovery and generic control type use cases
>
> 2. Specific services/features type use cases
>
> As we go along we can attempt to combined use cases and identify if they  
> are unique. My suggestion is not to make the use cases too broad since  
> it will be harder to identify individual services.
>
I'm fine with this. We can discuss this during the call, and I can apply  
the agreed changes after that.

We should try to spot overlaps when they are pretty clear, anyway as you  
say, I wouldn't worry too much.
Once we have included all the contributions in the requirement document  
will be easier for people to go through the all document and suggest  
improvement as needed.

/g
> Regards,
> JanL
>
>
> -----Original Message-----
> From: public-web-and-tv-request@w3.org  
> [mailto:public-web-and-tv-request@w3.org] On Behalf Of Giuseppe Pascale
> Sent: den 24 maj 2011 11:44
> To: public-web-and-tv@w3.org; Matt Hammond
> Subject: Re: [HOME_NETWORK_TF] Comment on the usecases (open and closed)  
> and on the requirement document
>
> Matt, all,
>
> On Tue, 24 May 2011 11:18:28 +0200, Matt Hammond  
> <matt.hammond@rd.bbc.co.uk> wrote:
>>
>> Substituting 'application' for 'document' seems sensible. Will this
>> need additional clarification with respect to whether the application
>> is web based, or whether we also include other forms of application in  
>> scope?
>> Or would the ambiguity be desirable?
>>
>
> First of all I would like to bring back the (old) discussion about  
> terminology, since when going into more detailed usecases we will for  
> sure need to make use of terms like "website", "tv" and so on.
> So we will benefit from adding a "Definitions" section. I propose to  
> start  from the one proposed by mat a while ago [1] if people are fine  
> with it, and add other terms like "service" "application" etc.
>
>
> When it comes to the term application, what I meant is "applications  
> based on web technologies", that mostly mean web apps served by a web  
> server on internet, but is not limited to that.
> Another example of application I think are in scope are W3C Widgets [1]
> that are defined as "interactive single purpose application [...]
> packaged in a way to allow a single download and installation on a  
> user's machine or mobile device". Since calling a Widget "web  
> application" may be confusing, I would prefer to use the word  
> application and define the terms in the "Definitions" section.
>
>
> [1]
> http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/UseCasesDualScreen
> [2] http://www.w3.org/TR/widgets/
>
>
>
>>
>> regards
>>
>>
>> Matt
>>
>> On Tue, 24 May 2011 09:45:24 +0100, Giuseppe Pascale
>> <giuseppep@opera.com> 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?
>>>
>>> ** 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?
>>>
>>>
>>> ** 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.
>>>
>>>
>>> ** 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?
>>>
>>> /g
>>>
>>> [1]
>>> http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Requirements#U
>>> se_cases
>>>
>>
>>
>
>
> --
> Giuseppe Pascale
> TV & Connected Devices
> Opera Software - Sweden


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

Received on Tuesday, 24 May 2011 13:43:49 UTC