Adequacy of EPUB?

[Arios]

Quote:
Originally Posted by Hitch
I wrote a big long response to this, and eschwartz' response, and realized that this is a honking waste of time.

Quote:
Originally Posted by eschwartz

Probably.

Definitely!

[dgatwood]

Originally Posted by JSWolf

Because all the stuff needed to make ePub 4 would be done by sane people instead of the insane committee that created ePub 3. Well, maybe not fully sane people, but sane enough when it comes to eBook features. And no company such as Apple will be allowed to submit suggestions or bribe anyone. And finally, no features would be added that would not work on an eInk Reader that was of a certain specification. So that would remove audio and video for sure.

I don't think the EPUB 3 folks were insane. Adding audio, video, etc. are very useful for interactive textbooks, which was the main goal of EPUB 3. It isn't useful for fiction, obviously, but you don't have to use all those features if you don't want them.

My biggest problem with EPUB 3 is that they didn't fully make it backwards compatible with EPUB 2, in that it isn't possible to provide a set of metadata that is guaranteed to be fully functional with both EPUB 3 and EPUB 2 readers, thanks to reuse of certain elements in entirely different ways (the HTML TOC being the big one, IIRC). That's a very Apple-like mentality (no need to support hardware more than three years old), and I think it was a mistake.

And there are significant accessibility issues with EPUB 3 video. (For example, there's fallback content for readers that can't show video, but the spec says that this isn't intended as an accessibility solution, and provides no suggestions for alternatives that would adequately serve blind or deaf readers.)

Basically, it seems like a sloppy specification in many ways, rushed out in an effort to create a standard that could be suitable for electronic textbooks, only to be ignored by Apple in the end, replaced by a proprietary standard that is only partially based on the spec. That's what I don't like about EPUB 3.

[Hitch]

Originally Posted by Arios

Definitely!

I think that people get a whiff of things that they think are cool...like DC metadata and semantics...(I remember when I thought XSLT was "cool"), and everything else falls by the wayside. And often, the cool bits really have nothing whatsoever to do with the work part.

It's not "bad," per se; it's just distracting.

Hitch

[Sarmat89]

Originally Posted by eschwartz

And the EPUB manifest recognizes "type" semantics declared in the <guide>.

That is good and fine, but do you really suggest that chapter texts were broken with one or more separate "epigraph" documents? What about letters, signs and chapter headers?
Hell, and even "George Martin", "Martin, George RR" and "George R.R. Martin" are three different persons in EPUB metadata format!

Originally Posted by Hitch

how many ePUBs have you built? XML-->XSLT to eBook transformations have you done?

Quite a few. / I didn't use XSLT to HTML transformations.

[Hitch]

Originally Posted by Sarmat89

That is good and fine, but do you really suggest that chapter texts were broken with one or more separate "epigraph" documents? What about letters, signs and chapter headers?
Quite a few. / I didn't use XSLT to HTML transformations.

Then why on EARTH do you think that using XML is better? I think you need to go forth and do some XSLT transformations on XML-crafted books. I have. I think you'll be surprised at how you feel about it after making 5-10 of them. Or, hell, after TWO.

Just saying. You are adamant that XML is a superior book-making methodology, but you haven't made any. Why don't you try a few, first?

Hitch

[Sarmat89]

Originally Posted by Hitch

Then why on EARTH do you think that using XML is better? ... You are adamant that XML is a superior book-making methodology, but you haven't made any.

1) Why limit yourself with XSLT? If you trying to replace E-book reader with a web browser and feed it with autogenerated HTML, you are doing it wrong.
2) There are several XML document and E-book formats existing already, so I don't see any issues with it. Any XML format is better, as they operate on sane entities, such as <em>, not presentation HTML monsters as <span class="Kursiv"> (or even better, <span style="font-style:italic">).

[Hitch]

Originally Posted by Sarmat89

1) Why limit yourself with XSLT? If you trying to replace E-book reader with a web browser and feed it with autogenerated HTML, you are doing it wrong.
2) There are several XML document and E-book formats existing already, so I don't see any issues with it. Any XML format is better, as they operate on sane entities, such as <em>, not presentation HTML monsters as <span class="Kursiv"> (or even better, <span style="font-style:italic">).

DANGER, DANGER, WILL ROBINSON, RANT COMING:

See, gang? I knew that 5 posts ago, this was a losing proposition. (Does anyone else feel like we've time-traveled back to the 90's, when XML was the BIG NEW THING?)

The whole POINT of XML was that--it was extensible. It allowed you to use Markup, and define your own tags, the order in which they occur, and how they should be processed or displayed. The "hoorah" about XML, basically, was that while humans can read and understand HTML, inferring the intention of a given paragraph, computers can't, in terms of SCHEMA. So..that advantages us in book creation how, precisely? What, using SCHEMA to create all books? Yoiks.

