For a format to be used, it has to be attractive in some form. Markdown is attractive because it's extremely easy to read and write. HTML is attractive because

For a format to be used, it has to be attractive in some form. Markdown is attractive because it's extremely easy to read and write. HTML is attractive because it can be displayed by all web browsers. LaTeX is attractive because it is extremely powerful, has the best math typesetting, and allows for user-defined abstractions. Your format is not easy to read. There is no implementation that displays it. It lacks many advanced features that make it useful, and those features that it does have are rather weird. To evaluate the format, let's consider a couple of texts that could be written, with their unique requirements: - A fantasy novel. The novel may rely on custom fonts, or multi-colored text. Your UBook cannot handle this (but to be fair, neither can Markdown). - A collection of poems. Modern poems can have rather challenging layout requirements, which UBook does not offer (but to be fair, neither does Markdown). - A highschool-level math textbook. This requires good support for math typesetting, figures, and tables. UBook has no clear vision to support math typesetting, e.g. through something like MathJax (to be fair, HTML relies on JavaScript or MathML for this, but some Markdown dialects are math-aware). - A programming book. This requires a form of verbatim input and syntax highlighting. Neither is possible with UBook (to be fair this is a pain in HTML, and only some Markdown dialects are highlighting-aware). - An academic paper. This has domain-specific requirements (e.g. math typesetting, special typesetting for linguistics) and also requires excellent handling of references (HTML: yes, Markdown: no) and footnotes (HTML: no, Markdown: in some dialects). The footnote handling in UBook is not sufficient (for example, it's not possible to reference the same footnote from multiple locations). Of course that are rather demanding examples, and there are plenty of texts that don't need many of these features. What use cases remain? Any text without advanced layout or formatting requirements, and without a need for much structure: wide swaths of literature, and non-demanding technical writing. Is your UBook the best choice for those use cases? Wouldn't it be easier to write it as Markdown, and compile it via HTML to a MOBI or EPUB before deploying? Now that I've looked at the scope of the language, let's look at the finer design decisions of UBook itself. - For example, the whole book has to be in a single file. This makes it unwieldy to write. Adding an "include" feature could help. - All commands except the table commands are terribly short, which makes them hard to remember. This makes sense for often-used commands, but seldom-used commands can be longer. for example, "$A" is not as memorable as "$AUTHOR". - UBook considers a line break to be a paragraph separator. This is bad for two reasons: (1) Advanced users with version control might want to split paragraphs onto multiple lines for better "diff"s. (2) Line breaks and paragraphs are semantically different, and HTML, Markdown, and LaTeX include ways to output a line break without starting a new paragraph. - The "$E" command (empty line) makes no sense whatsoever. No other format I know supports such a feature (although it can be faked with line breaks). - Inventing a new link syntax is highly unnecessary. The one used by Markdown is pretty good, and allows us to refer to a link target via a shorthand: Some Text [inline](link) or [keyword] link which can be used with [other text][keyword] as well [keyword]: some link - For the given use cases, the index functionality is unnecessary: A text complex enough to require a glossary will likely have more requirements that are not met by UBook, e.g. a way to link to a glossary entry in the text. - Using the same character to introduce a block-level command and a headline is very confusing. It might be better to use explicit headline commands like "$SUBSECTION" and "$CHAPTER" (compare LaTeX). - The format appears to lack composability. E.g. it's not obvious whether a block-level image can be included in a quote. It does not seem like a table cell could contain another table. It doesn't seem like a list item could contain multiple paragraphs (and if it does, where does the item end and normal text start?). Of course, this makes it very easy to parse (which is unnecessary, given today's state of parsing technology). - The fact that the three-character sequence "$Q " has to be included before each quoted line is a WTF in itself (and a misfeature shared similarly by Markdown). This is undue burden on the author as he has to type it, and undue burden on the parser as this makes the language non-context free. Using a quotation-start and quotation-end marker would be much better for all involved. - I fail to see the difference between horizontal lines and "$S" section separators. - The "$END" is a horrible anachronism and should die. The end of file is good enough to denote the end. Requiring such a token means that all your examples on the page won't work, and that many authors would be surprised when their magnus opus doesn't display. Your UBook in its current state is not a viable markup language. It has a few interesting concepts (indices, footnotes, book-orientation, table-cell merging), but isn't really attractive when we have so many other possible languages. Before redesigning the language, take a look at AsciiDoc, MultiMarkdown, and older markup languages like LaTeX, Perl's POD, and troff. Learn from their mistakes instead of repeating them! Remember that many restrictions of these formats do not apply to you! UBook as a distribution format is unlikely to ever become a viable option even though it has some nice features like excerpts (I would like to see the ebook format market to be disrupted, but UBook won't manage that). It would be better to de-emphasize this part of UBook, and focus on it as an authoring tool that can compile to various ebook formats.