This document has been placed in the public domain.
This document describes the XML data structure of Docutils documents:
the relationships and semantics of elements and attributes.
The Docutils document structure is formally defined by the
Docutils Generic XML document type definition (DTD) docutils.dtd,
which is the definitive source for details of element structural relationships.
It should be used in conjunction with the description of the semantics of
the elements, attributes, and parameter entities in this document.
The reader is assumed to have some familiarity with XML or SGML,
and an understanding of the data structure meaning of "tree".
For a list of introductory articles, see, e.g.,
Introducing the Extensible Markup Language (XML).
Docutils implements the Document tree data structure in the Python
module docutils.nodes. For details, see its internal API documentation
("docstrings") and the source nodes.py.
The Docutils document model uses strict element content models.
Below is a simplified diagram of the hierarchy of elements in the
Docutils document tree structure.
An element may contain elements immediately below it in the diagram.
Element types in square brackets indicate recursive or one-to-many
relationships: structural elements (sections) may contain sub-sections,
some body elements may contain other body elements, etc.
The element reference details valid parents and children
for each element.
Every element has a unique structure and semantics, but elements may be
classified into general categories according to their place and role in
the document. Some elements belong to more than one category.
Alternatively, we may classify elements by their content model:
Structural elements group other elements to provide a document structure.
They are child elements of the root element or other structural
elements. Structural elements may contain specific structural elements,
structural subelements, or body elements.
Structural subelements are child elements of the root element or
specific structural elements. Their content model varies
(see the respective element reference section for details).
Bibliographic elements store document meta-data like title or author.
They are child elements of <docinfo>.
Their content model varies (see the respective element reference section).
Body elements are children of the root element, structural elements,
or compound body elements.
Simple body elements may contain text and inline elements
or text data only (see the respective element reference section).
Compound body elements may contain body subelements or further
body elements.
Body subelements always occur within specific parent elements
(e.g. <bullet_list> contains <list_item>), never at the
body element level (beside paragraphs, etc.).
Body subelements may be compound elements (containing body elements or
further body subelements) or simple elements.
Inline elements are contained within simple body elements or other
inline elements.
Inline elements are simple elements: All inline elements may contain
text data, most inline elements may also contain further inline elements.
Each element in the Docutils Generic DTD is described in its own
section below. Each section contains the following items:
Summary description (up to two sentences).
Details (of element relationships and semantics):
Category:
One or more references to the element categories in the
Element Hierarchy above. Some elements belong to more than one
category.
Analogues:
Analogous elements in well-known document
models such as HTML [html.spec] or DocBook [tdg5.1].
Describes similarities and differences.
Processing:
Formatting or rendering recommendations for the element.
Parents:
Elements which may contain the element.
Children:
Elements which may occur within the element.
Optionally followed by the formal XML content model from the
Docutils Generic DTD.
Attributes:
XML Attributes that are defined for this element.
Parameter Entities:
Parameter entities which directly or indirectly include the element
(if applicable and not already implied by the element category).
Additional free text description and explanations (optional).
Examples: reStructuredText examples are shown along with
fragments of the document trees resulting from parsing.
Pseudo-XML is used to display the results of parsing and processing.
The <abbreviation> element is an inline element representing an
abbreviation, a shortened or contracted form of a word or phrase
used to represent the whole.
<abbreviation> is analogous to the DocBook <abbrev> element.
The HTML <abbr> element is used for both, abbreviations
and acronyms.
Processing:
May be used to semantically mark the presence of an
abbreviation in the text for styling or scripting purposes.
Writers may ignore the element and just render its contents.
Parents:
all elements employing %text.model in their content models
<acronym> is analogous to the DocBook <acronym> element.
The HTML <abbr> element is used for both, abbreviations
and acronyms.
Processing:
May be used to semantically mark the presence of an
acronym in the text for styling or scripting purposes.
Writers may ignore the element and just render its contents.
Parents:
all elements employing %text.model in their content models
The <address> element holds the surface mailing address information
for the author(s) (individual or group) of the document, or a third-party
contact address.
The generic <admonition> has no direct analogues in common DTDs.
It can be emulated with primitives and type effects.
The specific admonitions <caution>, <note>,
<tip>, and <warning> are analogous to the
respective DocBook elements.
Processing:
Rendered distinctly (inset and/or in a box, etc.).
<document ids="document-title" names="document title">
<title>
Document Title
<docinfo>
<authors>
<author>
J. Random Hacker
<author>
Jane Doe
In reStructuredText, multiple author's names are separated with
semicolons (";") or commas (","); semicolons take precedence.
There is currently no way to represent the author's organization,
address, or contact in a reStructuredText "Authors" field.
See <docinfo> for a more complete example, including processing
context.
The <bullet_list> element contains <list_item> elements which are
uniformly marked with bullets. Bullets are typically simple dingbats
(symbols) such as circles and squares.
The <caution> element is a specific admonition, a distinctive and
self-contained notice. See also the generic <admonition> and the
other specific admonition elements.
The <classifier> element contains the classification or type
of the <term> being defined in a <definition_list>.
For example, it can be used to indicate the type of a variable.
<definition_list>
<definition_list_item>
<term>
name
<classifier>
string
<definition>
<paragraph>
Customer name.
<definition_list_item>
<term>
i
<classifier>
int
<definition>
<paragraph>
Temporary index variable.
The <compound> element has no direct analogues in common DTDs.
In HTML, it can be emulated with <div> and CSS styling. [4]
Processing:
Typically rendered as multiple distinct text blocks, with
the possibility of variations to emphasize their logical
unity (cf. the "compound" directive).
.. compound::
The 'rm' command is very dangerous. If you are logged
in as root and enter ::
cd /
rm -rf *
you will erase the entire contents of your file system.
<compound>
<paragraph>
The 'rm' command is very dangerous. If you are logged
in as root and enter
<literal_block xml:space="preserve">
cd /
rm -rf *
<paragraph>
you will erase the entire contents of your file system.
The <contact> element holds contact information for the author
(individual or group) of the document, or a third-party contact.
It is typically used for an email or web address.
<document ids="document-title" names="document title">
<title>
Document Title
<docinfo>
<copyright>
This document has been placed in the public domain.
See <docinfo> for a more complete example,
including processing context.
The <decoration> element is a container for <header> and <footer>
elements and potential future extensions. These elements are used for
notes, time/datestamp, processing information, etc.
The decorative elements<header> and/or <footer>.
Although the content model doesn't specifically require
contents, no empty <decoration> elements are ever created.
The <definition_list> element contains a list of terms and their
definitions. It can be used for glossaries or dictionaries, to
describe or classify things, for dialogues, or to itemize subtopics.
<definition_list>
<definition_list_item>
<term>
Term
<definition>
<paragraph>
Definition.
<definition_list_item>
<term>
Term
<classifier>
classifier
<definition>
<paragraph>
The ' : ' indicates a classifier in
definition list item terms only.
Tyrannosaurus Rex : carnivore
Big and scary; the "Tyrant King".
Brontosaurus : herbivore
..
All brontosauruses are thin at one end,
much much thicker in the middle
and then thin again at the far end.
-- Anne Elk (Miss)
<definition_list>
<definition_list_item>
<term>
Tyrannosaurus Rex
<classifier>
carnivore
<definition>
<paragraph>
Big and scary; the "Tyrant King".
<definition_list_item>
<term>
Brontosaurus
<classifier>
herbivore
<definition>
<comment xml:space="preserve">
<block_quote>
<paragraph>
All brontosauruses are thin at one end,
much much thicker in the middle
and then thin again at the far end.
<attribution>
Anne Elk (Miss)
The <docinfo> element is a container for displayed document bibliographic
data, or meta-data (data about the document). It corresponds to the
front matter of a book, such as the title page and copyright page.
There are no directly analogous HTML or DocBook elements.
The DocBook <info> element is related but ususally
suppressed in the output.
Processing:
The <docinfo> element may be rendered as a two-column table or
in other styles. It may even be invisible or omitted from the
processed output. Meta-data may be extracted from <docinfo>
children; for example, HTML <meta> tags may be constructed.
See also the <meta> element (for hidden meta-data).
Examples
Bibliographic data is represented in reStructuredText by a
field list as the first visible element of a
document (after optional document title and subtitle).
The field list is transformed into a <docinfo> element and its children
by the DocInfo transform. [5]
Source:
Docinfo Example
===============
:Author: J. Random Hacker
:Contact: jrh@example.com
:Date: 2002-08-18
:Status: Work In Progress
:Version: 1
:Filename: $RCSfile$
:Copyright: This document has been placed in the public domain.
<document ids="docinfo-example" names="docinfo example">
<title>
Docinfo Example
<docinfo>
<author>
J. Random Hacker
<contact>
<reference refuri="mailto:jrh@example.com">
jrh@example.com
<date>
2002-08-18
<status>
Work In Progress
<version>
1
<field classes="filename">
<field_name>
Filename
<field_body>
<paragraph>
doctree.rst
<copyright>
This document has been placed in the public domain.
Note that "Filename" is a non-standard <docinfo> field, so becomes a
generic field element. Also note that the "RCSfile" keyword
syntax has been stripped from the "Filename" data.
<doctest_block> is analogous to the HTML <pre> element
and the DocBook <programlisting> and <screen> elements.
Processing:
As with <literal_block>, <doctest_block> elements are
typically rendered in a monospaced typeface. It is crucial
that all whitespace and line breaks are preserved in the
rendered form.
<document> is the direct or indirect ancestor of every other element in
the tree. It encloses the entire document tree. It is the starting
point for a document.
Depending on the source of the data and the stage of processing,
the <document> may not initially contain a <title>.
A document title is not directly representable in reStructuredText.
Instead, the DocTitle transform may promote a lone top-level section
title to become the document <title>, and similarly a lone
second-level (sub)section's title to become the document <subtitle>.
The contents of "<decoration>" may be specified in a document,
constructed programmatically, or both.
<entry> is analogous to the DocBook <entry> element.
HTML differentiates between header entries <td>
and data entries <td>.
Processing:
Render content in a table cell. The morecols and morerows
attributes may be used to define an entry spanning several
table cells.
See entry in the Exchange Table Model for details.
<field_list> is analogue to the HTML <dl> element.
Processing:
A <field_list> is typically rendered as a two-column list,
where the first column contains "labels" (usually with a
colon suffix). However, field lists are often used for
extension syntax or special processing. Such structures do
not survive as field lists to be rendered.
Field lists are often meant for further processing.
In reStructuredText, field lists are used to represent bibliographic
fields (contents of the <docinfo> element) and directive options.
The <footer> element is a container element whose contents are meant
to appear at the bottom of a web page, or repeated at the bottom of
every printed page.
<footer> is analogous to the HTML <footer> element. There
are no direct analogies to <footer> in HTML4 or DocBook.
Equivalents are typically constructed from primitives and/or
generated by the processing system.
The <footer> element may contain processing information (datestamp, a
link to Docutils, etc.) as well as custom content.
Examples
A document may get a <footer> decoration even without use of the
reStructuredText "footer" directive:
A paragraph.
Complete pseudo-XML result after parsing and applying transforms,
assuming that the datestamp command-line option or configuration
setting has been supplied:
<document>
<decoration>
<footer>
<paragraph>
Generated on: 2002-08-20.
<paragraph>
A paragraph.
The <footnote> element is used for labelled notes that provide
additional context to a passage of text (footnotes or endnotes).
The corresponding footnote mark in running text is set by the
<footnote_reference> element.
The DPub ARIA role "doc-footnote" may be used to mark a
(conforming) HTML emulation as "ancillary information,
such as a citation or commentary, that provides additional
context to a referenced passage of text".
For collections of notes that occur at the end of a section,
the DPub ARIA role "doc-endnotes" is more appropriate.
The <footnote_reference> element resembles
the DocBook <footnoteref> element or
the LaTeX \footnotemark command.
There is no equivalent in HTML. The <a> element can be used
to provide a link to the corresponding footnote.
Processing:
A <footnote_reference> should generate a mark matching the
<label> of the referenced footnote. The mark is
typically formatted as superscript or enclosed in square
brackets.
Parents:
all elements employing %text.model in their content models
<paragraph>
<footnote_reference auto="1" ids="id1">
is an auto-numbered footnote reference.
<footnote auto="1" ids="id3">
<paragraph>
First auto-numbered footnote.
The references.Footnotes Docutils transform resolves this to:
<paragraph>
<footnote_reference auto="1" ids="id1" refid="id2">
1
is an auto-numbered footnote reference.
<footnote auto="1" backrefs="id1" ids="id2" names="1">
<label>
1
<paragraph>
First auto-numbered footnote.
Docutils wraps <generated> elements around text that is inserted
(generated) by Docutils; i.e., text that was not in the document,
like section numbers inserted by the "sectnum" directive.
<header> is analogous to the HTML <header> element.
There are no direct analogies to <header> in HTML4 or DocBook.
Equivalents are typically constructed from primitives and/or
generated by the processing system.
The specified image is included into the output document.
Depending on the output format, this is done by referring to
the image URI or by embedding the image data.
It is up to the author to ensure compatibility of the image data format
with the output format or user agent (LaTeX engine, HTML browser, ...).
The reStructuredText Directives documentation contains a non exhaustive
table of compatible image formats.
<important>
<bullet_list>
<list_item>
<paragraph>
Wash behind your ears.
<list_item>
<paragraph>
Clean up your room.
<list_item>
<paragraph>
Back up your data.
<inline> is analogous to the HTML <span> element and the
DocBook <phrase> element.
Processing:
Writers typically pass the classes attribute to the output
document and leave styling to the backend or a custom
stylesheet. They may also process the classes attribute
and convert the <inline> element to a specific element or
render the content distinctly for specific class values.
Moreover, writers may ignore the element and just render
the content.
Parents:
all elements employing %text.model in their content models
<line_block> has no direct analogues in common DTDs.
Is is related to the DocBook <literallayout> element,
however <literallayout> is a verbatim environment which
directly contains text.
Processing:
Each <line> should begin a new vertical block,
without markers or additional spacing.
Nested <line_blocks> should be indented.
Take it away, Eric the Orchestra Leader!
| A one, two, a one two three four
|
| Half a bee, philosophically,
| must, *ipso facto*, half not be.
| But half the bee has got to be,
| *vis a vis* its entity. D'you see?
|
| But can a bee be said to be
| or not to be an entire bee,
| when half the bee is not a bee,
| due to some ancient injury?
|
| Singing...
<paragraph>
Take it away, Eric the Orchestra Leader!
<line_block>
<line>
A one, two, a one two three four
<line>
<line>
Half a bee, philosophically,
<line_block>
<line>
must,
<emphasis>
ipso facto
, half not be.
<line>
But half the bee has got to be,
<line_block>
<line>
<emphasis>
vis a vis
its entity. D'you see?
<line>
<line>
But can a bee be said to be
<line_block>
<line>
or not to be an entire bee,
<line_block>
<line>
when half the bee is not a bee,
<line_block>
<line>
due to some ancient injury?
<line>
<line>
Singing...
<literal_block> is analogous to the HTML <pre> element
and to the DocBook <programlisting> and <screen> elements.
Processing:
<literal_block> elements are typically rendered in a
monospaced typeface. It is crucial that all whitespace and
line breaks are preserved in the rendered form.
<literal_block> elements are commonly used for program listings and
interactive computer sessions.
See <line_block> for an alternative useful for verse and addresses.
<math_block> is analogous to a HTML/MathML <math> element
displayed as block-level element or a LaTeX equation*
environment.
Processing:
Rendered in a block as mathematical notation, typically
centered or with indentation
If the output format does not support math typesetting,
the content may be inserted verbatim.
<option_argument> has no direct analogues in common DTDs.
Processing:
The value of the "delimiter" attribute is prefixed to the
<option_argument>, separating it from its
<option_string> or a preceding <option_argument>.
The <option_argument> text is typically rendered in a
monospaced typeface, possibly italicized or otherwise
altered to indicate its placeholder nature.
<option_list> has no direct analogues in common DTDs.
It can be emulated with primitives such as tables.
Processing:
An <option_list> is typically rendered as a two-column list,
where the first column contains option strings and
arguments, and the second column contains descriptions.
The reStructuredText parser marks ambiguous or invalid inline syntax as
<problematic> and adds a reference to the associated <system_message>.
The behaviour can be configured with the report_level setting.
The following paragraph contains unbalanced inline markup:
<revision> is similar to (but simpler than) the
DocBook <revision> element. It closely matches the
DocBook <revnumber> element, but in a simpler context.
Processing:
Often used with the RCS/CVS keyword "Revision".
See <docinfo>.
rubric n. 1. a title, heading, or the like, in a manuscript,
book, statute, etc., written or printed in red or otherwise
distinguished from the rest of the text. ...
—Random House Webster's College Dictionary, 1991
A rubric is like an informal heading that doesn't correspond to the
document's structure.
The Docutils document model uses a simple, recursive model for section
structure. A <document> nodeelements.
Sections in turn may contain other <section> elements, without limit.
The level (depth) of a section element is determined from its physical
nesting level.
Paragraphs and other body elements may occur before a <section>,
but not after it.
Examples
reStructuredText does not impose a fixed number and order of section
title adornment styles. The order enforced will be the order as
encountered.
Title 1
=======
Paragraph 1.
Title 2
-------
Paragraph 2.
Title 3
=======
Paragraph 3.
Title 4
-------
Paragraph 4.
Sidebars are like miniature, parallel documents that occur inside other
documents, providing related or reference material.
Their content is outside of the flow of the document's main text.
<sidebar> is analogous to the DocBook <sidebar> element and
the HTML <aside> element.
Processing:
A <sidebar> element should be set off from the rest of the
document somehow, typically with a border. Sidebars
typically "float" to the side of the page and the document's
main text flows around them.
<sidebar> elements begin with optional
<title> and <subtitle> and contain
body elements and <topic> elements.
There must not be a <subtitle> without title.
The <sidebar> element is a non-recursive <section>-like construct.
<sidebar> elements cannot nest inside body elements, so you can't have a
<sidebar> inside a <table> or a list, or inside another <sidebar>
or <topic>.
<document ids="title" names="title">
<title>
Title
<subtitle ids="subtitle" names="subtitle">
Subtitle
<paragraph>
A paragraph.
Note how two section levels have collapsed, promoting their titles to
become the document's title and subtitle. Since there is only one
structural element (document), the subsection's ids and names
attributes are stored in the <subtitle> element.
<tgroup> is analogous to the DocBook <tgroup> element.
There is no corresponding HTML element (the <colgroup>
element has a different purpose and semantics).
One or more <colspec> elements, followed by an optional
<thead> and a <tbody> (cf. the %tbl.tgroup.mdl
parameter entity).
The number of <colspec>s, must not exceed
the value of the cols attribute. Docutils expects one
<colspec> per column.
Tables usually consist of a single <tgroup>.
Complex tables with widely varying column specifications may be
easier to code using multiple <tgroup>s. However, this is
not supported by table markup in reStructuredText
and Docutils table handling routines.
<thead> is analogous to the <thead> element in HTML and DocBook.
Processing:
Header rows are always rendered at the beginning of the
table and often presented in an alternate typographic style,
such as boldface.
In paged media, if a table spans across multiple pages,
header rows are printed at the top of each new page.
<title> is analogous to the DocBook <title> element.
In difference to the HTML section heading elements
(<h1>, …, <h6>), the heading level is solely determined
by the nesting level of the parent <section>.
As child of a <table>, <title> corresponds to the
HTML <caption> element.
<section ids="a-title" names="a\ title">
<title>
A Title
<paragraph>
A paragraph.
<section ids="next-section-s-title" names="next\ section's\ title">
<title>
Next section’s title
<topic> is analogous to the DocBook <simplesect> element
and the HTML <aside> element.
Processing:
A <topic> element should be set off from the rest of the
document somehow, such as with indentation or a border.
In contrast to a <sidebar>, it should not float.
Topics are terminal, "leaf" mini-sections, like block quotes with titles,
or textual figures. A <topic> is just like a <section>, except that
it has no subsections, it does not get listed in the ToC, and it doesn't
have to conform to section placement rules.
You may place a <topic> in the middle of a <section> and continue the same
section after it --- something that cannot be done with a nested <section>.
Topics cannot nest inside topics, or body elements
(tables, lists, block quotes, etc).
<transition> is analogous to the HTML <hr> element.
Processing:
The <transition> element is typically rendered as vertical
whitespace (more than that separating paragraphs), with or
without a horizontal line or row of asterisks. In novels,
transitions are often represented as a row of three
well-spaced asterisks with vertical space above and below.
To highlight specific attribute value constraints, the Docutils Generic
DTD defines custom attribute types via parameter entities that
resolve to standard attribute types.
In the docutils.nodes Python module, values are stored
using the specified data types.
Used in the ids attribute. Python data type: list[str].
%measure
A number which may be immediately followed by a unit or percent sign.
ReStructuredText supports CSS3 length units.
Attributes may restrict the value to some range.
Handling of values without unit depends on the writer/output format
(see the writer-specific documentation in the user documentation
for details). Resolves to CDATA.
Used in the height and width attributes. Python data type: str.
%number
The attribute value must be a positive interger. Resolves to NMTOKEN.
The align attribute is used in the <figure> and <table>
elements via the %align-h.att parameter entity
and in <image> via the %align-hv.att parameter entity
to specify the alignment of the element within its parent element.
The Exchange Table Model uses align in the <colspec>,
<entry>, and <tgroup> elements to specify the text alignment
in table cells. It cannot be specified in reStructuredText and is
ignored by Docutils.
The auto attribute is used to indicate automatically-numbered
<footnote>, <footnote_reference> and <title> elements
(via the %auto.att parameter entity).
In <footnote> and <footnote_reference> elements, it also carries information
about the label type: "1": auto-numbered, "*": auto-symbol.
The bullet attribute is used in the <bullet_list> element to
record the style of bullet from the input data. In documents processed
from reStructuredText, it contains one of "-", "+", or "*".
It may be ignored in processing.
The classes attribute is a space separated list containing zero or
more class names. It is one of the common attributes, shared by
all Docutils elements.
The purpose of the attribute is to indicate an "is-a" variant relationship,
to allow an extensible way of defining sub-classes of existing elements.
It can be used to carry context forward between a Docutils Reader and
Writer, when a custom structure is reduced to a standardized document
tree. One common use is in conjunction with stylesheets, to add
selection criteria. It should not be used to carry formatting
instructions or arbitrary content.
The classes attribute's contents should be ignorable. Writers that
are not familiar with the variant expressed should be able to ignore
the attribute.
The colsep attribute is used in the <colspec>, <entry>,
<table>, and <tgroup> elements to specify the presence or absence
of a column separator (vertical ruling).
The attribute is defined in the Exchange Table Model
It cannot be specified in reStructuredText and is ignored by Docutils.
The colwidth attribute is used in the <colspec> element
to specify the column width.
The attribute is defined in the Exchange Table Model
(which see for details) as either a proportional measure
(positive number followed by "*", e.g., "5*" for 5 times the unit proportion,
or just "*" for one unit proportion) or a fixed measure (e.g., 2.5cm).
Docutils supports only proportional measures.
The delimiter attribute is used in the <option_argument> element
and contains the text preceding the <option_argument>: either the text
separating it from the <option_string> (typically either "=" or " ")
or the text between option arguments (typically either "," or " ").
The ids attribute is a space separated list containing one or more
unique identifiers, typically assigned by the system.
It is one of the common attributes, shared by all Docutils elements.
The line attribute is used in the <system_message> element to
indicate the position of the reported problem in the document source.
See also the source attribute.
Attribute type: EnumeratedType, one of "embed", "link", or "lazy".
Default value: none.
The loading attribute is used in the <image> element to
indicate the preferred handling by the Docutils writer. [10]
The default depends on the writer and the image_loading
configuration setting.
The morecols attribute is used in the <entry> element
to specify an entry that spans several physical table columns.
It is similar to the colspan attribute of HTML table cells
(<th> and <td>).
The morecols attribute is defined in the %tbl.entry.att
parameter entity.
The morerows attribute is used in the <entry> element
to specify an entry that spans several physical table rows.
It is similar to the rowspan attribute of HTML table cells
(<th> and <td>).
The names attribute is a space-separated list containing reference
names of an element (spaces inside a name are backslash-escaped).
It is one of the common attributes, shared by all Docutils elements.
Each name in the list must be unique; if there are name conflicts (two or
more elements want to use the same name), the contents will be transferred
to the dupnames attribute on the duplicate elements. [11]
The namest attribute is used in the <entry> element to specify the
leftmost column of a span.
The attribute is defined in the Exchange Table Model.
It cannot be specified in reStructuredText and is ignored by Docutils
which uses the morecols attribute instead.
The nameend attribute is used in the <entry> element to specify the
rightmost column of a span.
The attribute is defined in the Exchange Table Model.
It cannot be specified in reStructuredText and is ignored by Docutils
which uses the morecols attribute instead.
The prefix attribute is used in the <enumerated_list> element
to store the formatting characters used before the enumerator.
In documents originating from reStructuredText data, it will contain
either "" (empty string) or "(" (left parenthesis).
Writers may ignore this attribute.
On a <target> element, refname indicates an indirect target
which may resolve to either an internal or external reference.
Docutils transforms replace the refname attribute with a refid
pointing to the same element.
The rowsep attribute may be used in the <colspec>, <entry>,
<row>, <table>, and <tgroup> elements to specify the presence
or absence of row separators (horizontal ruling).
The attribute is defined in the Exchange Table Model.
It cannot be specified in reStructuredText and is ignored by Docutils.
The source attribute stores the path, URI, or a description
of the source that was used to produce the document tree.
It is one of the common attributes but typically only
used with the <document> and <system_message> elements.
An element's source attribute may differ from the main document
source if the document is assembled from several sources
(e.g. via the "include" directive).
The stub attribute is used in the <colspec> element to
mark a table column as containing stubs (row titles, on the left).
See also the "csv-table" and "list-table" directives.
The attribute is defined in the %tbl.colspec.att parameter entity.
The suffix attribute is used in the <enumerated_list> element
to store the formatting characters used after the enumerator.
In documents originating from reStructuredText data, it will contain
either "." (period) or ")" (right parenthesis). Depending on the
capabilities of the output format, this attribute may or may not affect
processing.
The title attribute is used in the <document> element to store the
document's metadata title.
It is set by the "title" directive or the DocTitle transform.
This title is typically not part of the rendered document.
It is, for example, used as HTML <title> element and shown in a
browser's title bar, in a user's history or bookmarks, or in search results.
Attribute type: EnumeratedType, one of "default" or "preserve".
Default value: "preserve" (fixed).
The xml:space attribute is a standard XML attribute for
whitespace-preserving elements. It is used by the <address>,
<comment>, <doctest_block>, <literal_block>, <math_block>,
and <raw> elements (via the %fixedspace.att parameter entity).
It is a fixed attribute, meant to communicate to an XML parser that the
element contains significant whitespace. The attribute value should not
be set in a document instance.
Parameter entities are used
to simplify the Docutils Generic DTD (share definitions and reduce
duplication) and to allow it to be customized by wrapper DTDs (external
client DTDs that use or import the`Docutils Generic` DTD).
Parameter entities may be overridden by wrapper DTDs, replacing
the definitions below with custom definitions.
In addition, the Docutils Generic DTD defines parameter entities for
custom attribute types.
The %reference.atts parameter entity groups together the refuri,
refid, and refname attributes.
The %additional.reference.atts placeholder can be used by
wrapper DTDs to extend %reference.atts.
The %refname.att parameter entity contains the refname
attribute, an internal reference to the names attribute of another
element. On a <target> element, refname indicates an indirect
target which may resolve to either an internal or external
reference.
Entity definition:
refname %refname.type; #IMPLIED
The <substitution_reference> element directly employs the
%refname.att parameter entity in its attribute list.
The %body.elements parameter entity contains an OR-list of all
Body Elements.
The %additional.body.elements placeholder can be used by
wrapper DTDs to extend %body.elements.
The %inline.elements parameter entity contains an OR-list of all
Inline Elements.
The %additional.inline.elements placeholder can be used by
wrapper DTDs to extend %inline.elements.
The %inline.elements parameter entity is employed in the
%text.model parameter entity.
The %section.elements parameter entity contains the <section>
element.
The %additional.section.elements placeholder can be used
by wrapper DTDs to extend %section.elements.
Via %structure.model, the %section.elements parameter entity
is indirectly employed in the content models of the <document> and
<section> elements.
The %structure.model parameter entity encapsulates the
hierarchical structure of a document and of its constituent parts.
It contains body elements, structural elements, and the
<transition> element.
See the discussion in section Element Hierarchy above.
Each <document> or <section> contains zero or more
body elements, topics, sidebars, or transitions,
followed by zero or more sections (whose contents include this model),
or transitions.
A <transition> may not be the first element (i.e. it may
not occur at the beginning of a document or directly after
a title, subtitle, meta or decoration element).
Transitions must be separated by other elements (body elements,
sections, etc.). In other words, a transition may not be
immediately adjacent to another transition.
An additional restriction cannot be easily expressed in the
language of DTDs: [13]
A transition may not occur at the end of a document or section.
The %structure.model parameter entity is directly employed in the
content models of the <document> and <section> elements.
Docutils employs the identifier normalization to ensure class names
conform to both, HTML4.1 and CSS1.0 name requirements (the regular
expression [a-z](-?[a-z0-9]+)*).
Identifiers cannot be specified directly in reStructuredText.
Docutils generates them from reference names or from the
auto_id_prefix (prepending the id_prefix and appending numbers
for disambiguation if required).
is a representation of XML where nesting is indicated by
indentation and end-tags are not shown. Some of the precision
of real XML is given up in exchange for easier readability.
For example, the following are equivalent:
Reference names may consist of any text.
Whitespace is normalized. [15]Hyperlinks, footnotes, and citations all share the same namespace
for reference names. Comparison ignores case.
Substitutions use a distinct namespace. Comparison is case-sensitive
but forgiving.
Uniform Resource Identifier (URI): Generic Syntax,
T. Berners-Lee, R. Fielding, and L. Masinter,
STD 66, RFC 3986, January 2005,
https://www.rfc-editor.org/info/rfc3986.