Nevertheless, at least with regards to ZIP, a ZIP is a ZIP whether compression of individual files is used or not.

The issue of compression will always be political. But I agree that with today’s higher bandwidth and cheap ultra-high density disk drives where space is no longer an issue (both server and client sides), looking at the necessity of compression of text-encoded files can certainly be revisited. As noted before, Bill Janssen is a strong proponent of a MHTML-like approach. One can certainly imagine containing an OPS Publication within MHTML. As I’ve argued over the last few years, it’s really not the container which is the issue – it is the creamy filled center, the OPS Publication.

Jon, can you share where the impetus for compression is coming from? I presume that device manufacturers and publishers simply want to maximize the number of books that can be contained on one storage medium?

If compression is a political hotpoint, it would be good to consider requiring compliant EPUB reading systems to recognize two different containers, one compressed, the other not. For example a directory bundle with a .ops extension, and the .epub compressed version.

From my understanding (and this is not a knock since I understand the difficulty of building reading systems), FBReader’s support of EPUB is pretty sparse.

That is, from my understanding the current FBReader cannot be considered a conforming OPS Reading System per the OPS spec. Over time it may reach the level of OPS support where it conforms to all OPS reading system requirements, and I hope it does.

Let a thousand flowers bloom!

Certainly the kitchen sink http: could be used, and I assume it could be tweaked to carry something equivalent to the epub: IRI. But I’ll let the web developer experts chew on this. It’d still require special applications.

Standing back and looking at the bigger picture, we must have a “single file” for distribution, sale and archiving. Just like a book is a single object, an e-book MUST be a single digital object. I can’t imagine anything other than this, at least for a long-time. Even computers have what’s called “file systems” where the single file is still king.

Now this brings up what to do if not ZIP for this single file container.

Interestingly, one thing brought up is to place all the OPS files into a single XML document. Unfortunately we quickly discovered that Microsoft holds a key patent of putting multiple files representing a document/publication into a single XML document. This is the reason OpenOffice documents are a jar file containing multiple files. The OpenOffice folk originally wanted to encase all the files into a single XML document, but the patent issue stopped them. (This is what I was told, anyway – I’ve not verified this from other sources.)

Even with the XML solution, there’d be strong pressure to use compression, so again we are back to the issue of compression, which seems to be what the real issue in this discussion.

Web browsers handle local links well, but there is no mechanism for this in archives. How would a browser, or any program for that matter, follow a link from one document in an archive to another in the same archive?

My program generates multipage HTML files from a single Project Gutenberg text file. If I cannot link between files, what is the point of separating them in the first place? And what is the point of putting the files in an archive anyway as opposed to one big fat text file?

epub:/OPS-Pub-Identifier/content-doc-filename/#id

Or even use the more elaborate XPointer schemes when there don’t exist id’s at the points in the documents we’d like to point to.

@keith – I doubt that the folks who work on the major browsers are going to make OCF browsing a huge priority anytime soon. Likewise, until there’s a good reason, search engines are not going to do zip indexing (it took them long enough to index PDFs and Flash files).

Many here seem to have missed the first point, which is that there is room for another type of container more inclusive of browsers as reading agents.

There are good reasons that the W3C never proposed wrapping web sites in zip containers, and they have to do with linking, annotation and searching–all things we expect from digital books. For the same reasons, we don’t develop web sites as collections of PDFs. Search engines DO NOT index the contents of compressed files, and there is no standard scheme for linking into those contents. This has serious implications for any document format that relies on compression.

1) Direct rendering in capable reading systems, and

2) Conversion into other formats. Who does the conversion (including by the end-user) is immaterial.

(The original view of OEBPS being an “exchange format” was essentially publicly stated for “political reasons”, but we in the working group always considered both possibilities above in all decisions we made.)

So obviously an EPUB–>”local web site” converter fits into the general scheme of things which the OEBPS Working Group considers as viable/approved/encouraged/etc.

Let a thousand flowers bloom!

I was thinking more of a stand-alone utility, rather than a web application, but either works as a proof of concept. Note that format shifting is a recognized method of supporting EPUB, so EPUB to EPUB+WebFiles would seem to meet that criteria and once the WebFiles are created they should work remotely.

From my understanding, it is CSS-compatible (not like TEI which has structures that are not compatible with the HTML/CSS paradigm), and so one should be able to apply a default browser style sheet extension. I expect that very few EPUB’s the average book reader will obtain (in the short-term at least) will include DTBook documents. But in the long-term we may see more DTBook. It is a quite good markup vocabulary (XHTML with extensions) that forces structure on the author, which is Good™