That's a first quick start. Let's discuss these 8 first ideas and add to them afterwards.
</Daniel>
ZIP is the only manifest
toplevel document is like Apache's toplevel document, in other words it's index.(htm|html|xht|xhtml)
that document contains a OL used for all ToC purposes
metadata of the package are inside that document
no more ID/IDREF mechanisms in metadata, if we still need to refine metadata, let's used nesting
image cover is also declared through one simple <meta rel="cover" href="..."/> there
- I have mixed feelings about the mimetype file. It's useful for downloads over low-bandwidth to detect if a package is supposed to be conformant but it's also a blocker when a tool like iBooksAuthor forks that mimetype. At this time, I'm more in favor of dropping it.
I want to get rid of the properties declaring mathml, svg and script. I think they should be replaced by the presence of the corresponding namespace on the <html> element of the target document or the presence of at least a <script> element inside the <head> of the document. That way, non-conforming UAs don't have to parse the whole thing to know they will fail rendering the document
On 26/02/13 18:36, Dave Cramer wrote:
Thanks for getting us started! One problem is that we have three members
so far—you, me, and Hadrien. OK if I announce the mailing list on the
blog? I'll send invitations to a few more folks—suggestions welcome.
I am sure we can find a way of having one single list that serves all
needs/purposes.
Regarding point #5, the ID/IDREF mechanisms can be used for more than refining metadata - it lets you add metadata to any element in the document.
Whether that capability is worth the complexity is an open question (I think it's not), but it's important to understand it before removing it.
Maybe we should start with requirements instead of technical chats...
My requirements are the following:
1. unzip an ebook behind a web server and the book is immediately
readable on the Web as is
2. zip a set of web pages with an index file and that's an ebook
3. modern browsers can render an ebook w/o code additions
4. navigation and fallbacks work "out of the box" in a modern browser
5. all ebook metadata can be extracted from the index file; using CSS,
they can be rendered in the index file
What exactly do we need for fallbacks ? EPUB3 has fallbacks, bindings and epub:trigger. None of them are widely used or supported.I'd like a good definition of what we'd call "fallback" in our own context.
5. all ebook metadata can be extracted from the index file; using CSS,
they can be rendered in the index fileThen, no document level metadata ? Only publication level metadata ?
Hadrien
However I still see "reading order" and "ToC" as two separate and
sufficiently independent concepts, and even though I appreciate the
compactness of a unified list, I worry about the additional complexity
that it brings (more for human inspection/editing, than for an automated
framework to write it or for a reading app to parse it).
While I wasn't around at the time, my belief is that the manifest-level fallbacks that EPUB has had since version 1 were mainly targeted at 1) supporting the notion of content documents using any XML grammar, and b) supporting fallbacks for html elements with no intrinsic fallback capabilities, such as <img>. (For example, consider that support for the PNG format was shaky during some years.)At this juncture, it would appear that a valid starting point assumption is to assume that the intrinsic fallback capabilities provided by html5, svg and mathml are sufficient; there might simply be no need anymore for additional layers of fallback provision.
Keep in mind that complete bibliographic records (onix, marc, mods et al) are extremely rich and go beyond what can reasonably be captured in html metadata (nor can it be captured in current epub package metadata btw).
So the important requirement here is what the scope of inlined metadata is. One approach is to make a clear distinction:
1) "real" or complete bibliographic records are always out-of-line, and can be referenced via unambiguous links
2) inlined metadata is only for the most fundamental RS needs (approx: identity, version, and "bookshelf display" fields such as author, title and the common dublin core stuff)
Note there are communities out there that nurture the dream of the completely self-contained publication in terms of bibliographic metadata (i.e. there should not be a dependency on an external object). Whether or not it is enough to say "your onix/marc/mods record can always be in the zip" I do not know at this point...
So I'll argue that* the basic principle of the epub3 navigation document, which is solely user-centric and uses separate lists for each navigation "purpose", is not broken. (And I'll note that it meets Daniel G's requirement to just-work-in-browsers as well)
* the need for a dedicated spine remains, but can perhaps be solved by using another approach than a dedicated or combined list. Daniel G mentioned html head introspection; how about just requiring link@rel=next and prev in content document head metadata?
* the need for a dedicated spine remains, but can perhaps be solved by using another approach than a dedicated or combined list. Daniel G mentioned html head introspection; how about just requiring link@rel=next and prev in content document head metadata?link@rel=next would be much more respectful of HATEOAS (http://en.wikipedia.org/wiki/HATEOAS), but we're not really designing an API here.In terms of complexity for the spec, authoring and RS, I'm not convinced that link@rel=next is better than a simple list of files in OL. I'd rather have all the "glue" in index.html than all over the place.
* You restrict yourself to elements that can embed a link@rel=next ot
similar metadata. HTML can, but should we restrict elements to HTML
files?
What would you think about relaxing the second requirement from
zipping a set of web pages to running a custom tool on them? Assuming
it was open-source, and created as part of the spec process.