W3C home > Mailing lists > Public > public-digipub-ig@w3.org > September 2013

Re: May be a relevant discussion for eBooks: 'zip archives as first class citizens'

From: Robert Sanderson <azaroth42@gmail.com>
Date: Tue, 17 Sep 2013 09:00:55 -0600
Message-ID: <CABevsUF3nHYvvZjsW9SS3PBYGtKbALZ3x1gYUtEYBbOHZ5oM5A@mail.gmail.com>
To: Ivan Herman <ivan@w3.org>
Cc: Robin Berjon <robin@w3.org>, W3C Digital Publishing IG <public-digipub-ig@w3.org>, Brady Duga <duga@google.com>
Hi Ivan,

Yes, agreed. And my concern is that there will be two fragment
specifications for EPUB -- CFI and whatever the WHATWG come up with (if
anything) -- potentially neither of which have the full picture and
therefore don't cover all of the requirements from both communities.

Rob




On Mon, Sep 16, 2013 at 11:03 PM, Ivan Herman <ivan@w3.org> wrote:

> Robert,
>
> I guess, as far as this IG is concerned, we can/should restrict ourselves
> to eBooks, more precisely ePub. In the case of an ePub, the EPUB CFI
> specification:
>
> http://www.idpf.org/epub/linking/cfi/epub-cfi.html
>
> becomes part of the picture... I am not sure it answers to your
> requirements, though, because I am not sure whether the existing fragment
> id-s (in HTML or in SVG) can be combined easily...
>
> I guess Brady can help us out for this.
>
> Ivan
>
> On Sep 16, 2013, at 18:34 , Robert Sanderson <azaroth42@gmail.com> wrote:
>
> >
> > Thanks Ivan, Robin!
> >
> > Some ideas towards requirements from the annotation perspective:
> >
> > * Resource-in-Zip (RiZ) should be able to be annotated given the RiZ URL.
> >  -- anno hasTarget foo.epub%!/foo.jpg
> >
> > * A fragment of the RiZ should be able to be annotated, using existing
> fragment specs for interoperability
> >   -- anno hasTarget foo.epub%!/foo.jpg#xywh=100,100,20,20
> >
> > * ... without using the media fragment "extension" mechanism so that
> HTML fragments can be used
> >  -- anno hasTarget foo.epub%!/foo.html#para1
> >
> > * Extension ".zip" cannot be required for the encapsulating zip file
> >   -- anno hasTarget foo.__epub__%!/foo.jpg
> >
> > * ... or nested zips as RiZ, if that is supported:
> >  -- anno hasTarget foo.epub%!/chapters/chap1.epub%!/foo.jpg
> >
> > * Relative URLs should work to allow embedding annotations within the
> zip file and have them move around correctly without always referring back
> to the original copy of the epub, which might change or no longer exist.
> >   -- eg:
> >
> > <%!/annotations/anno1.ttl> a oa:Annotation ;
> >   oa:hasBody <%!/annotations/bodies/comment1.txt> ;
> >   oa:hasTarget <%!/foo.jpg#xywh=100,100,20,20> ;
> >   oa:hasMotivation oa:commenting .
> >
> > * Clearly we need to make RDF assertions about resources inside zips for
> any of these to work correctly.
> >
> > Is it worth adding as a discussion item for tomorrow's call?
> >
> > Thanks!
> >
> > Rob
> >
> >
> >
> > On Wed, Sep 11, 2013 at 8:13 AM, Robin Berjon <robin@w3.org> wrote:
> > On 11/09/2013 10:41 , Ivan Herman wrote:
> > There is a discussion going on the whatwg mailing list:
> >
> >
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-August/040599.html
> >
> >  on whether URI-s should be defined to address zip archives on the
> > Web. There has been some remarks about why this would be interesting
> > and the arguments seem to forget that, in fact, ePub files are also
> > zip archives.
> >
> > Yes, I'm still mulling over that thread and might jump in at some point.
> >
> >
> > I am not sure this is relevant for this IG, and those of you who may
> > be closer to the issues might want to have a look. It may be relevant
> > for epub-reader-in-a-browser type implementations...
> >
> > I think that this is a key component in bringing browsers and epub
> closer to forming one web, a goal that I think it pretty relevant :)
> >
> > --
> > Robin Berjon - http://berjon.com/ - @robinberjon
> >
> >
>
>
> ----
> Ivan Herman, W3C
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> FOAF: http://www.ivan-herman.net/foaf.rdf
>
>
>
>
>
>
Received on Tuesday, 17 September 2013 15:01:27 UTC

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