|
To re-iterate my points which you haven't answered in your rather rambling response:
1) Light markup has minimal features. If you add more features your viewer apps will become more complex anyway. That negates your viewer argument. Heavy markup is heavy for a reason, it supports features. A design philosophy that limits features in order to improve program simplicity is the wrong approach in these times of ever increasing CPU power.
2) If authors use a GUI to generate ebooks, then they don't care about the markup, which then negates your argument for lightweight markup from the perspective of authors.
3) Lightweight markup is suitable for people who digitize books (like p.g.) but not for people who create books, since people who digitize/convert books typically don't care about advanced features, while people who create them do.
Some new points:
1) If you aren't open sourcing your code then good bye and good luck. All you're doing then is defining a specification. Any 10 year old that spends a week thinking about the requirements for an ebook format could do that.
2) Considering that you are designing a limited specification with closed source authoring/viewing software support for changes to that format (which will have to be made over time) will be spotty at best.
Finally:
When it comes to designing format converters, the key is the output format.
If you choose an output format that is a superset of all input formats you might consider, it is then possible to use the converter to convert all input formats to a single output format. You do this by using a object model internally in the converter software, with plugins for input formats. And it them becomes easy to output to different formats using the object model.
Starting with an output format that is more limited than possible input formats is simply ass-backwards. As I said before zml *might* be a good idea for conversion of txt files for p.g. but little else. And without an opensource converter from zml to html it is emphatically not a good idea.
|