[eschwartz]

Originally Posted by Sarmat89

For a book, you need what DocBook don't have, and many features are not needed for books.

As Toxaris says -- what, exactly, do you claim DocBook doesn't support?

Also, you cannot choose an arbitrarily complex format like HTML/CSS or DocBook, as the clients will not be able to implement it fully. You need a clear, compact and comprehensive format that everyone can implement in its entirety.

The mere numerical quantity of things-that-have-to-be-implemented is not what determines whether a rendering engine can fully implement a spec. And I find the suggestion to be laughable.

How on earth do you think Gecko and Webkit (deliberately not mentioning MS Trident) manage to produce proper support for HTML+CSS?

Also, are you aware that pretty much every Android and iOS ereader app, embeds webkit to do the HTML layout?
Which is, incidentally, probably why they have a better track record for implementing EPUB3.

That is demagogy, again. Every book has the cover artist mentioned in its colophon, along with other copyright holders. The problem is that you need a dedicated person in the library to extract it and put into custom metadata. It would be an obvious decision to include this in format itself to enable machine processing.

I am looking at some books published by the Big 5 Publishers, and they don't mention a thing about the cover artist. (Well, a couple of them do. But most of them don't.)

Well, that was an easy one to disprove.

You cannot use other people's work without attribution, you know.

Of course you can.

You can't use work that other people hold the copyright to, unless doing so is in your contract.
And you certainly don't have to attribute them if you own the copyright by virtue of having purchased the rights.

Occasionally, just... occasionally... people use cover images that weren't downloaded for free from the internet under a CC BY{,-SA,-ND} license.

You need to have some level of structure in your Word file too, to get a hyperlinked TOC required for Kindles and the TOC itself.
Therefore, same methods can be employed to create a semantically structured document.

ToC structure requires a semantic ToC.

Your proposed format wants to perform magnitudes more structure than merely marking out the chapters.

Come back when you have a better comparison.

That's just one method for simple readers. There are readers that can interpret XML formats directly.

So tell me, when is this reader going to finally hit the commercial market?

To make a sidebar, or an illustration caption, with XHTML, you need to implement the HTML layout. Not all readers and devices can do it.
To render a semantic sidebar, you can use any model your reader is working with: you already know what you need to do, you don't need to copy the physical formatting to imitate it.

So... to use XHTML for the purpose, we are dependent on the reader/device to implement the necessary specs?
But of course, if it is all XML, the reader/device does NOT have to implement the necessary XSLT transforms?

I'm afraid you've lost me there. Can you repeat it again, with real ideas?