Re: packaging use cases

Hi Tzviya,

I was wondering how we should use/handle the use cases. What I did, as a first run, is to see how these use cases compare to what the Web Packaging spec provides, and whether there are major incompatibilities. I believe it would also be interesting to do the same with the current EPUB packaging (ie, OCF) to see whether there is a major pro or con.

In my mental model, there is of course a need to have an EPUB-WEB package format, that would relate to the Web Packaging like EPUB3 relates to OCF, ie, some additional structure should be given to the package content (in fact, I believe, most of what is in EPUB3 can be transferred to EPUB-WEB with very little change).

So here is my first run at things. I collected the explicit requirements when they are available, and added my own comment as some sort of a gut feeling


Publication with Data[1]
------------------------
* Package may contain/point to textual/graphical/media as well as data (CSV, code repository)
 - No problem for the package format (anything can be stored in a package)

* Package includes queryable manifest
 - Not a problem if the package is local, but I do not think that is possible out of the box in general. Actually, is this a package issue or some sort of an API/User Interface issue?

Publication plus Annotations[2]
-------------------------------
* Content in package is fully annotatable
 - No problem for the package format, modulo a clear fragment identifier spec for all the EPUB-WEB content (to have an anchor for a the annotations)

* Annotations are considered part of the package
 - No problem for the package format (modulo write permissions); anything can be stored in the package.

Streamlined Access to Disjoint Package Components[3]
----------------------------------------------------
* Metadata on package components
 - Apart from the HTTP Header metadata, all other forms of metadata must be defined by the EPUB-WEB package. Note that the package spec, by default, does not have some sort of a table of content. B.t.w., a package may include other packages, which may come handy.

* Manifest with metadata and semantic information
 - This is something an EPUB-WEB package definition should define

* Customizable manifest functionality
 - This is something an EPUB-WEB package definition should define

Manifest Includes Information about New Content [4]
---------------------------------------------------
* Manifest indicates whether content is new (relative to last download) and triggers download only when content is new/updated.
 - Works in the package spec out of the box by virtue of reusing the corresponding HTTP headers on expiration time

Access Control and selective encryption [5]
-------------------------------------------
* Ability to have certain content within the container encrypted, while others public
 - No problem for the package format insofar as the different parts can be encrypted (or not) independently of one another.

* Clearly defined sample that is publicly viewable. A sample may include different files than a full version (for example, a page on how to buy the book or other products that is displayed only in the sample. Or, if it's a web-app, and you are showing only a sample, you may want to only expose a portion of your controller source code)
 - No problem for the package format, but the details must be defined in the EPUB-WEB package.

* Unlock information: The ability to define a website where the full content can be purchased. Ideally, once a new license is purchased, the encrypted content would be replaced with the newly encrypted content for that specific user (assuming that encryption was necessary), but creating a new container with the encrypted content is also possible. Key management and decryption will be up to the authority services.
 - No problem for the package format, but the details must be defined in the EPUB-WEB package.


Note that many of those requirements rely on the manipulation of the package as a whole. Virtually speaking, this means unpacking (into a director structure), doing whatever is to be done, and packing again. Zip has, I believe, some tools to do that (at least from within other programs, ie, there is an API), the situation becomes very different for Web packaging where an expected model is that a package is downloaded and unpacked into, say, a browser local database or cache or something similar.

Am I on a wrong track here?

Ivan


[1] https://www.w3.org/dpub/IG/wiki/Publication_with_Date
[2] https://www.w3.org/dpub/IG/wiki/Publication_plus_Annotations
[3] https://www.w3.org/dpub/IG/wiki/Streamlined_Access_to_Disjoint_Package_Components
[4] https://www.w3.org/dpub/IG/wiki/Manifest_Includes_Information_about_New_Content
[5] https://www.w3.org/dpub/IG/wiki/Access_Control_and_selective_encryption








> On 30 Mar 2015, at 22:05 , Siegman, Tzviya - Hoboken <tsiegman@wiley.com> wrote:
> 
> Hi All,
> 
> I’ve put together some use cases about packaging [1]. Please comment and add your own use cases.  In a few weeks, we will send these use cases to Yves Lafon as he works on Packaging on the Web [2].
> 
> [1] https://www.w3.org/dpub/IG/wiki/UseCase_Directory#Packaging_and_Distribution
> [2] http://w3ctag.github.io/packaging-on-the-web/
> 
> 
> 
> Tzviya Siegman
> Digital Book Standards & Capabilities Lead
> Wiley
> 201-748-6884
> tsiegman@wiley.com


----
Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704