Guide XML
Basic structure
Let's start learning the GuideXML syntax. We'll start with the the initial
tags used in a GuideXML document:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<!-- $Header$ -->
<guide link="relative/link/to/your/guide.xml" lang="en">
<title>Gentoo Linux Documentation Guide</title>
<author title="Author">
<mail link="yourname@gentoo.org">Your Name</mail>
</author>
<abstract>
This guide shows you how to compose web documentation using
our new lightweight Gentoo GuideXML syntax. This syntax is the official
format for Gentoo Linux web documentation, and this document itself was created
using GuideXML.
</abstract>
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.0 -->
<license/>
<version>1.0</version>
<date>2004-12-25</date>
On the first lines, we see the requisite tag that identifies this as an XML
document and specifies its DTD. The <!-- $Header$ --> line
will be automatically modified by the CVS server and helps to track revisions.
Next, there's a <guide> tag -- the entire guide document
is enclosed within a <guide> </guide> pair. The link
attribute is compulsory and should preferably contain the relative path to the
document even though the file name alone will work. It is mainly used to
generate a link to a printer-friendly version of your document. If you use a
wrong value, the link to the printable version will either not work or point to
a wrong document. The lang attribute can be used to specify the language
code of your document. It is used to format the date and insert strings like
"Note", "Content", etc. in the specified language. The default
is English.
Next, there's a <title> tag, used to set the title for the entire
guide document.
Then, we come to the <author> tags, which contain information
about the various authors of the document. Each <author> tag
allows for an optional title= element, used to specify the author's
relationship to the document (author, co-author, editor, etc.). In this
particular example, the authors' names are enclosed in another tag -- a
<mail> tag, used to specify an email address for this particular
person. The <mail> tag is optional and can be omitted, and no
more than one <author> element is required per guide document.
Next, we come to the <abstract>, <version> and
<date> tags, used to specify a summary of the document, the
current version number, and the current version date (in YYYY-MM-DD format)
respectively. Dates that are invalid or not in the YYYY-MM-DD format will
appear verbatim in the rendered document.
This rounds out the tags that should appear at the beginning of a guide
document. Besides the <title> and <mail> tags, these
tags shouldn't appear anywhere else except immediately inside the
<guide> tag, and for consistency it's recommended (but not
required) that these tags appear before the content of the document.
Finally we have the <license/> tag, used to publish the document
under the Creative
Commons - Attribution / Share Alike license as required by the Documentation Policy.
Chapters and sections
Once the initial tags have been specified, you're ready to start adding the
structural elements of the document. Guide documents are divided into
chapters, and each chapter can hold one or more sections. Every chapter and
section has a title. Here's an example chapter with a single section,
consisting of a paragraph. If you append this XML to the XML in the previous excerpt and append a
</guide> to the end of the file, you'll have a valid (if minimal)
guide document:
<chapter>
<title>This is my chapter</title>
<section>
<title>This is section one of my chapter</title>
<body>
<p>
This is the actual text content of my section.
</p>
</body>
</section>
</chapter>
Above, I set the chapter title by adding a child <title>
element to the <chapter> element. Then, I created a section by
adding a <section> element. If you look inside the
<section> element, you'll see that it has two child elements -- a
<title> and a <body>. While the <title>
is nothing new, the <body> is -- it contains the actual text
content of this particular section. We'll look at the tags that are allowed
inside a <body> element in a bit.
A <guide> element can contain multiple <chapter>
elements, and a <chapter> can contain multiple
<section> elements. However, a <section>
element can only contain one <body> element.
An example <body>
Now, it's time to learn how to mark up actual content. Here's the XML code for
an example <body> element:
<p>
This is a paragraph. <path>/etc/passwd</path> is a file.
<uri>http://forums.gentoo.org</uri> is my favorite website.
Type <c>ls</c> if you feel like it. I <e>really</e> want to go to sleep now.
</p>
<pre caption="Code Sample">
This is text output or code.
# <i>this is user input</i>
Make HTML/XML easier to read by using selective emphasis:
<foo><i>bar</i></foo>
<comment>(This is how to insert an inline note into the code block)</comment>
</pre>
<note>
This is a note.
</note>
<warn>
This is a warning.
</warn>
<impo>
This is important.
</impo>
Now, here's how the <body> element above is rendered:
This is a paragraph. /etc/passwd is a file.
http://forums.gentoo.org is my favorite website.
Type ls if you feel like it. I really want to go to sleep now.
This is text output or code.
# this is user input
Make HTML/XML easier to read by using selective emphasis:
<foo>bar</foo>
(This is how to insert an inline note into the code block)
This is a note.
This is a warning.
This is important.
The <body> tags
We introduced a lot of new tags in the previous section -- here's what you
need to know. The <p> (paragraph), <pre> (code
block), <note>, <warn> (warning) and
<impo> (important) tags all can contain one or more lines of text.
Besides the <table> element (which we'll cover in just a bit),
these are the only tags that should appear immediately inside a
<body> element. Another thing -- these tags should not be
stacked -- in other words, don't put a <note> element inside a
<p> element. As you might guess, the <pre> element
preserves its whitespace exactly, making it well-suited for code excerpts.
You can also name the <pre> tag:
<pre caption = "Output of uptime">
# <i>uptime</i>
16:50:47 up 164 days, 2:06, 5 users, load average: 0.23, 0.20, 0.25
</pre>
<path>, <c> and <e>
The <path>, <c> and <e> elements can
be used inside any child <body> tag, except for
<pre>.
The <path> element is used to mark text that refers to an
on-disk file -- either an absolute or relative path, or a
simple filename. This element is generally rendered with a monospaced
font to offset it from the standard paragraph type.
The <c> element is used to mark up a command or user
input. Think of <c> as a way to alert the reader to something
that they can type in that will perform some kind of action. For example, all
the XML tags displayed in this document are enclosed in a <c>
element because they represent something that the user could type in that is
not a path. By using <c> elements, you'll help your readers
quickly identify commands that they need to type in. Also, because
<c> elements are already offset from regular text, it is rarely
necessary to surround user input with double-quotes. For example, don't
refer to a "<c>" element like I did in this sentence. Avoiding
the use of unnecessary double-quotes makes a document more readable -- and
adorable!
<e> is used to apply emphasis to a word or phrase; for example:
I really should use semicolons more often. As you can see, this text is
offset from the regular paragraph type for emphasis. This helps to give your
prose more punch!
<mail> and <uri>
We've taken a look at the <mail> tag earlier; it's used to link
some text with a particular email address, and takes the form <mail
link="foo@bar.com">Mr. Foo Bar</mail>.
The <uri> tag is used to point to files/locations on the Internet.
It has two forms -- the first can be used when you want to have the actual URI
displayed in the body text, such as this link to
http://forums.gentoo.org. To create this link, I typed
<uri>http://forums.gentoo.org</uri>. The alternate form is
when you want to associate a URI with some other text -- for example, the Gentoo Forums. To create this
link, I typed <uri link="http://forums.gentoo.org">the Gentoo
Forums</uri>. You don't need to write http://www.gentoo.org/
to link to other parts of the Gentoo website. For instance, a link to the documentation main index should be simply <uri
link="/doc/en/index.xml">documentation main index</uri>. You can
even omit index.xml when you link to a directory index, e.g. <uri
link="/doc/en/">documentation main index</uri>.
Figures
Here's how to insert a figure into a document -- <figure
link="mygfx.png" short="my picture" caption="my favorite picture of all
time"/>. The link= attribute points to the actual graphic image,
the short= attribute specifies a short description (currently used for
the image's HTML alt= attribute), and a caption. Not too difficult
:) We also support the standard HTML-style <img src="foo.gif"/> tag
for adding images without captions, borders, etc.
Tables and lists
Guide supports a simplified table syntax similar to that of HTML. To start
a table, use a <table> tag. Start a row with a <tr>
tag. However, for inserting actual table data, we don't support the
HTML <td> tag; instead, use the <th> if you are inserting a
header, and <ti> if you are inserting a normal informational
block. You can use a <th> anywhere you can use a <ti>
-- there's no requirement that <th> elements appear only in the
first row. Currently, these tags don't support any attributes, but some will
be added (such as a caption= attribute for <table>) soon.
To create ordered or unordered lists, simply use the XHTML-style
<ol>, <ul> and <li> tags. List tags
should only appear inside a <body>, <ul> or
<ol> tag. You need to close the tags as well (which is a general
XML requirement).
Intra-document references
Guide makes it really easy to reference other parts of the document using
hyperlinks. You can create a link pointing to Chapter
One by typing <uri link="#doc_chap1">Chapter
One</uri>. To point to section two of
Chapter One, type <uri link="#doc_chap1_sect2">section two of
Chapter One</uri>. To refer to figure 3 in chapter 1, type <uri
link="#doc_chap1_fig3">figure 1.3</uri>. Or, to refer to code listing 2 in chapter 2, type <uri
link="#doc_chap2_pre2">code listing 2.2</uri>. We'll be
adding other auto-link abilities (such as table support) soon.
However, some guides change often and using such "counting" can lead to broken
links. In order to cope with this, you can define a name for a
<chapter> or <section> by using the id
attribute, and then point to that attribute, like this:
<chapter id="foo">
<title>This is foo!</title>
...
<p>
More information can be found in the <uri link="#foo">foo chapter</uri>
</p>
Coding Style
Introduction
Since all Gentoo Documentation is a joint effort and several people will
most likely change existing documentation, a coding style is needed.
A coding style contains two sections. The first one is regarding
internal coding - how the xml-tags are placed. The second one is
regarding the content - how not to confuse the reader.
Both sections are described next.
Internal Coding Style
Newlines must be placed immediately after every
GuideXML-tag (both opening as closing), except for:
<version>, <date>, <title>,
<th>, <ti>,
<li>, <i>, <e>,
<uri>, <path>, <b>,
<comment>, <mail>.
Blank lines must be placed immediately after every
<body> (opening tag only) and before every
<chapter>, <p>, <table>,
<author> (set), <pre>, <ul>,
<ol>, <warn>, <note> and
<impo> (opening tags only).
Word-wrapping must be applied at 80 characters except inside
<pre>. Only when there is no other choice can be deviated from
this rule (for instance when a URL exceeds the maximum amount of characters).
The editor must then wrap whenever the first whitespace occurs.
Indentation may not be used, except with the XML-constructs of which
the parent XML-tags are <tr> (from <table>),
<ul>, <ol> and <author>. If indentation
is used, it must be two spaces for each indentation. That means no
tabs and not more spaces.
In case word-wrapping happens in <ti>, <th> or
<li> constructs, indentation must be used for the content.
An example for indentation is:
<table>
<tr>
<th>Foo</th>
<th>Bar</th>
</tr>
<tr>
<ti>This is an example for indentation.</ti>
<ti>
In case text cannot be shown within an 80-character wide line, you
must use indentation if the parent tag allows it.
</ti>
</tr>
</table>
<ul>
<li>First option</li>
<li>Second option</li>
</ul>
Attributes may not have spaces in between the attribute, the
"=" mark, and the attribute value. As an example:
Wrong : <pre caption = "Attributes">
Correct: <pre caption="Attributes">
External Coding Style
Inside tables (<table>) and listings (<ul> and
<ol>), periods (".") should not be used unless multiple
sentences are used. In that case, every sentence should end with a period (or
other reading marks).
Every sentence, including those inside tables and listings, should start
with a capital letter.
<ul>
<li>No period</li>
<li>With period. Multiple sentences, remember?</li>
</ul>
Code Listings should always have a caption.
Try to use <uri> with the link attribute as much as
possible. In other words, the Gentoo
Forums is preferred over http://forums.gentoo.org.
When you comment something inside a <pre> construct, use
<comment> and parentheses or the comment marker for the language
that is being used (# for bash scripts and many other things, //
for C code, etc.) Also place the comment before the subject of the
comment.
(Substitute "john" with your user name)
# id john
Handbook Format
Guide vs Book
For high-volume documentation, such as the Installation Instructions, a
broader format was needed. We designed a GuideXML-compatible enhancement that
allows us to write modular and multi-page documentation.
Main File
The first change is the need for a "master" document. This document contains no
real content, but links to the individual documentation modules. The syntaxis
doesn't differ much from GuideXML:
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE book SYSTEM "/dtd/book.dtd">
<!-- $Header$ -->
<book link="example.xml">
<title>Example Book Usage</title>
<author...>
...
</author>
<abstract>
...
</abstract>
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.0 -->
<license/>
<version>...</version>
<date>...</date>
So far no real differences (except for the <book> instead of
<guide> tag). Instead of starting with the individual
<chapter>'s, you define a <part>, which is the
equivalent of a separate part in a book:
<part>
<title>Part One</title>
<abstract>
...
</abstract>
(Defining the several chapters)
</part>
Each part is accompanied by a <title> and an
<abstract> which gives a small introduction to the part.
Inside each part, you define the individual <chapter>'s. Each
chapter must be a separate document. As a result it is no surprise that a
special tag (<include>) is added to allow including the separate
document.
<chapter>
<title>Chapter One</title>
<abstract>
This is a small explanation on chapter one.
</abstract>
<include href="path/to/chapter-one.xml"/>
</chapter>
Designing the Individual Chapters
The content of an individual chapter is structured as follows:
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
<!-- $Header$ -->
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.0 -->
<sections>
<version>...</version>
<date>...</date>
(Define the several <section> and <subsection>)
</sections>
Inside each chapter you can define <section>'s (equivalent of
<chapter> in a Guide) and <subsection>'s (equivalent
of <section> in a Guide).
Each individual chapter should have its own date and version elements. The
latest date of all chapters and master document will be displayed when a user
browses through all parts of the book.