(The following represents my evaluation. Although it contains many facts, you may weigh up them differently.)

Why not DocBook?

Some people have asked why I created a new XML format and didn't choose DocBook as the basis for my transformations.

Well, first of all: I don't know any free DocBook tool that produces output that is decent enough for me. Typically the printed output is not very beautiful and many things simply don't work (e.g. formulae). So I felt forced to create transformations by myself anyway.

Nevertheless I could have chosen DocBook as the starting point. I didn't do this because:

DocBook is highly optimised for technical documentation which is a very important but also very narrow field. This is the underlying reason for some of the following points.
DocBook is huge. While tbook has 80 elements, DocBook has almost 400. However many of them deal with extremely specific things (e.g. environment variables), so for general purpose these elements are irrelevant. On the one hand you are not forced to use the entirety of DocBook, on the other hand every effort with DocBook is multiplied by its bigness:
- You (the author) have to get at least an overview of all the DocBook elements.
- The DTD has to be read by the text editor or the transformer every time, which can be annoyingly slow even on modern computers.
- Every transformation tool has to cope with all elements. (Believe me, the 80 tbook elements are hard enough.)

DocBook forces to use deep nesting. While tbook has a rather "flat" structure, DocBook very often makes one or two additional elements necessary. For example, a graphics in DocBook is included with

    <figure label="1.1" float="1">
      <title>The galaxy.</title>
      <mediaobject>
	<imageobject>
	  <imagedata fileref="galaxie.png" format="PNG"/>
	</imageobject>
      </mediaobject>
    </figure>

whereas in tbook you just say

    <figure>
      <graphics file="galaxie" kind="vector"/>
      <caption>The galaxy.</caption>
    </figure>

DocBook's content models are too liberal. Sometimes one gets the impression that you can use any DocBook element within any other DocBook element. Although this is not true of course, I dislike such arbitrary structures. tbook is rather strict and yet it covers most document structures that you can find in books, papers, and theses. This has some advantages:
- It forces you to write a well structured and well ordered document which is a good thing in my opinion (and in your reader's opinion probably).
- It enables XML editors to help you greatly with the input.
- It simplifies the creation of useful tbook tools.
DocBook's arbitrary content models allow for absurd constructs and, even worse, make it impossible to write transformation programs that can guarantee to work. Instead they must hope that you don't use all features of DocBook which is very unfortunate in my opinion.
I miss many things in the DocBook DTD. While it's still not totally clear how math will eventually look like in DocBook, I especially need
- something like the <psfrag> element for neat graphics labels,
- overlay graphics (bitmap+vector),
- the style and class attributes that are extremely practical for Web output,
- a connection to BibTeX files for my literature,
- explicit horizontal lines in tables,
- a formula element with simple non-MathML syntax,
- a <letter> element,
and a couple of further elements and attributes. I could add these elements to DocBook, but this wouldn't be DocBook anymore and therefore existing DocBook tools wouldn't work anyway.
DocBook tries to enforce pure logical markup to its fingertips. I don't think that this is the right way. For large structures like chapters and lists logical markup is a good thing, so tbook uses it, too. However for inline text you may need more control, and thus you need visual markup. For example, if you say in a table caption "certain values are printed in bold face" you want to set them easily and safely to bold face. Or, you may want to print a warning in red, or include a skip between two paragraphs. DocBook intentionally supresses such wishes. But for me it's hard to write real world texts without them. tbook implements visual markup very carefully, and makes use of the lessons we've learned from visual markup in LaTeX.
DocBook's processing expectations often are too unspecific. Two typical examples. DocBook's <computeroutput> element has the following processing expectation: "[...] It’s often presented in a fixed width font." For many people it may be sufficient to assume something, but I as the author want to know such things, so this "often" is too wishy-washy. The same is true for labelling of figures, tables etc. You simply don't know which figure will get which number eventually. So the numbering may be different in different copies of your text which is unacceptable if for example people talk about your text by phone. tbook is rock-solid in this respect.
DocBook's customisation is too difficult. For example if you want to change the main font, for tbook it's sufficient to create a one-line text file in the current directory. Good LaTeX and CSS interfaces make it very simple to customise the layout of tbook documents. In typical DocBook tools such tasks are much more difficult and usually involve to modify style sheets written in an exotic computer language.
And, finally – you can convert tbook to DocBook so that you can use all tools of the DocBook world. Although the transformation exploits DocBook as much as possible, the transformation isn't lossless. (Not surprising after the points before.)

Conclusion

I'd lose credibility if I didn't mention the other side. If your texts don't have a very complex structure (e.g. no formulae, no bibliography, no index) the differences melt down to the non-existence of really nice free DocBook conversion tools. If, additionally, the output quality is not too important, or you are prepared to write your own conversion tools (as some people do), DocBook may well be sufficient for you.

Every tool has its purpose. DocBook's purpose is technical documentation. For example, tbook's manual pages are written in DocBook. I'd have even written tbook's main documentation in DocBook, too, but the Texinfo system turned out to be even better suited for this task.

To sum it up: DocBook for technical documentation and special tasks like manual pages, and tbook for scientific texts. For general texts you may use both, however tbook is simpler and – if you don't want to program yourself – produces nicer output.

Contact

Torsten Bronger, mailto:bronger@physik.rwth-aachen.de. 2003/06/23