Well, I don't know what eBook readers you're using, but the ones I use, and the ones I build eBooks for, all use HTML/XHTML, not XML straight up. While we're at it, we may as well just use Markdown, and display the book that way. Jeeze, let's just use Textile. That way, it can be even SIMPLER.

I'm sorry, but you've yet to convince me. All you've done is say that XHTML or HTML is "bad." The fact that it doesn't support advanced Calibre metadata/tags/categorizing...so what? You're assuming that everybody else wants to be able to categorize and find books based on things like "all covers by so-and-so," which assumes arguendo that the book creators would TAG that element for you. I've seen hundreds of eBooks that don't even have completed alt tags for images; why the hell would anyone assume that someone making eBooks with XML would fill in ALL the semantic metadata that you'd want?

This is just...pipe-dreaming. And it's not a pipe-dream that you've managed to sell to anyone here. So what, you don't like <span class="italic">? From what I am seeing from you, you want XML simply because it's MORE rigid, not less--or, it would be, IF implemented by YOU. As it is now, it's as freewheeling as HTML, for all intents and purposes.

For it to do what you want, it would have to be heavily regimented (SCHEMA, anyone?), so that everyone used the SAME elements, and worse, used the same specifications for each genre--e.g., mystery, romance, yadda-yadda. So instead of styling/formatting a book as a BOOK, you'd be stuck with a set of specifications, created by somebody ELSE, that you'd have to use for "mystery," or for "romance," et al. YICK. Talk about something created for some OTHER purpose!

XML is a way to keep large amounts of data in a somewhat tabular format. It's essentially databases for text, for all intents and purposes--like thousands of medical records. It's certainly not really designed for readers or easy reading.

I'm still waiting for you to show me ONE advantage of what you're proposing, other than (sorry) very personal-opinion arguments like "spans are bad." That's an OPINION. And it's an opinion that not everyone shares. I don't see any advantage in time, or ease of use or creation, or anything else in your idea. It simply SEEMS to fit with some preconceived notion you have, of how things MIGHT be, if some other party, board, committee, etc., comes up with some undefined plan to implement XML for eBooks, in a purer state than XHTML. And if they decide to use XML, but leave it as loosey-goosey as it is now? Then what? Will you be back here talking about how the XML standards are "bad," because they don't fit with your idea of how they SHOULD work?

Honestly, every single thing you're talking about is mitigated completely by any competent bookmaker that uses standard HTML and CSS. And I'd be the first to agree, yes, there are a lot of crappily-made books out there. BUT, the vast bulk of the self-publishing industry CERTAINLY will never a) use standarized HTML or b) use XML, that's fer damn sure.

