EPUB3 is dead, long live EPUB3Lite...

[fjtorres]

Originally Posted by Ansileran

@fjtorres

Your link is unavailable here (in France)...

So what you are actually saying is that epub3lite makes sense for most readers (6", fiction) but you'd need epub3 for specific purposes and dedicated devices. Isn't that exactly what the point of epub3lite is?

Sorry.
It's not on Youtube and I'm pretty sure the clip on Hulu is not accessible everywhere.
Try a web search for: shimmer floor wax saturday night live
In the meantime, here's a transcript:
http://snltranscripts.jt.org/75/75ishimmer.phtml

What I'm saying is that it doesn't make sense to jam together specifications for two very different products into one. The result is going to be suboptimal for both. epub3 as published was a bad idea from the start.

The reality we are seeing is that the epub3 stakeholders, the people whose livelihood depends in some measure on commercial ebooks not sold by Amazon, have found the existing epub3 specification too unwieldy to fully implement and have been implementing those features that make sense for *their* customers. If MathML isn't in there, well, that tells you what *they* think of it. It doesn't make sense to *them*.

What any specific customer needs or wishes to see isn't really factoring into it; if you look at the list of stakeholders listed by the AAP, they don't see readers or writers as stakeholders, only the middlemen.

epub3lite (or whatever they call it in the end) is an attempt to coordinate so that all the stakeholders doing partial epub3 implementations support the same sub-set the same way and deprecate the same features. They need a spec that will let them go make money (like Amazon and Apple are) instead of waiting for a gold-plated religious symbol of standardization to magically appear.

The full spec has been out for two years without being implemented, and the AAP crowd obviously think it won't be implemented within the next year if they don't trim out the bloat and get *something* out there. Especially since that is what proprietary format vendors like Apple and Amazon did to create *their* rich content ebook formats in a timely fashion. Amazon got the job done in six months so, unless their software developers are way better than everybody else's, the failure of epub3 to materialize lies in the spec's attempt to be everything to all people and feature triage is the only option left to them.

In the tech world, decades of product design successes and failures have shown that letting marketting types write the specs for products leads to failure every time. That is why the techie mantra is K.I.S.S. - "Keep it Simple, Stupid". The proper, time-proven solution isn't kitchen sink specs; it is market segmentation. Different products, each optimized for its intended mission and audience.
Textbooks and technical papers *are* different from narrative text and cookbooks. Two different products selling at vastly different prices to very different buyers. So why commingle the two?

Might as well try to sell a floor wax that is also a desert topping.

[WillAdams]

Because of course, if there isn't time and money to do it right the first time, there's always a way found to do it over after everyone is exhausted by yelling about the errors.

And, those superscripts directly set in ePubLite will be properly handled by a screen reader, right?

[Namekuseijin]

I don't get it. isn't epub simply zipped html and css?

[Andrew H.]

Originally Posted by fjtorres

In the tech world, decades of product design successes and failures have shown that letting marketting types write the specs for products leads to failure every time. That is why the techie mantra is K.I.S.S. - "Keep it Simple, Stupid". The proper, time-proven solution isn't kitchen sink specs; it is market segmentation. Different products, each optimized for its intended mission and audience.

Sorry, but having techies design products has also led to many product failures due to a failure to focus on the market or non-techie end user. And I haven't seen any evidence that EPUB 3 was driven by marketing or that EPUB 3 Lite is not.

I think the biggest problem with the EPUB 3 standard is that it was drawn up by a committee. Design by committee often leads to bloat because there is no one to say "no". There is no product designer to make the hard decisions about what the design needs, what would be nice to have but might not be technically feasible, and what the design doesn't need.

Originally Posted by WillAdams

Because of course, if there isn't time and money to do it right the first time, there's always a way found to do it over after everyone is exhausted by yelling about the errors.

And, those superscripts directly set in ePubLite will be properly handled by a screen reader, right?

You can't, as the saying goes, let the perfect be the enemy of the good. If one feature desired by <1% of the user base causes 99%+ of the user base to have no product for two more years, you need to get rid of that feature and let the rest of the product move forward.

[HarryT]

Originally Posted by Namekuseijin

I don't get it. isn't epub simply zipped html and css?

One could simplistically think of it as being so, but an ePub document can contain rather more than that, such as SVG images, video, and audio content, too, as well as XML files which tie it all together.

[eping]

We can invent another format easily, which supports everything in the file, such as you can embed PDF, Word, and everything you need.
But without reality support and implementation, what the meaning of it?

Originally Posted by Andrew H.

I think the biggest problem with the EPUB 3 standard is that it was drawn up by a committee. Design by committee often leads to bloat because there is no one to say "no". There is no product designer to make the hard decisions about what the design needs, what would be nice to have but might not be technically feasible, and what the design doesn't need.

It could be that. It could also be that there are too many conflicting interests.

A company, like Amazon, can decide that product X is going to include the feature set Y. Feature set Y was decided upon because they want to reach the set of markets represented by Z. Employees must then implement X. The success of that product is determined based upon how Y represents the needs of Z and how much access the company has to Z.

When it comes down to committees, you have to decide what Z is. Since different companies serve different markets, that is a complex task. Once that is done, the members have to decide upon Y. Since each company is serving a different Z they will each see market needs differently, thus have different perspectives on necessary feature sets, which makes deciding upon Y difficult. Finally, X is no longer a singular item. It is now a set of products (call it XS). Since different developers have different approaches to implementing Y, the elements in XS have slight incompatibilities that take time to sort out.

Now if that description didn't leave your head spinning I didn't do my job because standards by committee seem to be written in a somewhat more obtuse language to avoid a lot of ambiguity because it has to go through multiple hands and the details need to be implemented in similar ways in order for things to work. It isn't like internal company documentation that can be sketchy at points because the authoritative reference is the reference implementation, i.e. the product, which is easy to modify before the product is released (and sometimes even after the product is released).

[TadW]

Originally Posted by Namekuseijin

I don't get it. isn't epub simply zipped html and css?

My thoughts exactly when I first heard about ePub. It seems like there is an aweful amount of time spent on schemantics whereas really the main content is just XHTML 1.1.

If you take a closer look you'll see there is more about it. First, ePub has to be supported by a wide range of hardware. That includes old E Ink devices with limited memory and slow CPU. You need to do something about the XHTML file and included static material so that it won't overflow your device's memory. Second, there is the question how to include and present various metadata, how to include inline images, support DRM (some people ask for it...), extend functionality through XML, and support audio/video content.

[Katsunami]

EPUB, SchmEPUB. Blablablabla.



One of the things I hate most in IT or computer-related stuff. Nobody can ever agree, because there's a zillion way of doing things. In the end, we just have a zillion different systems, of which only very few people have any real in-depth knowledge. Then, just before one of those systems can actually become THE real standard, one or another thinks it should be done in yet another way, and it starts all over again.

As I've said in other posts, I'm re-ripping my CD's into FLAC. Some people have asked me why I don't use ALAC or APE or whatever. Why? Easy.

FLAC is free, it's not covered by patents, it has been stable since 2007 (now in 2013, an update has been released to make it easier to compile, using newer compilers), it's crossplatform running basically everywhere, it can be used from the command line or through a GUI, it has good compression, it's supported by quite a lot of hardware, most audio-related software, and it's the default standard to sell lossless music.

Why the hell do we *NEED* anyhting else? FLAC does everything already. Other standards improve only some very infinitesimally small points, while having some great disadvantages to offset those.

For digital music, this is what counts:

Uncompressed: WAV (AIFF for Apple)
Lossless compression: FLAC (ALAC for Apple stuff)
Lossy compression: MP3, Ogg Vorbis for the open-source minded (AAC for Apple stuff)

If you discount Apple, who is almost always different because of just wanting to be different (which is the reason why I avoid buying stuff from them), the only relevant formats are WAV, FLAC, MP3 and Ogg Vorbis. All of the rest is just dabbling in the margins, IMHO.

I am of the opinion that it's the same with EPUB. Compared to AZW and EPUB (and iBooks...) everything else is irrelevant. Instead of screaming for new standards al the time, I think the book industry should follow the music industry's example, and develop EPUB into a solid, stable standard (and ditch the DRM).

[speakingtohe]

I'm of two minds.

Epub as it was 3 years ago seemed to be fine on my old Sony reader. KISS

If nobody tried to make things better we would be still crossing the country in covered wagons with wooden wheels or living in caves.

Helen

[Katsunami]

You are right, but there is a difference in making things better, as opposed to just doing things differently.

Also, I am of the opinion that it is ridiculous to try to have one big giant format for every device. There is nothing wrong with using a perfected version of the current EPUB standard for e-readers only, and develop add-ons to that standard, to be used on tablets and other devices, as is necessary.

[HarryT]

Originally Posted by Katsunami

You are right, but there is a difference in making things better, as opposed to just doing things differently.

Also, I am of the opinion that it is ridiculous to try to have one big giant format for every device. There is nothing wrong with using a perfected version of the current EPUB standard for e-readers only, and develop add-ons to that standard, to be used on tablets and other devices, as is necessary.

Unfortunately the "current standard" (ie ePub 2) lacks features which are essential in some markets. For example, it has no support for vertical writing systems which are essential for languages such as Chinese.

[Katsunami]

Then add those features as options or modules or whatever. IMHO, it's still not necessary to start another all-but-the-kitchen-sink standard from scratch again.

[fjtorres]

Most ebook readers support multiple formats already.
The best do it seamlessly so that the user doesn't need to know what is in the file, just that it is an ebook and it works with their readers.
That is how Nook does it with graphic novels and magazines and how Amazon does it for everything: we techies know that Kindle files can be Topaz, Mobi7, Fixed-Format (pdf), KF8, even audible. Kindle is a brand, not a spec.
All that regular consumers need to know if that it is an ebook that works with Kindle readers and apps. Ditto for Nook. And to an extent Sony and Kobo.

[fjtorres]

Originally Posted by BWinmill

When it comes down to committees, you have to decide what Z is. Since different companies serve different markets, that is a complex task. Once that is done, the members have to decide upon Y. Since each company is serving a different Z they will each see market needs differently, thus have different perspectives on necessary feature sets, which makes deciding upon Y difficult.

Worse, each company has to bear the cost (in code, development time and money, and product maintenance) of supporting everybody else's market ambitions. (If all you want to do is sell travel guides and cookbooks why should you have to bear the costs of supporting phone-home Javascript and textbbook-grade math support?)

When bugs are found in features that don't impact their customers, some players will be inclined to ignore the fixes so that over time there is drift in the implemented products and people who expect that any product supporting the spec will offer the same experience run into all sorts of "minor" inconsitencies and incompatibilities. Grumbling ensues. Everybody loses.

This has happened before (SGML, for one); it likely will happen again, even though you'd think the committee standards crowd would get the message.