W3C home > Mailing lists > Public > public-digipub-ig@w3.org > February 2015

Re: Packaging Review

From: Matt Garrish <matt.garrish@bell.net>
Date: Wed, 11 Feb 2015 11:56:24 -0500
Message-ID: <BLU437-SMTP826A008AF6F6EC6003F0B3FA250@phx.gbl>
To: "Siegman, Tzviya - Hoboken" <tsiegman@wiley.com>, "Liam R E Quin" <liam@w3.org>
CC: <public-digipub-ig@w3.org>
I think it's a general question of efficiency without a listing of resources 
and byte offsets to the boundary locations, not that the resources couldn't 
be requested/pulled in parallel.

But if I read Ivan's comments right, at least for epub-web we could/would 
require that the package document be the first part, and be referenced in 
the "Link" header as the config file for the package. And we could make 
rules for packaging that prioritize the order of resources. So, while you 
could download all in one go and wait, I assume that the package document 
would be requested first and then requests for the subsequent resources 
prioritized based on the progression of the reader into the content while 
it's downloading.

Doesn't answer the byte efficiency question, but maybe adding byte locations 
to the manifest would be a good thing, even if not standardized in the 
packaging spec?

Matt

-----Original Message----- 
From: Siegman, Tzviya - Hoboken
Sent: Wednesday, February 11, 2015 9:24 AM
To: Liam R E Quin
Cc: DPUB mailing list (public-digipub-ig@w3.org)
Subject: RE: Packaging Review

Thanks, Liam

Perhaps I'm misunderstanding something, but I think it is possible to fetch 
individual items using the type parameter in the URL?

http://example.org/downloads/spending.pack#rel=describedby;type=application/ld+json
is the example 15 the section on Fragment IDs [1]. This is a URL pointing 
the metadata in JSON-LD (as opposed the metadata in Turtle.

In our publications world, might we see something like this to access the 
video element:
http://example.org/downloads/bookTitle.pack#rel=describedby;type= video/mp4

I believe if we want to fetch multiple parts in parallel, we use a less 
specific URL.

[1] http://w3ctag.github.io/packaging-on-the-web/#fragment-identifiers


Tzviya Siegman
Digital Book Standards & Capabilities Lead
Wiley
201-748-6884
tsiegman@wiley.com

-----Original Message-----
From: Liam R E Quin [mailto:liam@w3.org]
Sent: Tuesday, February 10, 2015 11:32 PM
To: Siegman, Tzviya - Hoboken
Cc: DPUB mailing list (public-digipub-ig@w3.org)
Subject: Re: Packaging Review

On Tue, 10 Feb 2015 17:11:49 -0500
"Siegman, Tzviya - Hoboken" <tsiegman@wiley.com> wrote:

> Note that the document itself includes some issues as open questions. We 
> might wish to offer our thoughts on those issues.

I think that would be a good idea.

Some thoughts I had when looking at the TAG document included...

* The lack of a byte-oriented table of contents means no ability to use HTTP 
Range to fetch an individual item, or to fetch multiple parts in parallel 
(consider a 3-hour long video with text captions in a following part)

* Similarly you can't easily extract individual items, hence might not be 
suitable for storing an ebook on disk (you _can_ do that with zip)


Liam



--
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures 
from old books: http://fromoldbooks.org/
Received on Wednesday, 11 February 2015 16:56:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:35:55 UTC