Adequacy of EPUB?

[Sarmat89]

Define why XHTML is 'simpler'. Simpler for book creator, reader creator or the end user?

Because implementing a fixed semantic standard gives more freedom in its implementation: the LCD device may, for example, render <em>s as inverted text, but <poem>s as left margin; if a physical/presentation format is used (HTML), it is impossible to do, as the formatting used is the same for both those elements.

[eschwartz]

Originally Posted by Sarmat89

Define why XHTML is 'simpler'. Simpler for book creator, reader creator or the end user?

Actually, I meant simpler in terms of the XHTML itself, hence my reference to the XHTML.

But now you mention it, I believe it is also simpler for the book creator, AND reader creator. The end user doesn't care one way or the other.

Because implementing a fixed semantic standard gives more freedom in its implementation: the LCD device may, for example, render <em>s as inverted text, but <poem>s as left margin; if a physical/presentation format is used (HTML), it is impossible to do, as the formatting used is the same for both those elements.

What??? <em>s are HTML.

And ebook authors actively, aggressively want to control how their poems look.
People who write poems are bigger control freaks about their work than pretty much any other type of author.
Any new format that involves handing over the controls from their carefully specified presentation (regardless of how semantically chosen their CSS classes are) to some arbitrary committee-designed specification what a poem should look like...
They would have a cow. No, make that multiple, pregnant cows. Armies of them, in fact.


Keeping in mind that as has been repeatedly mentioned in this thread, without you acknowledging those posts, ebook creators, including poets, have been and still are making semantically-defined ebooks that semantically define poems, letters, and many other things you haven't mentioned.

THEIR job is as easy as it is going to get (and the biggest problem is vendors and app-makers defecating on the EPUB standard, as I already mentioned above).

..

So yet again, I want to know -- what actual problems do you think need to be solved, and how do you intend to solve them?

If you feel there is a problem that no one else acknowledges is a problem, then step one of this thread should be trying to persuade us that it is indeed a problem.

[dgatwood]

Originally Posted by Hitch

...given that the cover is supplanted by the cover art that you upload at step 5 (or is it 6 now? The "Marketing image" upload, in any event...), why do you do this?

Honestly, I forgot.

[Hitch]

Originally Posted by dgatwood

Honestly, I forgot.

Dag:

Sorry, you forgot why you do it, or you've forgotten that Amazon supplants the cover you're building in the MOBI in the first place?

In any event--you needn't go through that dance with the cover. We've tested and proven that Amazon absolutely, positively, replaces any embedded cover with the image uploaded at Step whatever-it-is.

Hitch

[dgatwood]

Originally Posted by Hitch

Dag:

Sorry, you forgot why you do it, or you've forgotten that Amazon supplants the cover you're building in the MOBI in the first place?

The first one.

[Hitch]

Originally Posted by dgatwood

The first one.

Hmmmm, and I thought I was losing it! ;-)

Well, brah, you don't have to do that any longer. I mean, tweak the cover, not lose it.

Hitch

[Sarmat89]

Originally Posted by eschwartz

So yet again, I want to know -- what actual problems do you think need to be solved, and how do you intend to solve them?

