Die zentrale Struktur in DocBook ist das Buch, aber auch ganze Sätze von Büchern, einzelne Artikel, API-Referenzen, UNIX-Manpages und FAQs lassen sich in DocBook schreiben.
Die Elemente der DocBook-DTD lassen sich grob in drei Gruppen aufteilen: Metainformationen, Hierarchie und Information Pool. Auf die drei Gruppen verstreut sind eine Vielzahl von Elementen für das Markup technischer Konzepte. Für eine detailierte Beschreibung der mehr als 300 Elemente von DocBook sei auf [DocBookReference] verwiesen. An dieser Stelle soll ein grober Überblick genügen.
Die Hierarchie-Elemente ermöglichen die grobe Strukturierung und Gliederung eines Dokuments. Dazu gehören die typischen Root-Elementen book und article. preface, chapter, appendix, bibliography, glossary, index und weitere unterteilen ein Dokument in grobe Abschnitte. Diese lassen sich jeweils durch verschachtelte section-Elemente oder durch die nach Tiefe nummerierten sect1 bis sect5 feiner unterteilen. Für Manpage-Einträge ist das refentry-Element mit seinen Kindelementen vorgesehen. Für FAQs gibt es das qandaset-Element. Neben diesen gibt es etwa 45 weitere Hierarchie-Elemente.
Beispiel 7. Hierarchie-Elemente in einem Buch
<book lang="de">
<bookinfo>
<title>Ein Beispiel-Buch</title>
<author>
<firstname>Richard</firstname><surname>Cyganiak</surname>
</author>
<copyright>
<year>2002</year><holder>Freie Universität Berlin</holder>
</copyright>
</bookinfo>
<preface><title>Einleitung</title>
<para>...</para>
</preface>
<chapter><title>Das erste Kapitel</title>
<para>...</para>
</chapter>
<!-- ... -->
<appendix><title>Ein Anhang</title>
<para>...</para>
</appendix>
</book>
Die DocBook-DTD enthält über 100 Elemente zur Auszeichnung von Metainformationen. Beispiele sind title, author, pubdate, revhistory, contractsponsor, legalnotice und issuenum.
In DocBook 4.2 wurde eine Harmonisierung mit dem Dublin Core Standard vorgenommen. Die Elemente heißen in DocBook teilweise anders, haben aber äquivalente Semantik ([DocBook4.2#DC]).
Fast alle Hierarchie-Elemente können ein info-Element als Kind enthalten, also book enthält bookinfo, section enthält sectioninfo usw. Sie dienen als Container für Metainformationen. Das bedeutet, dass nicht nur das Root-Element Metainformationen haben kann. Wenn beispielsweise ein Kapitel von einem anderen Autor geschrieben wurde, so lässt sich dies kenntlich machen.
Alle Elemente für Metainformationen können auch im bibliography-Abschnitt verwendet werden, um Literaturangaben auszuzeichnen.
Beispiel 8. Metadaten eines Buches
<bookinfo>
<title>User's Guide for the DocBook DTD</title>
<authorgroup>
<author><firstname>Terry</firstname><surname>Allen</surname></author>
<author><firstname>Eve</firstname><surname>Maler</surname>
<affiliation><orgname>Arbortext, Inc.</orgname></affiliation>
</author>
<author><firstname>Norman</firstname><surname>Walsh</surname>
<affiliation><orgname>Arbortext, Inc.</orgname></affiliation>
</author>
</authorgroup>
<edition>User's Guide version 1.0 for DocBook V3.0</edition>
<pubdate>1997</pubdate>
<copyright>
<year>1992</year>
<year>1993</year>
<year>1994</year>
<year>1995</year>
<year>1996</year>
<year>1997</year>
<holder>
Arbortext, Inc., HaL Computer Systems, Inc.,
Fujitsu Software Corp., and O'Reilly & Associates, Inc.
</holder>
</copyright>
<legalnotice>
<para>
Permission to use, copy, modify and distribute
the DocBook DTD and its accompanying documentation for any purpose and
without fee is hereby granted in perpetuity, provided that the above
copyright notice and this paragraph appear in all copies.
</para>
</legalnotice>
<legalnotice>
<para>
The copyright holders make no representation about the suitability of
this DTD for any purpose. It is provided
<quote>as is</quote> without expressed
or implied warranty. If you modify the DocBook DTD in any way,
except for declaring and referencing additional general entities
and declaring additional notations, identify your DTD as a variant
of DocBook.
</para>
</legalnotice>
</bookinfo>
Natürlich muss es auch Elemente geben, in denen der eigentliche Inhalt des Dokuments steckt: Absätze, Listen, Tabellen, Bilder. Das wichtigste dieser Elemente ist para. Es enthält einen Absatz. Für Tabellen wird das CALS-Modell verwendet. Es entstand beim US-Verteidigungsministerium und ist in der SGML-Welt recht verbreitet.
Beispiel 9. Eine Tabelle nach dem CALS-Modell
<informaltable frame='none'>
<tgroup cols='2'>
<colspec colwidth='0.5in'/>
<colspec colwidth='0.5in'/>
<tbody>
<row><entry>1</entry><entry>1</entry></row>
<row><entry>2</entry><entry>4</entry></row>
<row><entry>3</entry><entry>9</entry></row>
</tbody>
</tgroup>
</informaltable>
Die oben genannten Inhaltstypen sind im Prinzip aus HTML bekannt. DocBook hat noch etwa 110 weitere Elemente für Inhalte. Der Großteil dient entweder dem Markup technischer Begriffe, oder bezeichnet bestimmte Konzepte aus dem Bereich der Buchformatierung wie footnote, indexterm, citation.
Da DocBook für technische Dokumention entwickelt wurde, gibt es natürlich eine große Anzahl von Elementen zur Auszeichnung technischer Konzepte. Zu den abgedeckten Bereichen gehören Benutzerinterfaces (keycombo, mousebutton, menuchoice, guiicon), Programmierung (methodname, ooexception, returnvalue, constructorsynopsis), Betriebssysteme (prompt, command, errorcode, manvolnum, filename) und Hardware (invpartnumber, hardware). Natürlich ist auch ein sgmltag-Element vorhanden. Laut Dokumentation soll es auch für XML-Konstrukte verwendet werden. Spezielles Markup für bestimmte XML-Konstrukte ist für eine zukünftige Version des Standards vorgesehen.
Beispiel 10. Markup einer Benutzereingabe
<para>
Und wenn nichts mehr hilft, drücken Sie
<keycombo action="simul">
<keycap>Strg</keycap>
<keycap>Alt</keycap>
<keycap>Entf</keycap>
</keycombo>.
</para>
Beispiel 11. Markup einer Java-Methodensignatur
<!--
public Wumpus getWumpus(int id)
throws NoSuchWumpusException;
-->
<methodsynopsis>
<modifier>public</modifier>
<type>Wumpus</type>
<methodname>getWumpus</methodname>
<methodparam>
<type>int</type><parameter>id</parameter>
</methodparam>
<exceptionname>NoSuchWumpusException</exceptionname>
</methodsynopsis>
Für Fälle, in denen der semantische Reichtum des vorhandene Markups immer noch nicht genügt, ist das role-Attribut vorgesehen. Es ist auf jedem Element vorhanden. Der DocBook-Standard gibt keine möglichen Werte vor, sondern überlässt die Wahl dem Nutzer. Dadurch lassen sich Subklassen aller Elemente bilden. Weiterverarbeitende Tools können das Element dann je nach Subklasse unterschiedlich behandeln. Dieser Mechanismus ähnelt dem class-Attribut in HTML und XHTML.