Re: [HOME_NETWORK_TF] About Service Migration (ISSUE-7) and Document Migration (ISSUE-15)

On Wed, 25 May 2011 11:38:18 +0200, Jean-Claude Dufourd  
<> 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.


> 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 <
>> <>> 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