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

Re: [dpub-loc] Draft update

From: Ivan Herman <ivan@w3.org>
Date: Fri, 12 Feb 2016 15:54:52 +0100
Cc: Daniel Weck <daniel.weck@gmail.com>, Ben De Meester <ben.demeester@ugent.be>, W3C Digital Publishing IG <public-digipub-ig@w3.org>
Message-Id: <58EB4391-BB1C-4FBF-9C4B-49992A36AECF@w3.org>
To: Leonard Rosenthol <lrosenth@adobe.com>

> On 12 Feb 2016, at 13:27, Leonard Rosenthol <lrosenth@adobe.com> wrote:
> 
> On 2/12/16, 5:47 AM, "Daniel Weck" <daniel.weck@gmail.com> wrote:
> 
> 
> 
>> Note that it is possible to download only fragments of a packed
>> publication, without any server-side code ; just by emitting HTTP
>> partial byte-range requests from the client-side. It is therefore
>> possible to acquire individual files from the archive directory of a
>> publication hosted remotely, by inflating / unzipping streams of
>> binary data into Blob-URIs,
> 
> That is quite true.
> 
> HOWEVER, it requires the client to have intimate knowledge of the packed format of the PWP (eg. ZIP) to be able to request the “catalog” of the format to find out all the bits and what their byte ranges are.
> 
> And if a given PWP or RS wishes to do that - that’s certainly fine, no one will stop them. However, I don’t believe that is the direction we want to take as the standard or even recommended implementation.
> 
> 
>> The trick
>> used is a URL syntactical convention based on the ! exclamation mark
>> (as per the JAR standard), denoting a level of indirection into the
>> EPUB archive (e.g. https://domain.com/ebook.epub!/path/to/image.png).
> 
> Right.  However, right now, our goal (or at least mine) is to see if we can avoid that approach…
> 

I agree.

Ivan

> 
> Leonard
> 


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





Received on Friday, 12 February 2016 14:55:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 25 April 2017 10:44:40 UTC