1. The important metadata are stored in EPUBs in plain text format, and some cannot be stored at all.
The solution: store the metadata in XML format with a defined set of fields: (Name;Surname;UUID;etc); (Series;#); (Genre;Sub-genre;Sub-sub-genre;etc). The metadata come from a list which is designed for books, unlike DC.
2. The underlying HTML/CSS code is not standardized, and allows partial implementation of its features. There is no way to predict what the user's device is going to support.
The solution: the exhaustive XML semantic format, in which each part of a book format has one and only one possible representation. Physical formatting (CSS) is separate from logical formatting (elements used).
The device is free to apply any needed transformations based on the semantic content to achieve the supported output. No longer books are set of paragraphs, divs and spans with no semantic role and opaque formatting. Example: in HTML, you cannot be sure what does the paragraph style "SJ8M" (left margin, top margin, no break, italics, 80% size) is intended to do, and you cannot adjust the presentation if you do not support CSS features from the above list. With XML, it is clear that it is 'epigraph/p', and you can use any methods you support to format it according to your internal stylesheet combined with book and user stylesheets.
3. Using browsers to display the raw HTML means working around the renderers' quirks and compatibility issues.
The solution: XML is free of preconceptions about the physical format necessary in WWW.

I believe it is evident why a custom XML format yields better results for 95% of fiction and non-fiction EBooks than EPUB.

[eschwartz]

Originally Posted by Sarmat89

1. The important metadata are stored in EPUBs in plain text format, and some cannot be stored at all.
The solution: store the metadata in XML format with a defined set of fields: (Name;Surname;UUID;etc); (Series;#); (Genre;Sub-genre;Sub-sub-genre;etc).

Demonstrably false. Plaintext metadata has never existed in the EPUB spec, and if you try to use plaintext metadata I am not aware of a single piece of code in the world that will understand it.

This would be because the metadata is written in XML, just like you wanted.

The metadata come from a list which is designed for books, unlike DC.

You know, I am fairly positive I mentioned this already... but if you have a problem with the DC metadata, why not complain to them, rather than trying to start a competing ebook format for the sole purpose of arguing with the DC over the list of available metadata fields?

2. The underlying HTML/CSS code is not standardized, and allows partial implementation of its features. There is no way to predict what the user's device is going to support.
The solution: the exhaustive XML semantic format, in which each part of a book format has one and only one possible representation. Physical formatting (CSS) is separate from logical formatting (elements used).

HTML and CSS are very standardized.
And anyone who is gong to break HTML+CSS compatibility by partial non-implementation will also partially not implement your proposed schema.

But XML has no representation and no formatting and no concept of CSS, except through a linked schema. Sure, XML is impossible to misinterpret, but that is only because it doesn't define anything.

So we are back to your schema. Since XHTML is the current schema used by EPUB, and ereader makers went ahead and "partially implemented its features", they will presumably do the same to your proposed schema (notwithstanding that you still haven't actually proposed it.)

The device is free to apply any needed transformations based on the semantic content to achieve the supported output. No longer books are set of paragraphs, divs and spans with no semantic role and opaque formatting. Example: in HTML, you cannot be sure what does the paragraph style "SJ8M" (left margin, top margin, no break, italics, 80% size) is intended to do, and you cannot adjust the presentation if you do not support CSS features from the above list. With XML, it is clear that it is 'epigraph/p', and you can use any methods you support to format it according to your internal stylesheet combined with book and user stylesheets.

Oh, wait.

Do you mean there should be NO schema, and every ereader needs to reimplement the entire parsing and rendering logic?


Now I'm getting really confused, because I literally cannot think of one reason why anyone would ever suggest such a thing, even taking into account your "disagreement" with EPUB.

3. Using browsers to display the raw HTML means working around the renderers' quirks and compatibility issues.
The solution: XML is free of preconceptions about the physical format necessary in WWW.

True. XML has no defined look and therefore cannot have any preconceptions about how your book should look.

This is a bad thing, as your book has no look, only a folded XML tree...

I believe it is evident why a custom XML format yields better results for 95% of fiction and non-fiction EBooks than EPUB.

XHTML is a custom XML format, and EPUB validates against XHTML.
Aside from that, XML on its own is the single most useless form of data in the known universe, since:

• unlike (X)HTML it has no schema to interpret it
• unlike markdown or text/plain it has no visual meaning

Thus, it has no meaning whatsoever, and is in fact the platonic ideal of "empty meaning" (or perhaps, meaning that fell into a black hole).

It is marginally possible to access data that is even more meaningless, by inspecting the contents of /dev/urandom

[DaleDe]

Originally Posted by Sarmat89

1. The important metadata are stored in EPUBs in plain text format, and some cannot be stored at all.
The solution: store the metadata in XML format with a defined set of fields: (Name;Surname;UUID;etc); (Series;#); (Genre;Sub-genre;Sub-sub-genre;etc). The metadata come from a list which is designed for books, unlike DC.

This an the other data you posted is false. Study the OPF data in our wiki for the metadata which is all tagged in XML format.

Dale

[Sarmat89]

Originally Posted by DaleDe

This an the other data you posted is false. Study the OPF data in our wiki for the metadata which is all tagged in XML format.

What exactly is tagged in OPF in this example?

<dc:creator id="creator">Haruki Murakami</dc:creator>

Where are tagged name, surname and any uids?

<meta refines="#creator" property="role" scheme="marc:relators" id="role">aut</meta>

Where are roles for cover artists, lyrics writers and translators? Why the 'author' is applied to the entire file and not to logical sections therein? If there is preface written by Mr. X, how that metadata scheme is going to represent it?

<dc:subject>Novel</dc:subject>

What the hell is 'novel'? It is not a genre. It is a form factor.

If you cannot see that EPUB scheme is defective, I don't know what to say.

[Sarmat89]

Originally Posted by eschwartz

XML on its own is the single most useless form of data in the known universe, since unlike (X)HTML it has no schema to interpret it

There is a scheme which defines a file format. As soon as you know what book part is being represented by the XML element, you can apply any formatting on your own, not being in complete dependance on faithful representation of the HTML author's CSS/physical format.

I have yet to see EPUB which have no semantically absurd elements like '<p>&nbsp</p>'. This is physical formatting which can be easily ridden off with a specific semantic markup.

Consider that many libraries of any size use their own formats for their digitized funds, as EPUB cannot represent the document structure which is needed for digital processing. Many of this formats are exactly this: semantic XML-based formats.

[Sarmat89]

A book from the real life: It has 2 authors, A1 and A2, and a poem written by A3. It is the anthology in which one of 4 stories is written by A1 and A4 instead. There is a cover image by I1 and interior illustrations by I2. The book text is translated by T1 and the poem by T2.
Can this information be represented in EPUB format, with the possibility of automatic search and catalogization? My opinion is <strong>no</strong>.

[eschwartz]

Originally Posted by Sarmat89

What exactly is tagged in OPF in this example?

<dc:creator id="creator">Haruki Murakami</dc:creator>

Where are tagged name, surname and any uids?

<meta refines="#creator" property="role" scheme="marc:relators" id="role">aut</meta>

Where are roles for cover artists, lyrics writers and translators? Why the 'author' is applied to the entire file and not to logical sections therein? If there is preface written by Mr. X, how that metadata scheme is going to represent it?

<meta name="dc_proposed:translator" content="Translator Name">

<dc:subject>Novel</dc:subject>

What the hell is 'novel'? It is not a genre. It is a form factor.

If you cannot see that EPUB scheme is defective, I don't know what to say.

<dc:subject>Poopy</dc:subject>

Well, clearly the person who tagged that was an idiot. I am not sure why you think that is a flaw in EPUB, rather than a problem with a publisher on crack.

[eschwartz]

Originally Posted by Sarmat89

There is a scheme which defines a file format. As soon as you know what book part is being represented by the XML element, you can apply any formatting on your own, not being in complete dependance on faithful representation of the HTML author's CSS/physical format.

I can already do that with custom CSS.

Are you saying you don't want authors to be allowed to define CSS?

I have yet to see EPUB which have no semantically absurd elements like '<p>&nbsp</p>'. This is physical formatting which can be easily ridden off with a specific semantic markup.

I strongly disagree with your opinion that &nbsp; is absurd.
I agree that there are some formatters that use it in the wrong way.

I vehemently disagree with the conclusions you have drawn.
Speaking of absurd, I don't see why using an XML tag to describe a non-breaking-space is any better than using a unicode character.

Consider that many libraries of any size use their own formats for their digitized funds, as EPUB cannot represent the document structure which is needed for digital processing. Many of this formats are exactly this: semantic XML-based formats.

You mean they use XSLT processing to produce EPUBs? Or are you going to actually give us an example of what you claim to be talking about? (Base on your track record in this thread, I can only assume everything is yet another outrageous claim.)

[eschwartz]

Originally Posted by Sarmat89

A book from the real life: It has 2 authors, A1 and A2, and a poem written by A3. It is the anthology in which one of 4 stories is written by A1 and A4 instead. There is a cover image by I1 and interior illustrations by I2. The book text is translated by T1 and the poem by T2.
Can this information be represented in EPUB format, with the possibility of automatic search and catalogization? My opinion is <strong>no</strong>.

My opinion is yes.

There are four authors.
There is one cover illustrator, tagged by a custom opf namespace because the Dublin Core committee are dinosaurs. Note that any other format would also have to follow the Dublin Core.
There is one illustrator, with the same rules as the cover illustrator.
It has one translator, with the same rules as the illustrators.


It is literally that simple. And all you have to do is complain to the Dublin Core committee.