Packaged and hosted E0

Kjartan Müller

unread,

Oct 22, 2013, 7:33:44 AM10/22/13

to epu...@googlegroups.com

Hi all!

As Book in Browser is about to start (unfortunately I can't be there), there is one thing bothering me about the current strawman proposal. It still presupposes that ebooks mainly should be packaged as single files to pass around. I would suggest that we, analogues to the web app world, may distinguish between something like 'hosted ebooks' and 'packaged ebooks'.

Packaged e0-books would be zipped files as the straw man proposal outlines, while hosted e0-books would be ebooks living on the web and addressable by url's. I think hosted ebooks would support subscription scenarios and some educational scenarios better than the packaged model. Hosted ebooks could still be accessed by dedicated reading systems -- in addition to simpler book-in-browser-applications, and could also support offline reading by using standard cache mechanisms in html5 or by using link-rel=alternate to a packaged version.

A hosted e0 could be identified by using <link rel="profile" href="http://somethingsomething-e0"> (http://tools.ietf.org/html/rfc6906). Using 'profile' to identify e0 would also signal a commitment to html, and that future ebooks should not be a format by itself, or a media type, but rather a special case of using open web standards.

It could also be a way to support modularity:

would signal that the ebook could be presented by a basic e0-system, but a system supporting additional overlay-metadata would add functionality like synchronized audio or something.

Best

Kjartan

Bill McCoy

unread,

Oct 22, 2013, 1:18:10 PM10/22/13

to Kjartan Müller, epub-ng

Kjartan,

You make very good points and I personally see the "networked publications" use case as being most critical to address, since today's EPUB doesn't clearly specify it.

However I see it as even stronger than just being an analogy to the web apps world, as apps based on the Open Web Platform, that are presently rather proprietary or at least browser-dependent (Chrome Apps, Mozilla FirefoxOS apps, even Amazon Web Apps) also want to become standardized. I.e. I would generalize one of your statements to: "future ebooks and apps built with Web technologies should not be formats by themsleves, or media types, but rather special cases of using open web standards"

And so shouldn't it be considered how the Web community is going about identfying hosted Web apps, so we can maximize converagence rather than doing something special for ebooks (/ publications / hosted, rather than packaged, portable documents)? The W3C Systems Applications WG ( http://www.w3.org/2012/sysapps/ ) and the recently transferred app manifest seem relevant ( http://www.w3.org/2012/sysapps/manifest/ ) albeit it's a bit too soon to say what will become standardized (and meanwhile web apps is still experiencing some adventures in proprietary-ness, such as the new Safari & OS/X web app notifications).

Anyway I know you e0 guys tend to like "tag soup" HTML and hate XML... ;-) but if JSON is what's going to be used to identify and scope unpackaged apps I see no reason that it shouldn't be adopted for unpackaged publications as well.

--Bill

Kjartan Müller

unread,

Oct 23, 2013, 5:03:35 AM10/23/13

to epu...@googlegroups.com, Kjartan Müller

Hi, Bill, thanks for your answer!

6 months ago, I probably would have agreed with you totally, but I'm no longer so sure. The question here is what the main endpoint of a hostable, networked ebook should look like: An indirectly install file with metadata in a json-manifest, or a combination of toc/spine and metadata in html. Tagsoup aside :-) I now prefer the last one:

1 There is a 80-20 situation here, I think. For 80% of the ebooks, having an indirectly install file will just add complexity without any real benefits for author, developer, publisher or reader. We should optimize the core spec for those 80, and add complexity/functionality in a layered/modularized fashion based on industry experimentation.

2 There is a real beauty in having an endpoint for an ebook that is both machine readable and instantly human readable in any browser -- without any clue of or functionality for manifests or E0-profiles.

3 I'm kind of inspired for the moment by the idea of 'Book as API' and by reading RESTful WebAPIs, so of course I would argue that the endpoint should be proper hypermedia :-) At one point an ebook could be defined in something like HAL JSON (http://tools.ietf.org/html/draft-kelly-json-hal-06) + E0-profile + SYSAPPS-profile, linking to chapters in markdown. But for now, see 2.

4 Even if there is a huge overlap between ebooks and apps, I still think we need to separate the concepts of 'launch files' and 'ebook toc/spine'. But those could be explicitly combined. There is an interesting use case where the index containing the spine/toc also could link to a lightweight embeddable js-E0-player (hosted by readium?), turning the index.html to a self-contained reader system. In a browser with js turned off, you could still read the ebook in a plain fashion. With js you get all the whistles and bells. So instead of adding ebooks to a reader system, you could add a basic reader system directly to the ebooks. Why not? In this case a manifest would make sense.

5 For the 20% scenario where we would need to add semantics from SYSAPPS directly to an ebook with some interactivity of some sort, I think that can be solved in different ways by profiling, metadata and/or linking:

or maybe:

Both variations have been part of the web app discussions, I think. Using rel="manifest" makes sense for web apps as well, since it promotes discoverability of hostable web apps.

6 What about OPDS? Do we not already have a distributable install-mechanism for ebooks? Could we not use a JSON version of OPDS (or even XML:-) with semantics from SYSAPPS mixed in?