(I'm picturing the KDP Boards, if Amazon implemented an XML SCHEMA for eBooks. Mother of God. ) Hey, wait, maybe I should indeed vote for this! It's pure evil genius.

Back OT:

So, when you can show us actual advantages, instead of an opinion that the way HTML works is "bad," I'm certainly willing to listen. But so far, I'm only seeing your opinions about something that honestly, no offense, I'm not convinced that you understand all that well. BTW: with the exception of ePUB2 validation, pretty much all eBook readers understand and will display <em> just fine. That's a bad example.

For the record, I use schema on my website. It's a giant pain in the ass, because already, Google has "decided" what schema should be where. You use it wrongly, you're penalized. Does the SCHEMA that Google wants/allows match other SCHEMA? NOOOOOOOOOOOOOOOOO, it does NOT. And the same bloody thing would happen with eBooks. Doubt it? Just go ask Apple.

(Sorry, my MR Dudes and Dudettes; </rant>).

BTW: what XML eBook format are you proposing that already exists?

Hitch

[eschwartz]

Originally Posted by Sarmat89

That is good and fine, but do you really suggest that chapter texts were broken with one or more separate "epigraph" documents? What about letters, signs and chapter headers?

I genuinely have no idea what this sentence is attempting to say.
Sorry.

Hell, and even "George Martin", "Martin, George RR" and "George R.R. Martin" are three different persons in EPUB metadata format!

And an apple is different from an orange. If I add bogus information to the metadata, it will of course be wrong.

Standards for writing peoples' full names are not difficult.
George R. R. Martin does not go by "George Martin", so that is objectively wrong.
"Martin, George R. R." is not author metadata, it is "author sort" metadata, and once again, this is an objective standard.
The idea of using-a-space-or-not between initials is actually interesting, but says more about, once again, standards, than anything else.

So, I call a whole slew of red herrings on you, and say your whole bogus complaint has nothing to do with EPUB and everything to do with standardization of metadata.

[Hitch]

Originally Posted by eschwartz

I genuinely have no idea what this sentence is attempting to say.
Sorry.

<snippage>...once again, this is an objective standard.
The idea of using-a-space-or-not between initials is actually interesting, but says more about, once again, standards, than anything else.

So, I call a whole slew of red herrings on you, and say your whole bogus complaint has nothing to do with EPUB and everything to do with standardization of metadata.

YES, perzackly. Much more succinctly than I. So, what he said ^.

Nope, I lied, not done yet: from my perspective, it's moot. I'd still have to wrap tags around EVERYTHING, whether it's a P in html or "body" in XML. SS, DD. No bookmaker would find it faster, I think. Also, it would be far WORSE for anyone in my line of work, becaue the XML output from Word is simply godawful, whereas any Word file can be cleaned easily by any competent person into clean(ish) HTML.

Hitch

[eschwartz]

Originally Posted by Hitch

DANGER, DANGER, WILL ROBINSON, RANT COMING:

See, gang? I knew that 5 posts ago, this was a losing proposition. (Does anyone else feel like we've time-traveled back to the 90's, when XML was the BIG NEW THING?)

Yes, but I had the time to spare, so I didn't mind posting here.

But it is too bad MobileRead doesn't have a "topics going nowhere" subforum, for "topics deemed to be bikeshed".
I have seen one like that elsewhere.

[Toxaris]

The only 'XML'-like format I can come up with with with regards to ebooks is Tex I think. Although in theory XML can give you much more control over the semantics, it does nothing for you with regards to presentation. You *will* need to convert it to something else or use a stylesheet for it. So, in the end it will give you the same issues as XHTML as you see it. Sure, the Dublin Core is seriously lacking in several metadata areas. Then again, I would already be very happy if publishers would use the metadata options there already are and in a consistent manner.

Using XML for an eBook with full semantics can only be achieved with a strict schema that must be used. Considering the issues there are with ePUB already due to compromises (and listening to wrong companies), no publisher will go for that.

[Terisa de morgan]

Tex, my God, the newest thing in the world (Not laughing at you idea but the big novelty which was proposed). And, yes, I know Tex. And yes, I've used it... without fancy editors... so using for writing a book... perhaps we can go to LaTex...

[Sarmat89]

Originally Posted by Hitch

What, using SCHEMA to create all books?

Yes, books are simple enough matter to be described by an XML schema.

all use HTML/XHTML, not XML straight up.

That is just the matter of format. Generating HTML from XML source is so trivial it can be done on an E-ink Linux device easily.

which assumes arguendo that the book creators would TAG that element for you.

It is always 'tagged' in colophon; it would be in proper metadata if such existed.

that someone making eBooks with XML would fill in ALL the semantic metadata that you'd want?

People make books with WYSIWYG editors, that provide nice toolbars and forms for filling this kind of stuff in.

So instead of styling/formatting a book as a BOOK, you'd be stuck with a set of specifications, created by somebody ELSE, that you'd have to use for "mystery,"

You would create a book like a BOOK, not like a webpage with options for form fields and buttons, but none for footnotes, chapters or scene breaks.

pretty much all eBook readers understand and will display <em> just fine.

And book producers have a myriad of options of imitating the <em> with spans and CSS. With a real format, there is only one way to do that, which all readers, converters and editors support.

what XML eBook format are you proposing that already exists?

We need a new format, that's quite clear.

Originally Posted by eschwartz

"Martin, George R. R." is not author metadata, it is "author sort" metadata, and once again, this is an objective standard.

EPUB metadata standard does not provide for autors' names, surnames, normative references and other logical parts in any way. It is just an arbitrary string with an arbitrary sort key. You cannot order the book list for authors' surnames, as it is impossible to know what is the surname. Same with genres, annotations, etc. etc.

[eschwartz]

Originally Posted by Toxaris

Sure, the Dublin Core is seriously lacking in several metadata areas. Then again, I would already be very happy if publishers would use the metadata options there already are and in a consistent manner.

I don't really care whether publishers use carpy metadata or not.
I just want the Dublin Core to recognize series, so I can fix the metadata and ereaders will recognize it.

[eschwartz]

Originally Posted by Sarmat89

EPUB metadata standard does not provide for autors' names, surnames, normative references and other logical parts in any way. It is just an arbitrary string with an arbitrary sort key. You cannot order the book list for authors' surnames, as it is impossible to know what is the surname. Same with genres, annotations, etc. etc.

That is ridiculous.

Authors surnames are the first comma-separated component of the sort key.
That is why the sort key was defined and created in the first place.


Annotations are not incompatible with EPUB, it is merely that the EPUB3 committee wasted their time on video ebooks when things like an expanded Dublin Core and standardized annotations should have been a bigger issue.


Once again, each time you raise the issue of "we need a new format" because "the current format hasn't standardized $x", you are trying to throw the baby out with the bathwater.

You still have yet to provide one decent explanation for a single one of your conclusions in this thread.