DocBook V5.0 represents a major step forward for DocBook. The differences between DocBook 4.x and V5.0 are quite radical in some aspects, but the basic idea behind DocBook is still the same, and almost all element names are unchanged. Because of this it is very easy to become familiar with DocBook V5.0 if you know any previous version of DocBook.
In V5.0, DocBook has been rewritten as a native RELAX NG grammar (“An introduction to the RELAX NG schema language” [RNG-Intro] is an excellent introduction to the grammar). The objectives were to produce a schema that:
“Feels like” DocBook. Most existing documents should still be valid or it should be possible to transform them in simple, mechanical ways into valid documents.
Enforces as many constraints as possible in the schema. Some additional constraints are expressed with Schematron rules.
Cleans up the content models.
Gives users the flexibility to extend or subset the schema in an easy and straightforward way.
Can be used to generate XML DTD and W3C XML Schema versions of DocBook.
Under the ordinary operating rules of DocBook evolution, the only backward-incompatible changes that could be made in DocBook V5.0 were those announced in DocBook V4.0. In light of the fact that this is a complete rewrite, the Technical Committee gave itself the freedom to make “unannounced” backward-incompatible changes for this one release.
A number of elements have been removed from DocBook. Some have been replaced by simpler, more versatile alternatives. Others have been removed because they were no longer needed, and still others have been renamed. Table 1-1 lists the elements that have been renamed for DocBook V5.0.
Table 1-1. Renamed elements
|Old name||New name|
The following elements were removed from DocBook
V5.0 without direct replacements:
you use one or more of these elements, Table 1-2
contains suggestions for recoding them in DocBook
Table 1-2. Recommended mapping for removed elements
|Old name||Recommended mapping|
|No longer needed. The current processing model for
In DocBook 4.x the
id attribute is used to assign a unique
identifier to an element. In DocBook V5.0 this
attribute is renamed
its usage is consistent with xml:id Version 1.0
[XML-ID], a W3C Recommendation.
<section id="dir"> <title>DIR command</title> <para>...</para> </section> <section id="ls"> <title>LS command</title> <para>This command is a synonym for <link linkend="dir"><command>DIR</command></link> command. </para> </section>
In DocBook V5.0, this can be written as the following:
<section xml:id="dir"> <title>DIR command</title> <para>...</para> </section> <section xml:id="ls"> <title>LS command</title> <para>This command is a synonym for <command linkend="dir">DIR</command> command. </para> </section>
In addition, the
attribute from the XLink namespace was added to the same set of inline
following example shows how you can use
href. Note that you need to declare the
XLink namespace in your document instance to use this
<article xmlns="http://docbook.org/ns/docbook" xmlns:xl="http://www.w3.org/1999/xlink" version="5.0"> <title>Test article</title> <para> <application xl:href="http://www.gnu.org/software/emacs/">Emacs</application> is my favourite text editor.</para> ... </article>
DocBook versions earlier than DocBook
V5.0 use unique elements for block information. For
book element would contain a
bookinfo element. This was done to support
different content models for different block elements. DTDs only allow
one content model for each element, so a different element name was
required for each block’s information element.
RELAX NG does not have this limitation. An element can have a
different content model in different contexts. Therefore, the array of
info elements (
bookinfo, etc.) has been replaced with
DocBook V5.0 requires the
title attribute on large block elements
article. The written specification for
earlier versions of DocBook noted this, but the DTD could not enforce
this constraint. With RELAX NG, this constraint can now be enforced in
DocBook V5.0 no longer requires a Document
Type Declaration. However, because processors may need to know the
version of an instance, DocBook V5.0 has added the
version attribute, which must
appear on the root element of a DocBook document. The
version attribute may also appear on other
elements, and mixing of versions is allowed.
DocBook V5.0 enforces co-constraints
such as the constraint that the
otherclass attribute on
biblioid may appear if, and only if, the
class attribute exists and
has the value
DocBook V5.0 uses some data
types; for example, the
tgroup is defined as a positive
integer. In some cases, the data type for a particular value may
constrain it further than that value was constrained in prior
Prior to DocBook V5.0, the markup for
tables of contents was clumsy and difficult to use. Although nearly
all tables of contents are generated automatically, there are still
cases where a table may need to be created or edited manually.
Therefore, DocBook V5.0 introduces a simpler,
recursive structure. See the
pages for details and an example.
DocBook V5.0 uses rule-based
validation for certain constraints using Schematron. These
constraints, such as the requirement that the root element of a
document have a
version attribute, are easier to
express in a rule-based language than in a schema language, even one
as flexible as RELAX NG.