Re: Use Case for State Changing Document

And that’s generally the position we’ve taken, Mike.  That the use of or lack of use of a cache is entirely up to the “PWP Processor”.

But Nick’s idea that an author could provide hints for a system that might want them, seems reasonable (and happily ignorable).

Leonard

From: Mike Perlman <perlmanm@me.com<mailto:perlmanm@me.com>>
Date: Monday, March 14, 2016 at 4:06 PM
To: Nick Ruffilo <nickruffilo@gmail.com<mailto:nickruffilo@gmail.com>>
Cc: Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>, W3C Digital Publishing Discussion list <public-digipub@w3.org<mailto:public-digipub@w3.org>>
Subject: Re: Use Case for State Changing Document

Hi

I don’t think a cache should be involved with PWP. n the case of media, there can be a low res offline and high res online, but no one knows what could or couldn’t happen to a cache in the future or guarantee the cache will travel with the document. We probably need a new paradigm to address this area.

Cheers
Mike

On 14 Mar 2016, at 08:51, Nick Ruffilo <nickruffilo@gmail.com<mailto:nickruffilo@gmail.com>> wrote:

Leonard,

Great comments - and let me hopefully clarify.  See below for comments.

On Mon, Mar 14, 2016 at 3:31 PM, Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>> wrote:
A few comments, Nick.   These are my opinions and I am sure that others will disagree :).

> the user needs to ensure they have access to critical pieces of data while secondary assets have a pre-defined fallback
>
That’s actually an author decision, not a user one.  If the author doesn’t provide for a disconnected/offline version, then one doesn’t exist.  The PWP processor would not be expected to provide one.


Yes.  it is an author decision - but my use-case was to outline that the author needs a way to specify what and how an offline package looks like.  The PWP processor should do no guessing.


>The publication also needs some concept of location so that the reading experience can be resumed from device to device.
>
This is a feature of a “reading system” and not a publication.


Agreed - what I want to make sure is that the PWP has a way that can allow such functionality to be universal - basically being able to provide a locator to "active text."



>As changes in state - mainly from online to offline - may not be predictable to the user or the device, all offline-fallback resources should be >determined and loaded when the resource is initially loaded.
>
That’s an implementation decision of the “reading system” and not anything controlled by the publication.  It’s similar to caching, which we have already agreed is out of scope.


Here I think we disagree.  While it is up to the reading system how much to cache - what I'd like is to see that a well defined manifest that outlines critical-for-offline and offline-fallback resources could cache them creating a high-quality reading experience for the user.  The reading system could choose to do what it wants, but I want to ensure that the PWP itself provides the reading system all the information it needs to create a great experience.


>Additionally - there are situations - such as with large video files - where a package may want to label these assets as "non critical but able to be
>taken offline" which could prompt a user to be asked if they wish to cache certain large resources for offline consumption.
>
The idea that a PWP can contain information to guide (influence?) the caching behavior of a “reading system” is interesting and not one that we’ve spent much time on.  I think it could be something to consider…


Thanks!  Me to.  Especially as I've noted above.  This was one of the promising things of the now-defunct HTML5 appcache or whatever it was called - being able to really define a fallback for unintentional offline mode - and then possibly provide a "full offline mode" and being sensitive to legal issues - certain resources may NOT be allowed to be made offline and therefore a fallback would be needed.


>It may also be necessary to define different script outcomes based on status.
>
Is that really something that needs to be defined or just something that a scriptor would need to be prepared to handle?



I'm not sure - and not sure if Javascript already provides that level of information.  Additionally - will the states of PWP be any different or unique from the states of a web-page?  Would those states be useful to define and surface in a scripting environment so that the script COULD do something?  Even if the solution isn't something handled by spec, it's useful to say: "if you want to do X, here's how to do it" to implementers.  And for offline-specific scripting, if it's up to the coders, thats a reasonable solution.


Leonard

Thanks for the feedback!


From: Nick Ruffilo <nickruffilo@gmail.com<mailto:nickruffilo@gmail.com>>
Date: Monday, March 14, 2016 at 3:19 PM
To: W3C Digital Publishing Discussion list <public-digipub@w3.org<mailto:public-digipub@w3.org>>
Subject: Use Case for State Changing Document
Resent-From: <public-digipub@w3.org<mailto:public-digipub@w3.org>>
Resent-Date: Monday, March 14, 2016 at 3:20 PM

Here is - hopefully - a good starting point for a use-case on having mechanisms to handle a state-changing document.


----------- BEGIN USE CASE ---------------------

Many publications - especially long form fiction & non-fiction - that users engage with for many hours.  During this time, the user may shift states in many ways - starting consumption on an internet enabled PC, moving to an internet enabled portable device, going into offline-mode on that device, and then back to the PC.

During all of these experiences, the user needs to ensure they have access to critical pieces of data while secondary assets have a pre-defined fallback that will allow the user to continue (for example, a poster image of a video that serves as a placeholder for an externally streamed video when internet is available).

The publication also needs some concept of location so that the reading experience can be resumed from device to device.

As changes in state - mainly from online to offline - may not be predictable to the user or the device, all offline-fallback resources should be determined and loaded when the resource is initially loaded.  This means that certain items in the package need to be classified as critical for offline reading, and others as non-critical.

Additionally - there are situations - such as with large video files - where a package may want to label these assets as "non critical but able to be taken offline" which could prompt a user to be asked if they wish to cache certain large resources for offline consumption.

It may also be necessary to define different script outcomes based on status.  For example if a large data set were to be requested in real-time, while in offline mode, a static version that was pre-generated could be provided as a fallback.



----------- END USE CASE -----------------------

What am I missing?  Any notes for doing things different/better in the future?

--
- Nick Ruffilo
@NickRuffilo
Aer.io<http://aer.io/> an INGRAM company




--
- Nick Ruffilo
@NickRuffilo
Aer.io<http://aer.io/> an INGRAM company