- From: Matt Garrish <matt.garrish@bell.net>
- Date: Wed, 11 Feb 2015 11:56:24 -0500
- 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