These ideas were expressed most forcefully by Daniel Glazman (slides available here as PDF). I'd been familiar with some of his thoughts, as he'd posted extensively about his experience with EPUB3 as he implemented an EPUB3 editor. His rant about the absurd number of navigation files particularly resonated with me. Why do we need a manifest, a spine, an NCX, a nav document, landmarks, and guides?
What would an e-book look like, if we tried to avoid as much complexity as possible? The idea wouldn't go away. I try to avoid abstract thinking, and so my natural reaction was to build a sample book and see what happened. So I'm in the middle of that process, with Moby-Dick, of course. Let me know if you want me to email you a copy.
Another goal is to make authoring easier. I wonder how much of the complexity of previous e-book specifications was to make life easier for reading system developers, who have course been the major participants in the standards bodies (not that there's anything wrong with that!).
INSIDE EPUB ZERO
An EPUB Zero file is a zipped folder containing only content files. It's identified by the file extension. There is no mimetype, no META-INF, no container.xml. And so the zip process is much simpler, your operating system's zip command should work without changes. None of this
zip -v0X $FOLDER mimetype zip -vr $FOLDER * -x $FOLDER mimetypebullshit.
The heart of an EPUB Zero is the index.html file. The reading system (if they were ever to exist) would look inside the zip for index.html. This file provides navigation (via the nav element), defines the order of content documents (via the nav element!), and contains document metadata (see below). Not all content documents need to be in the nav element; if they're in the zip you can reference them via links and have an "out of spine" item. Same goes for images, as well as audio, and video (perish the thought).
An open question is how to define what happens when the book first opens. You might not want to see a complex table of contents as soon as you open a book. Perhaps if the nav element is hidden, the reading system would then just open the first document referenced by nav.
I'm unsure how to handle metadata. My first thought was to use the head of index.html:
<meta charset='utf-8'> <title>Moby-Dick</title> <meta name="dcterms.creator" content="Herman Melville"/> <meta name="dcterms.title" content="Moby-Dick"/> <meta name="dcterms.identifier" content="x9780000000000"/> <meta name="dcterms.language" content="en"/> <meta name="dcterms.modified" content="2013-02-14"/> <meta name="dcterms.publisher" content="Harper & Sons"/>
That strikes me as inadequate. Would this be enough for the very simplest cases, in conjunction with some sort of link to an ONIX record? The middle ground here seems like dangerous ground, as we always want to handle "one more thing…"
All content documents are HTML5, which of course can contain SVG and MathML. I reserve the right to use the XML serialization for any EPUB Zero I produce :)
WHAT IS AN EBOOK?
When you go to a website, you navigate through the content by clicking on links, going from page to page. What makes an e-book different is that the sequence of pages is defined ahead of time, and the reading system helps the reader navigate. Does this mean that a plain web browser won't work as a (packaged) e-book reader, without some sort of extension or scripting?
I haven't thought about how accessibility would work in this context, or digital rights management (could a digital signature work with this file structure?), or many other things. Maybe the ultimate answer is that we need the complexity of the existing specs. But I'd prefer to be convinced that this is too simple, rather than assume that what we have is just right.
Dave (writing, of course, as a private citizen)