<chapter id=over01>
<title>DocBook Introduction and Background</title>
<para>This chapter offers a high-level overview of DocBook's purpose and scope
and describes its revision and maintenance policy.</para>
<sect1>
<title>Purpose and Scope</title>
<para>The DocBook DTD defines structural and content-based SGML markup for
computer documentation, with a primary emphasis on software documentation
and related classes of technical documents. Its main high-level hierarchical
structures are for books, reference entries (for example, <quote>man pages
</quote>), and articles. It is maintained by the Davenport Group (about which
see the Davenport archive at &dav-archive;).</para>
<para>DocBook was originally designed to filter existing software documentation,
typically marked up with <literal>troff</literal>, into SGML so that it could
then be interchanged among business partners. As such, it describes the structures
that many producers of software documentation have encountered in converting
large bodies of such material. Over time, DocBook's design has responded to
direct SGML writing and publishing needs as well, and it has begun to be supported
in off-the-shelf versions of many SGML tools so that it can be used easily
from writing through processing and delivery. Dozens of organizations use
DocBook for millions of pages of documentation.</para>
<para>Because DocBook is a large and robust DTD, it is quite common for organizations
to use only a subset of its markup model. Similarly, because individual organizations
often have specific needs that an industry DTD cannot reflect, many users
also extend DocBook's markup model. In response, DocBook has been made highly
modular and parameterized so that users can create <quote>customization layers
</quote> containing their unique DTD specifications while using <quote>real
DocBook</quote> wherever they have no need to make changes.</para>
<para>We expect that DocBook will evolve as it is applied to more documents,
as more SGML tools come into use, and as users gain more experience in working
with it. We are interested in your use of the DocBook DTD and welcome your
comments. We are committed to reviewing customizations and evaluating their
features for inclusion in future DocBook releases.</para>
</sect1>
<sect1 id="rev-policy">
<title>Revision and Maintenance Policy</title>
<para>A <firstterm>backwards-incompatible change</firstterm> is a change to
any <literal>ELEMENT</literal> or <literal>ATTLIST</literal> declaration (or
any parameter entity or other construct that such a declaration references,
directly or indirectly) that results in a restriction of markup choices, such
that some or all document instances conforming to previous versions might
not conform to the new version.</para>
<para>The Davenport Group's policy is not to make backwards-incompatible changes
in minor revisions (<replaceable>x</replaceable>.<replaceable>n</replaceable>
to <replaceable>x</replaceable>.<replaceable>n</replaceable>+1); such changes
shall be made only in major revisions (<replaceable>x</replaceable>.<replaceable>
n</replaceable> to <replaceable>y</replaceable>.0). There will be no more
than two major revisions of DocBook per year, and in practice there will probably
be fewer than two. The Davenport Group will always give warning of backwards-incompatible
changes at least six months in advance.</para>
<para>Accordingly, some future backwards-incompatible changes are signaled
in <quote>FUTURE USE</quote> comments in the DTD. The future version in which
the change will take place is indicated in each comment.</para>
<note>
<title>Note</title>
<para>Changes to parameter entities that affect the DTD's customizability&mdash;for
example, changes to parameter entity names&mdash;are not restricted to major
revisions. Thus, DocBook customizers should review each new minor revision
and may need to make changes to their customization layers.</para>
</note>
<para>See <xref linkend="change-list"> for lists of changes made in recent
and planned versions of DocBook.</para>
</sect1>
</chapter>