- From: Giuseppe Pascale <giuseppep@opera.com>
- Date: Tue, 24 May 2011 17:33:46 +0200
- To: "Francois Daoust" <fd@w3.org>, "Scott Wilson" <scott.bradley.wilson@gmail.com>
- Cc: public-web-and-tv@w3.org, "Matt Hammond" <matt.hammond@rd.bbc.co.uk>
On Tue, 24 May 2011 16:20:06 +0200, Scott Wilson <scott.bradley.wilson@gmail.com> wrote: > > A W3C Widget may contain multiple assets (including alternate > localizations) however It isn't executed as a collection of documents, > but as one application in one browsing context. So technically, in the > HTML5 sense, a Widget may be a Document. However, in the colloquial > sense, its an application. > As discussed today I think that if we use the term application and reuse the definition for document given by html5 we should probably able to achieve both goals, that it be coherent with html5 and make the usecases a but more readable. I'll add a definition section in the requirement document (and define application) and rephrase the existing usecases to use application instead of document if people can leave with it. >> Provided we define terms, it does not really matter what term we use. >> My point is that it could be easier and faster to re-use an existing >> definition than to come up with our own vocabulary. > > It depends on the audience, but if a use case can involve Widgets, it > may be better to say so explicitly rather than to rely on readers > referring to a broad definition of Document that includes everything > from word documents to Angry Birds and filling in the gaps themselves. > > Many of UCs that Matt has submitted may involve Widgets - whether > installed on the TV, a STB or on the second-screen device, or deployed > as needed. I think thats a characteristic of the UC worth calling > attention to rather than hiding. > Agree; actually using a widget-like approach could also solve some of the security concerns, since a widget could be prevented to communicate with the public network and be confined to the private network, avoiding information leakage. /g > S > >> >> Francois. >> >> >> >>> >>> /g >>> >>>> 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] >>>>> 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#Use_cases >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>> >>> >> > -- Giuseppe Pascale TV & Connected Devices Opera Software - Sweden
Received on Tuesday, 24 May 2011 15:36:40 UTC