- From: Giuseppe Pascale <giuseppep@opera.com>
- Date: Wed, 25 May 2011 13:18:10 +0200
- To: "Glenn Adams" <glenn@skynav.com>, "Jean-Claude Dufourd" <jean-claude.dufourd@telecom-paristech.fr>
- Cc: "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
On Wed, 25 May 2011 11:38:18 +0200, Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr> wrote: > Thank you, Glenn, for this very clear formulation. > I fully agree now with Giuseppe that we need to use the term > "application" rather than "document" in our use cases. > Giuseppe, please include some of Glenn's text in your application > definition. > Thanks both, I'll do an attempt and ask the list for review (I'll probably write it down directly into the requirement document) > I believe we also need to make clear what is part of the > "client-application-state": > > - if the application is implemented as a set of documents, which > document is currently active is part of the state; for example, if > "tabs" are implemented as separate documents, which tab is visible is > part of the state. > > - if any user interaction has brought a non-transient transformation of > the DOM, that is part of the state; for example, a text highlight > appearing because the mouse hovers above the text is transient and not > part of the state, but a checkbox which has been checked may be part of > the state. > > - in a similar fashion, if a communication link is established with > another application through HNTF discovery, then that communication link > may be part of the state; for example, the TV set running a voting > application has established connections with two smartphones; if for any > reason, the TV set was restarted, the voting application needs to > reestablish connections with the same two smartphones if they are still > available, but not with other phones. > While for a technical specification this is surely needed, do we need to go into this level of details for a "usecases and requirements" document? What about describing some examples of modification in the use case itself? Of course this will not capture all the possible "states" but I don't think is relevant at this stage to make a precise definition of this but rather describe what are the most common scenarios we expect to be covered. /g > Best regards > JC > > On 24/5/11 18:42 , Glenn Adams wrote: >> Please do not equate 'application' and 'document'. They are not the >> same. From the client perspective, and application may be defined as: >> >> application : metadata resource* client-application-state >> >> In contrast a document (as in XHTML document, HTML document, SGML >> document, XML document etc.) is generally understood as an individual >> resource that adheres to a certain content type; however, even here, >> one must distinguish between the 'interchange document' and the >> 'instantiated (dynamic) document', where: >> >> interchange-document : resource of a specific type (e.g., text/html, >> application/xhtml+xml) >> instantiated-document : parsed-interchange-document >> client-document-state >> >> While an 'application' may consist of a single resource representing >> a specific document, it will more often consist of multiple resources >> representing one or more documents and their related resources. >> >> The HTML5 application-cache employs a model similar to the above (at >> least for caching an application's resources). >> >> Regards, >> Glenn >> >> On Tue, May 24, 2011 at 9:57 AM, Giuseppe Pascale <giuseppep@opera.com >> <mailto:giuseppep@opera.com>> wrote: >> >> Hi JC, >> during last call we touched on two of your usecases Service >> Migration (ISSUE-7) and Document Migration (ISSUE-15). >> There were some comments from several participants that would >> require some actions from you. >> I'll try to summarize the main issues here so you can act on them. >> >> (I would like to ask everybody to point out in case I fail to list >> all the pointed out issues) >> >> - for both usecases (and actually for all of them) would be better >> to use the word "application" rather then document (see also >> related discussion on the list) >> Since I'm going to add a definition of application, basically >> similar to the html5 definition of document, you don't need to >> clarify in your usecase the term. >> >> - for ISSUE-7 (and in general for any usecase you or anyone else >> will provide) would be better to provide a more detailed >> description of one particular scenario you have in mind with the >> steps that the user would have to do to cover that particular use >> case. So would be good if you could do for ISSUE-7 what you have >> done for ISSUE-15 (i.e. step by step description). You have >> actually called it "implementation" but I think that as far as you >> don't mention any specific technology (if not part of the use case >> of course) that can be safely part of the description itself. >> >> Furthermore someone was concerned about the particular example you >> make since it was not clear how a moving service could still work >> when it is highly dependent from a platform capability. So if you >> could provide a more detailed, step by step, usecase that would be >> great. >> >> - as also captured in the notes for ISSUE-15, the are 2 possible >> sub usecases that can be considered here, one that involve a web >> server and one that it does not (widget). Since it seems that what >> you are looking at is the second one (widget) is probably better >> to make this explicit. >> >> >> Generic comment: we decided to split the requirement document into >> high level usecases and low level usecases. I think I have a >> pretty good understanding of the high level usecases (based on the >> discussion so far) so I will try to list them into the requirement >> document myself (then people can review it). Would be better then >> from now on if we focus on more specific and user centric usecase, >> like it could be your "voting" example since different services >> may imply very different requirements for a specification to cover. >> >> /g >> >> >> >> >> -- >> Giuseppe Pascale >> TV & Connected Devices >> Opera Software - Sweden >> >> > > -- Giuseppe Pascale TV & Connected Devices Opera Software - Sweden
Received on Wednesday, 25 May 2011 11:21:15 UTC