Quote:
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).