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

On Tue, 24 May 2011 13:20:15 +0200, Francois Daoust <> wrote:

> On 05/24/2011 11:44 AM, Giuseppe Pascale wrote:
>> Matt, all,
>> On Tue, 24 May 2011 11:18:28 +0200, Matt Hammond  
>> <> 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.
> +1 to a "Definitions" section.
> Not that I like "document" so much, but I note that the HTML5  
> specification "uses the term document to refer to any use of HTML,  
> ranging from short static documents to long essays or reports with rich  
> multimedia, as well as to fully-fledged interactive applications":

That probably still do not include Widgets, i.e. a package of documents.
I don't have a strong opinion anyway.
I can come up with a straw man proposal (for this and other terms) and  
people can comment on it.


> Francois.
>> 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]  
>> [2]
>>> regards
>>> Matt
>>> On Tue, 24 May 2011 09:45:24 +0100, 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?
>>>> ** 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]  

Giuseppe Pascale
TV & Connected Devices
Opera Software - Sweden

Received on Tuesday, 24 May 2011 13:48:15 UTC