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

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