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

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.

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.

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


-- 
JC Dufourd
Directeur d'Etudes/Professor
Groupe Multimedia/Multimedia Group
Traitement du Signal et Images/Signal and Image Processing
Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France
Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144