| 1 |
cam |
1.41 |
<?xml version="1.0" encoding="UTF-8"?>
|
| 2 |
neysx |
1.53 |
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/xml-guide.xml,v 1.52 2005/10/13 15:57:42 neysx Exp $ -->
|
| 3 |
drobbins |
1.1 |
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
|
| 4 |
|
|
|
| 5 |
zhen |
1.2 |
<guide link="/doc/en/xml-guide.xml">
|
| 6 |
vapier |
1.50 |
<title>Gentoo XML Guide</title>
|
| 7 |
swift |
1.15 |
|
| 8 |
|
|
<author title="Author">
|
| 9 |
|
|
<mail link="drobbins@gentoo.org">Daniel Robbins</mail>
|
| 10 |
|
|
</author>
|
| 11 |
swift |
1.19 |
<author title="Author"><!-- zhen@gentoo.org -->
|
| 12 |
|
|
John P. Davis
|
| 13 |
swift |
1.15 |
</author>
|
| 14 |
|
|
<author title="Editor">
|
| 15 |
|
|
<mail link="peesh@gentoo.org">Jorge Paulo</mail>
|
| 16 |
|
|
</author>
|
| 17 |
swift |
1.25 |
<author title="Editor">
|
| 18 |
|
|
<mail link="swift@gentoo.org">Sven Vermeulen</mail>
|
| 19 |
|
|
</author>
|
| 20 |
neysx |
1.35 |
<author title="Editor">
|
| 21 |
|
|
<mail link="neysx@gentoo.org">Xavier Neys</mail>
|
| 22 |
|
|
</author>
|
| 23 |
drobbins |
1.1 |
|
| 24 |
swift |
1.15 |
<abstract>
|
| 25 |
|
|
This guide shows you how to compose web documentation using the new lightweight
|
| 26 |
vapier |
1.50 |
Gentoo GuideXML syntax. This syntax is the official format for Gentoo
|
| 27 |
swift |
1.15 |
documentation, and this document itself was created using GuideXML. This guide
|
| 28 |
|
|
assumes a basic working knowledge of XML and HTML.
|
| 29 |
drobbins |
1.1 |
</abstract>
|
| 30 |
|
|
|
| 31 |
swift |
1.31 |
<!-- The content of this document is licensed under the CC-BY-SA license -->
|
| 32 |
swift |
1.46 |
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
|
| 33 |
swift |
1.26 |
<license/>
|
| 34 |
|
|
|
| 35 |
neysx |
1.53 |
<version>2.28</version>
|
| 36 |
|
|
<date>2005-10-13</date>
|
| 37 |
drobbins |
1.1 |
|
| 38 |
|
|
<chapter>
|
| 39 |
|
|
<title>Guide basics</title>
|
| 40 |
|
|
<section>
|
| 41 |
|
|
<title>Guide XML design goals</title>
|
| 42 |
|
|
<body>
|
| 43 |
|
|
|
| 44 |
swift |
1.15 |
<p>
|
| 45 |
|
|
The guide XML syntax is lightweight yet expressive, so that it is easy to
|
| 46 |
drobbins |
1.1 |
learn yet also provides all the features we need for the creation of web
|
| 47 |
|
|
documentation. The number of tags is kept to a minimum -- just those we need.
|
| 48 |
|
|
This makes it easy to transform guide into other formats, such as DocBook
|
| 49 |
swift |
1.15 |
XML/SGML or web-ready HTML.
|
| 50 |
|
|
</p>
|
| 51 |
drobbins |
1.1 |
|
| 52 |
swift |
1.15 |
<p>
|
| 53 |
|
|
The goal is to make it easy to <e>create</e> and <e>transform</e> guide XML
|
| 54 |
|
|
documents.
|
| 55 |
|
|
</p>
|
| 56 |
drobbins |
1.1 |
|
| 57 |
|
|
</body>
|
| 58 |
|
|
</section>
|
| 59 |
|
|
<section>
|
| 60 |
swift |
1.20 |
<title>Further Resources</title>
|
| 61 |
drobbins |
1.1 |
<body>
|
| 62 |
|
|
|
| 63 |
swift |
1.15 |
<p>
|
| 64 |
neysx |
1.34 |
If you are planning on contributing documentation to Gentoo, or you want to
|
| 65 |
neysx |
1.52 |
test GuideXML, please read our <uri
|
| 66 |
|
|
link="/proj/en/gdp/doc/doc-tipsntricks.xml">Doc Tips 'n' Tricks</uri> guide
|
| 67 |
|
|
which contains tips and tricks for documentation development.
|
| 68 |
|
|
</p>
|
| 69 |
|
|
|
| 70 |
|
|
<p>
|
| 71 |
|
|
You may want to look at the <uri link="?passthru=1">XML source</uri> of this
|
| 72 |
|
|
document while you read it.
|
| 73 |
drobbins |
1.1 |
</p>
|
| 74 |
|
|
|
| 75 |
|
|
</body>
|
| 76 |
|
|
</section>
|
| 77 |
|
|
</chapter>
|
| 78 |
swift |
1.15 |
|
| 79 |
drobbins |
1.1 |
<chapter>
|
| 80 |
swift |
1.15 |
<title>Guide XML</title>
|
| 81 |
drobbins |
1.1 |
<section>
|
| 82 |
|
|
<title>Basic structure</title>
|
| 83 |
|
|
<body>
|
| 84 |
|
|
|
| 85 |
swift |
1.15 |
<p>
|
| 86 |
swift |
1.36 |
Let's start learning the GuideXML syntax. We'll start with the the initial
|
| 87 |
|
|
tags used in a GuideXML document:
|
| 88 |
swift |
1.15 |
</p>
|
| 89 |
drobbins |
1.1 |
|
| 90 |
|
|
<pre caption="The initial part of a guide XML document">
|
| 91 |
cam |
1.41 |
<?xml version="1.0" encoding="UTF-8"?>
|
| 92 |
swift |
1.25 |
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
|
| 93 |
neysx |
1.42 |
<!-- $Header$ -->
|
| 94 |
|
|
|
| 95 |
neysx |
1.43 |
<guide link="<i>/doc/en/guide.xml</i>" lang="<i>en</i>">
|
| 96 |
vapier |
1.50 |
<title><i>Gentoo Documentation Guide</i></title>
|
| 97 |
neysx |
1.49 |
|
| 98 |
swift |
1.33 |
<author title="<i>Author</i>">
|
| 99 |
|
|
<mail link="<i>yourname@gentoo.org</i>"><i>Your Name</i></mail>
|
| 100 |
drobbins |
1.1 |
</author>
|
| 101 |
|
|
|
| 102 |
swift |
1.15 |
<abstract>
|
| 103 |
|
|
<i>This guide shows you how to compose web documentation using
|
| 104 |
|
|
our new lightweight Gentoo GuideXML syntax. This syntax is the official
|
| 105 |
vapier |
1.50 |
format for Gentoo web documentation, and this document itself was created
|
| 106 |
swift |
1.15 |
using GuideXML.</i>
|
| 107 |
|
|
</abstract>
|
| 108 |
drobbins |
1.1 |
|
| 109 |
swift |
1.27 |
<!-- The content of this document is licensed under the CC-BY-SA license -->
|
| 110 |
swift |
1.46 |
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
|
| 111 |
swift |
1.14 |
<license/>
|
| 112 |
|
|
|
| 113 |
drobbins |
1.1 |
<version><i>1.0</i></version>
|
| 114 |
neysx |
1.35 |
<date><i>2004-12-25</i></date>
|
| 115 |
drobbins |
1.1 |
</pre>
|
| 116 |
|
|
|
| 117 |
swift |
1.15 |
<p>
|
| 118 |
neysx |
1.42 |
On the first lines, we see the requisite tag that identifies this as an XML
|
| 119 |
|
|
document and specifies its DTD. The <c><!-- $Header$ --></c> line
|
| 120 |
|
|
will be automatically modified by the CVS server and helps to track revisions.
|
| 121 |
neysx |
1.51 |
Next, there's a <c><guide></c> tag -- the entire guide document is
|
| 122 |
|
|
enclosed within a <c><guide> </guide></c> pair. The <c>link</c>
|
| 123 |
neysx |
1.43 |
attribute is compulsory and should preferably contain the absolute path to the
|
| 124 |
|
|
document relatively to the document root even though the file name alone will
|
| 125 |
|
|
work. It is mainly used to generate a link to a printer-friendly version of
|
| 126 |
neysx |
1.51 |
your document. If you use a wrong value, the link to the printable version will
|
| 127 |
|
|
either not work or point to a wrong document. Translated documents <e>must</e>
|
| 128 |
|
|
specify the full path because it is also used to check whether a more recent
|
| 129 |
|
|
original document exists. The <c>lang</c> attribute should be used to specify
|
| 130 |
|
|
the language code of your document. It is used to format the date and insert
|
| 131 |
|
|
strings like "<e>Note</e>", "<e>Content</e>", etc. in the specified language.
|
| 132 |
|
|
The default is English.
|
| 133 |
neysx |
1.35 |
</p>
|
| 134 |
|
|
|
| 135 |
|
|
<p>
|
| 136 |
drobbins |
1.1 |
Next, there's a <c><title></c> tag, used to set the title for the entire
|
| 137 |
swift |
1.15 |
guide document.
|
| 138 |
|
|
</p>
|
| 139 |
drobbins |
1.1 |
|
| 140 |
swift |
1.15 |
<p>
|
| 141 |
|
|
Then, we come to the <c><author></c> tags, which contain information
|
| 142 |
drobbins |
1.1 |
about the various authors of the document. Each <c><author></c> tag
|
| 143 |
neysx |
1.52 |
allows for an optional <c>title</c> element, used to specify the author's
|
| 144 |
drobbins |
1.1 |
relationship to the document (author, co-author, editor, etc.). In this
|
| 145 |
|
|
particular example, the authors' names are enclosed in another tag -- a
|
| 146 |
|
|
<c><mail></c> tag, used to specify an email address for this particular
|
| 147 |
|
|
person. The <c><mail></c> tag is optional and can be omitted, and no
|
| 148 |
|
|
more than one <c><author></c> element is required per guide document.
|
| 149 |
|
|
</p>
|
| 150 |
|
|
|
| 151 |
swift |
1.15 |
<p>
|
| 152 |
|
|
Next, we come to the <c><abstract></c>, <c><version></c> and
|
| 153 |
drobbins |
1.1 |
<c><date></c> tags, used to specify a summary of the document, the
|
| 154 |
neysx |
1.35 |
current version number, and the current version date (in YYYY-MM-DD format)
|
| 155 |
|
|
respectively. Dates that are invalid or not in the YYYY-MM-DD format will
|
| 156 |
|
|
appear verbatim in the rendered document.
|
| 157 |
|
|
</p>
|
| 158 |
|
|
|
| 159 |
|
|
<p>
|
| 160 |
|
|
This rounds out the tags that should appear at the beginning of a guide
|
| 161 |
|
|
document. Besides the <c><title></c> and <c><mail></c> tags, these
|
| 162 |
|
|
tags shouldn't appear anywhere else except immediately inside the
|
| 163 |
drobbins |
1.1 |
<c><guide></c> tag, and for consistency it's recommended (but not
|
| 164 |
swift |
1.15 |
required) that these tags appear before the content of the document.
|
| 165 |
|
|
</p>
|
| 166 |
swift |
1.14 |
|
| 167 |
swift |
1.15 |
<p>
|
| 168 |
neysx |
1.38 |
Finally we have the <c><license/></c> tag, used to publish the document
|
| 169 |
neysx |
1.49 |
under the <uri link="http://creativecommons.org/licenses/by-sa/2.5/">Creative
|
| 170 |
neysx |
1.38 |
Commons - Attribution / Share Alike</uri> license as required by the <uri
|
| 171 |
|
|
link="/proj/en/gdp/doc/doc-policy.xml">Documentation Policy</uri>.
|
| 172 |
swift |
1.15 |
</p>
|
| 173 |
drobbins |
1.1 |
|
| 174 |
|
|
</body>
|
| 175 |
|
|
</section>
|
| 176 |
|
|
<section>
|
| 177 |
|
|
<title>Chapters and sections</title>
|
| 178 |
|
|
<body>
|
| 179 |
swift |
1.15 |
|
| 180 |
|
|
<p>
|
| 181 |
neysx |
1.37 |
Once the initial tags have been specified, you're ready to start adding the
|
| 182 |
|
|
structural elements of the document. Guide documents are divided into
|
| 183 |
|
|
chapters, and each chapter can hold one or more sections. Every chapter and
|
| 184 |
|
|
section has a title. Here's an example chapter with a single section,
|
| 185 |
|
|
consisting of a paragraph. If you append this XML to the XML in the <uri
|
| 186 |
|
|
link="#doc_chap2_pre1">previous excerpt</uri> and append a
|
| 187 |
|
|
<c></guide></c> to the end of the file, you'll have a valid (if minimal)
|
| 188 |
|
|
guide document:
|
| 189 |
drobbins |
1.1 |
</p>
|
| 190 |
|
|
|
| 191 |
neysx |
1.37 |
<pre caption="Minimal guide example">
|
| 192 |
drobbins |
1.1 |
<chapter>
|
| 193 |
|
|
<title><i>This is my chapter</i></title>
|
| 194 |
|
|
<section>
|
| 195 |
swift |
1.15 |
<title><i>This is section one of my chapter</i></title>
|
| 196 |
|
|
<body>
|
| 197 |
|
|
|
| 198 |
|
|
<p>
|
| 199 |
|
|
<i>This is the actual text content of my section.</i>
|
| 200 |
|
|
</p>
|
| 201 |
|
|
|
| 202 |
|
|
</body>
|
| 203 |
drobbins |
1.1 |
</section>
|
| 204 |
|
|
</chapter>
|
| 205 |
|
|
</pre>
|
| 206 |
|
|
|
| 207 |
swift |
1.15 |
<p>
|
| 208 |
|
|
Above, I set the chapter title by adding a child <c><title></c>
|
| 209 |
drobbins |
1.1 |
element to the <c><chapter></c> element. Then, I created a section by
|
| 210 |
|
|
adding a <c><section></c> element. If you look inside the
|
| 211 |
|
|
<c><section></c> element, you'll see that it has two child elements -- a
|
| 212 |
|
|
<c><title></c> and a <c><body></c>. While the <c><title></c>
|
| 213 |
|
|
is nothing new, the <c><body></c> is -- it contains the actual text
|
| 214 |
|
|
content of this particular section. We'll look at the tags that are allowed
|
| 215 |
swift |
1.15 |
inside a <c><body></c> element in a bit.
|
| 216 |
|
|
</p>
|
| 217 |
drobbins |
1.1 |
|
| 218 |
swift |
1.15 |
<note>
|
| 219 |
|
|
A <c><guide></c> element can contain multiple <c><chapter></c>
|
| 220 |
|
|
elements, and a <c><chapter></c> can contain multiple
|
| 221 |
|
|
<c><section></c> elements. However, a <c><section></c>
|
| 222 |
|
|
element can only contain one <c><body></c> element.
|
| 223 |
|
|
</note>
|
| 224 |
drobbins |
1.1 |
|
| 225 |
|
|
</body>
|
| 226 |
|
|
</section>
|
| 227 |
|
|
<section>
|
| 228 |
|
|
<title>An example <body></title>
|
| 229 |
|
|
<body>
|
| 230 |
swift |
1.15 |
|
| 231 |
drobbins |
1.1 |
<p>
|
| 232 |
neysx |
1.37 |
Now, it's time to learn how to mark up actual content. Here's the XML code for
|
| 233 |
|
|
an example <c><body></c> element:
|
| 234 |
drobbins |
1.1 |
</p>
|
| 235 |
swift |
1.15 |
|
| 236 |
neysx |
1.37 |
<pre caption="Example of a body element">
|
| 237 |
drobbins |
1.1 |
<p>
|
| 238 |
|
|
This is a paragraph. <path>/etc/passwd</path> is a file.
|
| 239 |
neysx |
1.35 |
<uri>http://forums.gentoo.org</uri> is my favorite website.
|
| 240 |
drobbins |
1.1 |
Type <c>ls</c> if you feel like it. I <e>really</e> want to go to sleep now.
|
| 241 |
|
|
</p>
|
| 242 |
|
|
|
| 243 |
neysx |
1.37 |
<pre caption="Code Sample">
|
| 244 |
drobbins |
1.1 |
This is text output or code.
|
| 245 |
|
|
# <i>this is user input</i>
|
| 246 |
|
|
|
| 247 |
|
|
Make HTML/XML easier to read by using selective emphasis:
|
| 248 |
|
|
<foo><i>bar</i></foo>
|
| 249 |
|
|
|
| 250 |
neysx |
1.37 |
<comment>(This is how to insert an inline note into the code block)</comment>
|
| 251 |
drobbins |
1.1 |
</pre>
|
| 252 |
swift |
1.15 |
|
| 253 |
|
|
<note>
|
| 254 |
|
|
This is a note.
|
| 255 |
|
|
</note>
|
| 256 |
|
|
|
| 257 |
|
|
<warn>
|
| 258 |
|
|
This is a warning.
|
| 259 |
|
|
</warn>
|
| 260 |
|
|
|
| 261 |
|
|
<impo>
|
| 262 |
|
|
This is important.
|
| 263 |
|
|
</impo>
|
| 264 |
drobbins |
1.1 |
</pre>
|
| 265 |
swift |
1.15 |
|
| 266 |
|
|
<p>
|
| 267 |
neysx |
1.37 |
Now, here's how the <c><body></c> element above is rendered:
|
| 268 |
swift |
1.15 |
</p>
|
| 269 |
drobbins |
1.1 |
|
| 270 |
|
|
<p>
|
| 271 |
|
|
This is a paragraph. <path>/etc/passwd</path> is a file.
|
| 272 |
swift |
1.45 |
<uri>http://forums.gentoo.org</uri> is my favorite web site.
|
| 273 |
drobbins |
1.1 |
Type <c>ls</c> if you feel like it. I <e>really</e> want to go to sleep now.
|
| 274 |
|
|
</p>
|
| 275 |
|
|
|
| 276 |
neysx |
1.37 |
<pre caption="Code Sample">
|
| 277 |
drobbins |
1.1 |
This is text output or code.
|
| 278 |
|
|
# <i>this is user input</i>
|
| 279 |
|
|
|
| 280 |
|
|
Make HTML/XML easier to read by using selective emphasis:
|
| 281 |
|
|
<foo><i>bar</i></foo>
|
| 282 |
|
|
|
| 283 |
neysx |
1.37 |
<comment>(This is how to insert an inline note into the code block)</comment>
|
| 284 |
drobbins |
1.1 |
</pre>
|
| 285 |
swift |
1.15 |
|
| 286 |
|
|
<note>
|
| 287 |
|
|
This is a note.
|
| 288 |
|
|
</note>
|
| 289 |
|
|
|
| 290 |
|
|
<warn>
|
| 291 |
|
|
This is a warning.
|
| 292 |
|
|
</warn>
|
| 293 |
|
|
|
| 294 |
|
|
<impo>
|
| 295 |
|
|
This is important.
|
| 296 |
|
|
</impo>
|
| 297 |
|
|
|
| 298 |
drobbins |
1.1 |
</body>
|
| 299 |
|
|
</section>
|
| 300 |
|
|
<section>
|
| 301 |
|
|
<title>The <body> tags</title>
|
| 302 |
|
|
<body>
|
| 303 |
|
|
|
| 304 |
swift |
1.15 |
<p>
|
| 305 |
neysx |
1.52 |
We introduced a lot of new tags in the previous section -- here's what you need
|
| 306 |
|
|
to know. The <c><p></c> (paragraph), <c><pre></c> (code block),
|
| 307 |
|
|
<c><note></c>, <c><warn></c> (warning) and <c><impo></c>
|
| 308 |
|
|
(important) tags all can contain one or more lines of text. Besides the
|
| 309 |
|
|
<c><table></c>, <c><ul></c>, <c><ol></c> and
|
| 310 |
|
|
<c><dl></c> elements (which we'll cover in just a bit), these are the
|
| 311 |
|
|
only tags that should appear immediately inside a <c><body></c> element.
|
| 312 |
|
|
Another thing -- these tags <e>should not</e> be stacked -- in other words,
|
| 313 |
|
|
don't put a <c><note></c> element inside a <c><p></c> element. As
|
| 314 |
|
|
you might guess, the <c><pre></c> element preserves its whitespace
|
| 315 |
|
|
exactly, making it well-suited for code excerpts. You must name the
|
| 316 |
neysx |
1.53 |
<c><pre></c> tag with a <c>caption</c> attribute:
|
| 317 |
swift |
1.15 |
</p>
|
| 318 |
swift |
1.12 |
|
| 319 |
neysx |
1.37 |
<pre caption="Named <pre>">
|
| 320 |
neysx |
1.51 |
<pre caption="Output of uptime">
|
| 321 |
swift |
1.12 |
# <i>uptime</i>
|
| 322 |
|
|
16:50:47 up 164 days, 2:06, 5 users, load average: 0.23, 0.20, 0.25
|
| 323 |
|
|
</pre>
|
| 324 |
|
|
</pre>
|
| 325 |
drobbins |
1.1 |
|
| 326 |
|
|
</body>
|
| 327 |
|
|
</section>
|
| 328 |
|
|
<section>
|
| 329 |
neysx |
1.52 |
<title>Epigraphs</title>
|
| 330 |
|
|
<body>
|
| 331 |
|
|
|
| 332 |
|
|
<p by="Anonymous student">
|
| 333 |
|
|
Delegates from the original 13 states formed the Contented Congress. Thomas
|
| 334 |
|
|
Jefferson, a Virgin, and Benjamin Franklin were two singers of the Declaration
|
| 335 |
|
|
of Independence. Franklin discovered electricity by rubbing two cats backwards
|
| 336 |
|
|
and declared, "A horse divided against itself cannot stand." Franklin died in
|
| 337 |
|
|
1790 and is still dead.
|
| 338 |
|
|
</p>
|
| 339 |
|
|
|
| 340 |
|
|
<p>
|
| 341 |
|
|
Epigraphs are sometimes used at the beginning of chapters to illustrate what is
|
| 342 |
|
|
to follow. It is simply a paragraph with a <c>by</c> attribute that contains
|
| 343 |
|
|
the signature.
|
| 344 |
|
|
</p>
|
| 345 |
|
|
|
| 346 |
|
|
<pre caption="Short epigraph">
|
| 347 |
|
|
<p by="Anonymous student">
|
| 348 |
|
|
Delegates from the original 13 states formed the...
|
| 349 |
|
|
</p>
|
| 350 |
|
|
</pre>
|
| 351 |
|
|
|
| 352 |
|
|
</body>
|
| 353 |
|
|
</section>
|
| 354 |
|
|
<section>
|
| 355 |
|
|
<title>
|
| 356 |
|
|
<path>, <c>, <i>, <b>, <e>, <sub> and <sup>
|
| 357 |
|
|
</title>
|
| 358 |
drobbins |
1.1 |
<body>
|
| 359 |
|
|
|
| 360 |
swift |
1.15 |
<p>
|
| 361 |
neysx |
1.52 |
The <c><path></c>, <c><c></c>, <c><b></c>, <c><e></c>,
|
| 362 |
|
|
<c><sub></c> and <c><sup></c> elements can be used inside any child
|
| 363 |
|
|
<c><body></c> tag, except for <c><pre></c>. The <c><i></c>
|
| 364 |
|
|
element can only be used inside <c><pre></c>.
|
| 365 |
swift |
1.15 |
</p>
|
| 366 |
drobbins |
1.1 |
|
| 367 |
swift |
1.15 |
<p>
|
| 368 |
|
|
The <c><path></c> element is used to mark text that refers to an
|
| 369 |
|
|
<e>on-disk file</e> -- either an <e>absolute or relative path</e>, or a
|
| 370 |
swift |
1.45 |
<e>simple filename</e>. This element is generally rendered with a mono spaced
|
| 371 |
swift |
1.15 |
font to offset it from the standard paragraph type.
|
| 372 |
|
|
</p>
|
| 373 |
drobbins |
1.1 |
|
| 374 |
swift |
1.15 |
<p>
|
| 375 |
|
|
The <c><c></c> element is used to mark up a <e>command</e> or <e>user
|
| 376 |
drobbins |
1.1 |
input</e>. Think of <c><c></c> as a way to alert the reader to something
|
| 377 |
|
|
that they can type in that will perform some kind of action. For example, all
|
| 378 |
|
|
the XML tags displayed in this document are enclosed in a <c><c></c>
|
| 379 |
|
|
element because they represent something that the user could type in that is
|
| 380 |
|
|
not a path. By using <c><c></c> elements, you'll help your readers
|
| 381 |
|
|
quickly identify commands that they need to type in. Also, because
|
| 382 |
|
|
<c><c></c> elements are already offset from regular text, <e>it is rarely
|
| 383 |
|
|
necessary to surround user input with double-quotes</e>. For example, don't
|
| 384 |
|
|
refer to a "<c><c></c>" element like I did in this sentence. Avoiding
|
| 385 |
swift |
1.15 |
the use of unnecessary double-quotes makes a document more readable -- and
|
| 386 |
|
|
adorable!
|
| 387 |
|
|
</p>
|
| 388 |
drobbins |
1.1 |
|
| 389 |
swift |
1.15 |
<p>
|
| 390 |
swift |
1.44 |
When you want to highlight some text as user input inside a <c><pre></c>,
|
| 391 |
|
|
use <c><i></c> instead.
|
| 392 |
|
|
</p>
|
| 393 |
|
|
|
| 394 |
|
|
<p>
|
| 395 |
neysx |
1.51 |
As you might have guessed, <c><b></c> is used to <b>boldface</b> some
|
| 396 |
|
|
text.
|
| 397 |
|
|
</p>
|
| 398 |
|
|
|
| 399 |
|
|
<p>
|
| 400 |
swift |
1.15 |
<c><e></c> is used to apply emphasis to a word or phrase; for example:
|
| 401 |
drobbins |
1.1 |
I <e>really</e> should use semicolons more often. As you can see, this text is
|
| 402 |
|
|
offset from the regular paragraph type for emphasis. This helps to give your
|
| 403 |
swift |
1.15 |
prose more <e>punch</e>!
|
| 404 |
|
|
</p>
|
| 405 |
drobbins |
1.1 |
|
| 406 |
neysx |
1.52 |
<p>
|
| 407 |
|
|
The <c><sub></c> and <c><sup></c> elements are used to specify
|
| 408 |
|
|
<sub>subscript</sub> and <sup>superscript</sup>.
|
| 409 |
|
|
</p>
|
| 410 |
|
|
|
| 411 |
drobbins |
1.1 |
</body>
|
| 412 |
|
|
</section>
|
| 413 |
|
|
<section>
|
| 414 |
|
|
<title><mail> and <uri></title>
|
| 415 |
|
|
<body>
|
| 416 |
|
|
|
| 417 |
swift |
1.15 |
<p>
|
| 418 |
neysx |
1.51 |
We've taken a look at the <c><mail></c> tag earlier; it's used to link
|
| 419 |
|
|
some text with a particular email address, and takes the form <c><mail
|
| 420 |
|
|
link="foo@bar.com">Mr. Foo Bar</mail></c>. If you want to display the
|
| 421 |
|
|
email address, you can use <c><mail>foo@bar.com</mail></c>, this
|
| 422 |
|
|
would be displayed as <mail>foo@bar.com</mail>.
|
| 423 |
swift |
1.15 |
</p>
|
| 424 |
drobbins |
1.1 |
|
| 425 |
swift |
1.15 |
<p>
|
| 426 |
neysx |
1.35 |
The <c><uri></c> tag is used to point to files/locations on the Internet.
|
| 427 |
|
|
It has two forms -- the first can be used when you want to have the actual URI
|
| 428 |
|
|
displayed in the body text, such as this link to
|
| 429 |
|
|
<uri>http://forums.gentoo.org</uri>. To create this link, I typed
|
| 430 |
|
|
<c><uri>http://forums.gentoo.org</uri></c>. The alternate form is
|
| 431 |
drobbins |
1.1 |
when you want to associate a URI with some other text -- for example, <uri
|
| 432 |
neysx |
1.35 |
link="http://forums.gentoo.org">the Gentoo Forums</uri>. To create <e>this</e>
|
| 433 |
|
|
link, I typed <c><uri link="http://forums.gentoo.org">the Gentoo
|
| 434 |
|
|
Forums</uri></c>. You don't need to write <c>http://www.gentoo.org/</c>
|
| 435 |
swift |
1.45 |
to link to other parts of the Gentoo web site. For instance, a link to the <uri
|
| 436 |
neysx |
1.35 |
link="/doc/en/">documentation main index</uri> should be simply <c><uri
|
| 437 |
|
|
link="/doc/en/index.xml">documentation main index</uri></c>. You can
|
| 438 |
|
|
even omit <c>index.xml</c> when you link to a directory index, e.g. <c><uri
|
| 439 |
|
|
link="/doc/en/">documentation main index</uri></c>.
|
| 440 |
drobbins |
1.1 |
</p>
|
| 441 |
|
|
|
| 442 |
|
|
</body>
|
| 443 |
|
|
</section>
|
| 444 |
|
|
<section>
|
| 445 |
|
|
<title>Figures</title>
|
| 446 |
|
|
<body>
|
| 447 |
|
|
|
| 448 |
swift |
1.15 |
<p>
|
| 449 |
|
|
Here's how to insert a figure into a document -- <c><figure
|
| 450 |
drobbins |
1.1 |
link="mygfx.png" short="my picture" caption="my favorite picture of all
|
| 451 |
neysx |
1.52 |
time"/></c>. The <c>link</c> attribute points to the actual graphic image,
|
| 452 |
|
|
the <c>short</c> attribute specifies a short description (currently used for
|
| 453 |
|
|
the image's HTML <c>alt</c> attribute), and a caption. Not too difficult
|
| 454 |
drobbins |
1.1 |
:) We also support the standard HTML-style <img src="foo.gif"/> tag
|
| 455 |
swift |
1.15 |
for adding images without captions, borders, etc.
|
| 456 |
|
|
</p>
|
| 457 |
drobbins |
1.1 |
|
| 458 |
|
|
</body>
|
| 459 |
|
|
</section>
|
| 460 |
|
|
<section>
|
| 461 |
neysx |
1.52 |
<title>Tables</title>
|
| 462 |
drobbins |
1.1 |
<body>
|
| 463 |
|
|
|
| 464 |
swift |
1.15 |
<p>
|
| 465 |
neysx |
1.52 |
Guide supports a simplified table syntax similar to that of HTML. To start a
|
| 466 |
neysx |
1.51 |
table, use a <c><table></c> tag. Start a row with a <c><tr></c>
|
| 467 |
neysx |
1.52 |
tag. However, for inserting actual table data, we <e>don't</e> support the
|
| 468 |
drobbins |
1.1 |
HTML <td> tag; instead, use the <c><th></c> if you are inserting a
|
| 469 |
|
|
header, and <c><ti></c> if you are inserting a normal informational
|
| 470 |
neysx |
1.51 |
block. You can use a <c><th></c> anywhere you can use a <c><ti></c>
|
| 471 |
|
|
-- there's no requirement that <c><th></c> elements appear only in the
|
| 472 |
|
|
first row.
|
| 473 |
drobbins |
1.1 |
</p>
|
| 474 |
|
|
|
| 475 |
swift |
1.15 |
<p>
|
| 476 |
neysx |
1.52 |
Besides, the table header tag (<c><th></c>) accepts the <c>colspan</c>
|
| 477 |
|
|
and <c>rowspan</c> attributes to span titles across rows, columns or both as
|
| 478 |
|
|
shown below:
|
| 479 |
|
|
</p>
|
| 480 |
|
|
|
| 481 |
|
|
<table>
|
| 482 |
|
|
<tr>
|
| 483 |
|
|
<th colspan="4">This title spans 4 columns</th>
|
| 484 |
|
|
</tr>
|
| 485 |
|
|
<tr>
|
| 486 |
|
|
<th rowspan="3">This title spans 3 rows</th>
|
| 487 |
|
|
<ti>Item A1</ti>
|
| 488 |
|
|
<ti>Item A2</ti>
|
| 489 |
|
|
<ti>Item A3</ti>
|
| 490 |
|
|
</tr>
|
| 491 |
|
|
<tr>
|
| 492 |
|
|
<ti>Item B1</ti>
|
| 493 |
|
|
<th colspan="2" rowspan="2">Blocky 2x2 title</th>
|
| 494 |
|
|
</tr>
|
| 495 |
|
|
<tr>
|
| 496 |
|
|
<ti>Item C1</ti>
|
| 497 |
|
|
</tr>
|
| 498 |
|
|
</table>
|
| 499 |
|
|
|
| 500 |
|
|
</body>
|
| 501 |
|
|
</section>
|
| 502 |
|
|
<section>
|
| 503 |
|
|
<title>Lists</title>
|
| 504 |
|
|
<body>
|
| 505 |
|
|
|
| 506 |
|
|
<p>
|
| 507 |
swift |
1.39 |
To create ordered or unordered lists, simply use the XHTML-style
|
| 508 |
neysx |
1.52 |
<c><ol></c>, <c><ul></c> and <c><li></c> tags. Lists may only
|
| 509 |
|
|
appear inside the <c><body></c> and <c><li></c> tags which means
|
| 510 |
|
|
that you can have lists inside lists. Don't forget that you are writing XML and
|
| 511 |
|
|
that you must close all tags including list items unlike in HTML.
|
| 512 |
swift |
1.15 |
</p>
|
| 513 |
drobbins |
1.1 |
|
| 514 |
neysx |
1.52 |
<p>
|
| 515 |
|
|
Definition lists (<c><dl></c>) are also supported. Please note that
|
| 516 |
|
|
neither the definition term tag (<c><dt></c>) nor the definition data tag
|
| 517 |
|
|
(<c><dd></c>) accept any other block level tag such as paragraphs or
|
| 518 |
neysx |
1.53 |
admonitions. A definition list comprises:
|
| 519 |
neysx |
1.52 |
</p>
|
| 520 |
|
|
|
| 521 |
|
|
<dl>
|
| 522 |
|
|
<dt><c><dl></c></dt>
|
| 523 |
|
|
<dd>A <b>D</b>efinition <b>L</b>ist Tag containing</dd>
|
| 524 |
|
|
<dt><c><dt></c></dt>
|
| 525 |
|
|
<dd>Pairs of <b>D</b>efinition <b>T</b>erm Tags</dd>
|
| 526 |
|
|
<dt><c><dd></c></dt>
|
| 527 |
|
|
<dd>and <b>D</b>efinition <b>D</b>ata Tags</dd>
|
| 528 |
|
|
</dl>
|
| 529 |
|
|
|
| 530 |
|
|
<p>
|
| 531 |
|
|
The following list copied from <uri
|
| 532 |
|
|
link="http://www.w3.org/TR/REC-html40/struct/lists.html">w3.org</uri> shows
|
| 533 |
|
|
that a definition list can contain ordered and unordered lists. It may not
|
| 534 |
|
|
contain another definition list though.
|
| 535 |
|
|
</p>
|
| 536 |
|
|
|
| 537 |
|
|
<dl>
|
| 538 |
|
|
<dt><b>The ingredients:</b></dt>
|
| 539 |
|
|
<dd>
|
| 540 |
|
|
<ul>
|
| 541 |
|
|
<li>100 g. flour</li>
|
| 542 |
|
|
<li>10 g. sugar</li>
|
| 543 |
|
|
<li>1 cup water</li>
|
| 544 |
|
|
<li>2 eggs</li>
|
| 545 |
|
|
<li>salt, pepper</li>
|
| 546 |
|
|
</ul>
|
| 547 |
|
|
</dd>
|
| 548 |
|
|
<dt><b>The procedure:</b></dt>
|
| 549 |
|
|
<dd>
|
| 550 |
|
|
<ol>
|
| 551 |
neysx |
1.53 |
<li>Mix dry ingredients thoroughly</li>
|
| 552 |
|
|
<li>Pour in wet ingredients</li>
|
| 553 |
|
|
<li>Mix for 10 minutes</li>
|
| 554 |
|
|
<li>Bake for one hour at 300 degrees</li>
|
| 555 |
neysx |
1.52 |
</ol>
|
| 556 |
|
|
</dd>
|
| 557 |
|
|
<dt><b>Notes:</b></dt>
|
| 558 |
neysx |
1.53 |
<dd>The recipe may be improved by adding raisins</dd>
|
| 559 |
neysx |
1.52 |
</dl>
|
| 560 |
|
|
|
| 561 |
drobbins |
1.1 |
</body>
|
| 562 |
|
|
</section>
|
| 563 |
|
|
<section>
|
| 564 |
|
|
<title>Intra-document references</title>
|
| 565 |
|
|
<body>
|
| 566 |
|
|
|
| 567 |
swift |
1.15 |
<p>
|
| 568 |
|
|
Guide makes it really easy to reference other parts of the document using
|
| 569 |
drobbins |
1.1 |
hyperlinks. You can create a link pointing to <uri link="#doc_chap1">Chapter
|
| 570 |
|
|
One</uri> by typing <c><uri link="#doc_chap1">Chapter
|
| 571 |
|
|
One</uri></c>. To point to <uri link="#doc_chap1_sect2">section two of
|
| 572 |
|
|
Chapter One</uri>, type <c><uri link="#doc_chap1_sect2">section two of
|
| 573 |
|
|
Chapter One</uri></c>. To refer to figure 3 in chapter 1, type <c><uri
|
| 574 |
swift |
1.40 |
link="#doc_chap1_fig3">figure 1.3</uri></c>. Or, to refer to <uri
|
| 575 |
swift |
1.15 |
link="#doc_chap2_pre2">code listing 2 in chapter 2</uri>, type <c><uri
|
| 576 |
neysx |
1.52 |
link="#doc_chap2_pre2">code listing 2.2</uri></c>.
|
| 577 |
swift |
1.17 |
</p>
|
| 578 |
swift |
1.23 |
|
| 579 |
|
|
<p>
|
| 580 |
|
|
However, some guides change often and using such "counting" can lead to broken
|
| 581 |
|
|
links. In order to cope with this, you can define a name for a
|
| 582 |
neysx |
1.47 |
<c><chapter></c>, <c><section></c> or a <c><tr></c> by using
|
| 583 |
|
|
the <c>id</c> attribute, and then point to that attribute, like this:
|
| 584 |
swift |
1.23 |
</p>
|
| 585 |
|
|
|
| 586 |
|
|
<pre caption="Using the id attribute">
|
| 587 |
|
|
<chapter id="foo">
|
| 588 |
|
|
<title>This is foo!</title>
|
| 589 |
|
|
...
|
| 590 |
|
|
<p>
|
| 591 |
|
|
More information can be found in the <uri link="#foo">foo chapter</uri>
|
| 592 |
|
|
</p>
|
| 593 |
|
|
</pre>
|
| 594 |
swift |
1.17 |
|
| 595 |
|
|
</body>
|
| 596 |
|
|
</section>
|
| 597 |
neysx |
1.51 |
<section>
|
| 598 |
|
|
<title>Disclaimers and obsolete documents</title>
|
| 599 |
|
|
<body>
|
| 600 |
|
|
|
| 601 |
|
|
<p>
|
| 602 |
|
|
A disclaimer attribute can be applied to guides and handbooks to display a predefined disclaimer at the top of the document. The available disclaimers are:
|
| 603 |
|
|
</p>
|
| 604 |
|
|
|
| 605 |
|
|
<ul>
|
| 606 |
|
|
<li>
|
| 607 |
|
|
<b>articles</b> is used for <uri link="/doc/en/articles/">republished
|
| 608 |
|
|
articles</uri>
|
| 609 |
|
|
</li>
|
| 610 |
|
|
<li>
|
| 611 |
|
|
<b>draft</b> is used to indicate a document is still being worked on and
|
| 612 |
|
|
should not be considered official
|
| 613 |
|
|
</li>
|
| 614 |
|
|
<li>
|
| 615 |
|
|
<b>oldbook</b> is used on old handbooks to indicate they are not maintained
|
| 616 |
|
|
anymore
|
| 617 |
|
|
</li>
|
| 618 |
|
|
<li><b>obsolete</b> is used to mark a document as obsolete.</li>
|
| 619 |
|
|
</ul>
|
| 620 |
|
|
|
| 621 |
|
|
<p>
|
| 622 |
|
|
When marking a document as obsolete, you might want to add a link to a new
|
| 623 |
|
|
version. The <c>redirect</c> attribute does just that. The user might be
|
| 624 |
|
|
automatically redirected to the new page but you should not rely on that
|
| 625 |
|
|
behaviour.
|
| 626 |
|
|
</p>
|
| 627 |
|
|
|
| 628 |
|
|
<pre caption="Disclaimer sample">
|
| 629 |
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
| 630 |
|
|
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
|
| 631 |
|
|
<!-- $Header$ -->
|
| 632 |
|
|
|
| 633 |
|
|
<guide link="/doc/en/gentoo-x86-install.xml" disclaimer="obsolete" redirect="/doc/en/handbook/handbook-x86.xml">
|
| 634 |
|
|
<title>Gentoo x86 Installation Guide</title>
|
| 635 |
|
|
|
| 636 |
|
|
<author title="Author">
|
| 637 |
|
|
...
|
| 638 |
|
|
</pre>
|
| 639 |
|
|
|
| 640 |
|
|
</body>
|
| 641 |
|
|
</section>
|
| 642 |
swift |
1.17 |
</chapter>
|
| 643 |
|
|
|
| 644 |
|
|
<chapter>
|
| 645 |
|
|
<title>Coding Style</title>
|
| 646 |
|
|
<section>
|
| 647 |
|
|
<title>Introduction</title>
|
| 648 |
|
|
<body>
|
| 649 |
|
|
|
| 650 |
|
|
<p>
|
| 651 |
|
|
Since all Gentoo Documentation is a joint effort and several people will
|
| 652 |
|
|
most likely change existing documentation, a coding style is needed.
|
| 653 |
|
|
A coding style contains two sections. The first one is regarding
|
| 654 |
swift |
1.45 |
internal coding - how the XML-tags are placed. The second one is
|
| 655 |
swift |
1.17 |
regarding the content - how not to confuse the reader.
|
| 656 |
|
|
</p>
|
| 657 |
|
|
|
| 658 |
|
|
<p>
|
| 659 |
|
|
Both sections are described next.
|
| 660 |
|
|
</p>
|
| 661 |
|
|
|
| 662 |
|
|
</body>
|
| 663 |
|
|
</section>
|
| 664 |
|
|
<section>
|
| 665 |
|
|
<title>Internal Coding Style</title>
|
| 666 |
|
|
<body>
|
| 667 |
|
|
|
| 668 |
|
|
<p>
|
| 669 |
|
|
<b>Newlines</b> must be placed immediately after <e>every</e>
|
| 670 |
|
|
GuideXML-tag (both opening as closing), except for:
|
| 671 |
|
|
<c><version></c>, <c><date></c>, <c><title></c>,
|
| 672 |
|
|
<c><th></c>, <c><ti></c>,
|
| 673 |
|
|
<c><li></c>, <c><i></c>, <c><e></c>,
|
| 674 |
swift |
1.44 |
<c><uri></c>, <c><path></c>, <c><b></c>, <c><c></c>,
|
| 675 |
neysx |
1.37 |
<c><comment></c>, <c><mail></c>.
|
| 676 |
swift |
1.17 |
</p>
|
| 677 |
|
|
|
| 678 |
|
|
<p>
|
| 679 |
|
|
<b>Blank lines</b> must be placed immediately after <e>every</e>
|
| 680 |
|
|
<c><body></c> (opening tag only) and before <e>every</e>
|
| 681 |
|
|
<c><chapter></c>, <c><p></c>, <c><table></c>,
|
| 682 |
swift |
1.18 |
<c><author></c> (set), <c><pre></c>, <c><ul></c>,
|
| 683 |
|
|
<c><ol></c>, <c><warn></c>, <c><note></c> and
|
| 684 |
|
|
<c><impo></c> (opening tags only).
|
| 685 |
swift |
1.17 |
</p>
|
| 686 |
|
|
|
| 687 |
|
|
<p>
|
| 688 |
|
|
<b>Word-wrapping</b> must be applied at 80 characters except inside
|
| 689 |
neysx |
1.51 |
<c><pre></c>. You may only deviate from this rule when there is no other
|
| 690 |
|
|
choice (for instance when a URL exceeds the maximum amount of characters). The
|
| 691 |
|
|
editor must then wrap whenever the first whitespace occurs. You should try to
|
| 692 |
|
|
keep the <e>rendered</e> content of <c><pre></c> elements within 80
|
| 693 |
|
|
columns to help console users.
|
| 694 |
swift |
1.17 |
</p>
|
| 695 |
|
|
|
| 696 |
|
|
<p>
|
| 697 |
neysx |
1.51 |
<b>Indentation</b> may not be used, except with the XML-constructs of which the
|
| 698 |
|
|
parent XML-tags are <c><tr></c> (from <c><table></c>),
|
| 699 |
neysx |
1.53 |
<c><ul></c>, <c><ol></c>, <c><dl></c>, and
|
| 700 |
|
|
<c><author></c>. If indentation is used, it <e>must</e> be two spaces for
|
| 701 |
|
|
each indentation. That means <e>no tabs</e> and <e>not</e> more spaces.
|
| 702 |
|
|
Besides, tabs are not allowed in GuideXML documents.
|
| 703 |
swift |
1.17 |
</p>
|
| 704 |
|
|
|
| 705 |
|
|
<p>
|
| 706 |
neysx |
1.53 |
In case word-wrapping happens in <c><ti></c>, <c><th></c>,
|
| 707 |
|
|
<c><li></c> or <c><dd></c>constructs, indentation must be used for
|
| 708 |
|
|
the content.
|
| 709 |
swift |
1.17 |
</p>
|
| 710 |
|
|
|
| 711 |
|
|
<p>
|
| 712 |
|
|
An example for indentation is:
|
| 713 |
|
|
</p>
|
| 714 |
|
|
|
| 715 |
neysx |
1.37 |
<pre caption="Indentation Example">
|
| 716 |
swift |
1.17 |
<table>
|
| 717 |
|
|
<tr>
|
| 718 |
|
|
<th>Foo</th>
|
| 719 |
|
|
<th>Bar</th>
|
| 720 |
|
|
</tr>
|
| 721 |
|
|
<tr>
|
| 722 |
swift |
1.48 |
<ti>This is an example for indentation</ti>
|
| 723 |
swift |
1.17 |
<ti>
|
| 724 |
|
|
In case text cannot be shown within an 80-character wide line, you
|
| 725 |
swift |
1.48 |
must use indentation if the parent tag allows it
|
| 726 |
swift |
1.17 |
</ti>
|
| 727 |
|
|
</tr>
|
| 728 |
|
|
</table>
|
| 729 |
|
|
|
| 730 |
|
|
<ul>
|
| 731 |
|
|
<li>First option</li>
|
| 732 |
|
|
<li>Second option</li>
|
| 733 |
|
|
</ul>
|
| 734 |
|
|
</pre>
|
| 735 |
|
|
|
| 736 |
|
|
<p>
|
| 737 |
neysx |
1.53 |
<b>Attributes</b> may not have spaces in between the attribute, the "=" mark,
|
| 738 |
|
|
and the attribute value. As an example:
|
| 739 |
swift |
1.17 |
</p>
|
| 740 |
|
|
|
| 741 |
|
|
<pre caption="Attributes">
|
| 742 |
|
|
<comment>Wrong :</comment> <pre caption = "Attributes">
|
| 743 |
|
|
<comment>Correct:</comment> <pre caption="Attributes">
|
| 744 |
|
|
</pre>
|
| 745 |
|
|
|
| 746 |
|
|
</body>
|
| 747 |
|
|
</section>
|
| 748 |
|
|
<section>
|
| 749 |
|
|
<title>External Coding Style</title>
|
| 750 |
|
|
<body>
|
| 751 |
|
|
|
| 752 |
|
|
<p>
|
| 753 |
neysx |
1.53 |
Inside tables (<c><table></c>) and listings (<c><ul></c>,
|
| 754 |
|
|
<c><ol></c>) and <c><dl></c>, periods (".") should not be used
|
| 755 |
|
|
unless multiple sentences are used. In that case, every sentence should end
|
| 756 |
|
|
with a period (or other reading marks).
|
| 757 |
swift |
1.17 |
</p>
|
| 758 |
|
|
|
| 759 |
|
|
<p>
|
| 760 |
|
|
Every sentence, including those inside tables and listings, should start
|
| 761 |
|
|
with a capital letter.
|
| 762 |
|
|
</p>
|
| 763 |
|
|
|
| 764 |
|
|
<pre caption="Periods and capital letters">
|
| 765 |
|
|
<ul>
|
| 766 |
|
|
<li>No period</li>
|
| 767 |
|
|
<li>With period. Multiple sentences, remember?</li>
|
| 768 |
|
|
</ul>
|
| 769 |
|
|
</pre>
|
| 770 |
|
|
|
| 771 |
|
|
<p>
|
| 772 |
|
|
Code Listings should <e>always</e> have a <c>caption</c>.
|
| 773 |
|
|
</p>
|
| 774 |
|
|
|
| 775 |
|
|
<p>
|
| 776 |
|
|
Try to use <c><uri></c> with the <c>link</c> attribute as much as
|
| 777 |
neysx |
1.35 |
possible. In other words, the <uri link="http://forums.gentoo.org">Gentoo
|
| 778 |
|
|
Forums</uri> is preferred over <uri>http://forums.gentoo.org</uri>.
|
| 779 |
swift |
1.15 |
</p>
|
| 780 |
swift |
1.18 |
|
| 781 |
|
|
<p>
|
| 782 |
neysx |
1.37 |
When you comment something inside a <c><pre></c> construct, use
|
| 783 |
|
|
<c><comment></c> and parentheses or the comment marker for the language
|
| 784 |
|
|
that is being used (<c>#</c> for bash scripts and many other things, <c>//</c>
|
| 785 |
|
|
for C code, etc.) Also place the comment <e>before</e> the subject of the
|
| 786 |
|
|
comment.
|
| 787 |
swift |
1.18 |
</p>
|
| 788 |
|
|
|
| 789 |
|
|
<pre caption="Comment example">
|
| 790 |
|
|
<comment>(Substitute "john" with your user name)</comment>
|
| 791 |
|
|
# <i>id john</i>
|
| 792 |
|
|
</pre>
|
| 793 |
drobbins |
1.1 |
|
| 794 |
|
|
</body>
|
| 795 |
|
|
</section>
|
| 796 |
|
|
</chapter>
|
| 797 |
swift |
1.15 |
|
| 798 |
drobbins |
1.1 |
<chapter>
|
| 799 |
swift |
1.25 |
<title>Handbook Format</title>
|
| 800 |
|
|
<section>
|
| 801 |
|
|
<title>Guide vs Book</title>
|
| 802 |
|
|
<body>
|
| 803 |
|
|
|
| 804 |
|
|
<p>
|
| 805 |
|
|
For high-volume documentation, such as the <uri
|
| 806 |
neysx |
1.29 |
link="/doc/en/handbook/handbook-x86.xml?part=1">Installation Instructions</uri>, a
|
| 807 |
swift |
1.25 |
broader format was needed. We designed a GuideXML-compatible enhancement that
|
| 808 |
|
|
allows us to write modular and multi-page documentation.
|
| 809 |
|
|
</p>
|
| 810 |
|
|
|
| 811 |
|
|
</body>
|
| 812 |
|
|
</section>
|
| 813 |
|
|
<section>
|
| 814 |
|
|
<title>Main File</title>
|
| 815 |
|
|
<body>
|
| 816 |
|
|
|
| 817 |
|
|
<p>
|
| 818 |
|
|
The first change is the need for a "master" document. This document contains no
|
| 819 |
|
|
real content, but links to the individual documentation modules. The syntaxis
|
| 820 |
|
|
doesn't differ much from GuideXML:
|
| 821 |
|
|
</p>
|
| 822 |
|
|
|
| 823 |
|
|
<pre caption="Example book usage">
|
| 824 |
|
|
<?xml version='1.0' encoding='UTF-8'?>
|
| 825 |
|
|
<!DOCTYPE book SYSTEM "/dtd/book.dtd">
|
| 826 |
neysx |
1.42 |
<!-- $Header$ -->
|
| 827 |
swift |
1.25 |
|
| 828 |
|
|
<<i>book</i> link="example.xml">
|
| 829 |
|
|
<title>Example Book Usage</title>
|
| 830 |
|
|
|
| 831 |
|
|
<author...>
|
| 832 |
|
|
...
|
| 833 |
|
|
</author>
|
| 834 |
|
|
|
| 835 |
|
|
<abstract>
|
| 836 |
|
|
...
|
| 837 |
|
|
</abstract>
|
| 838 |
|
|
|
| 839 |
|
|
<!-- The content of this document is licensed under the CC-BY-SA license -->
|
| 840 |
neysx |
1.49 |
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
|
| 841 |
swift |
1.25 |
<license/>
|
| 842 |
|
|
|
| 843 |
|
|
<version>...</version>
|
| 844 |
|
|
<date>...</date>
|
| 845 |
|
|
</pre>
|
| 846 |
|
|
|
| 847 |
|
|
<p>
|
| 848 |
|
|
So far no real differences (except for the <c><book></c> instead of
|
| 849 |
|
|
<c><guide></c> tag). Instead of starting with the individual
|
| 850 |
|
|
<c><chapter></c>'s, you define a <c><part></c>, which is the
|
| 851 |
|
|
equivalent of a separate part in a book:
|
| 852 |
|
|
</p>
|
| 853 |
|
|
|
| 854 |
|
|
<pre caption="Defining a part">
|
| 855 |
|
|
<part>
|
| 856 |
|
|
<title>Part One</title>
|
| 857 |
|
|
<abstract>
|
| 858 |
|
|
...
|
| 859 |
|
|
</abstract>
|
| 860 |
|
|
|
| 861 |
|
|
<comment>(Defining the several chapters)</comment>
|
| 862 |
|
|
</part>
|
| 863 |
|
|
</pre>
|
| 864 |
|
|
|
| 865 |
|
|
<p>
|
| 866 |
|
|
Each part is accompanied by a <c><title></c> and an
|
| 867 |
|
|
<c><abstract></c> which gives a small introduction to the part.
|
| 868 |
|
|
</p>
|
| 869 |
|
|
|
| 870 |
|
|
<p>
|
| 871 |
|
|
Inside each part, you define the individual <c><chapter></c>'s. Each
|
| 872 |
|
|
chapter <e>must</e> be a separate document. As a result it is no surprise that a
|
| 873 |
|
|
special tag (<c><include></c>) is added to allow including the separate
|
| 874 |
|
|
document.
|
| 875 |
|
|
</p>
|
| 876 |
|
|
|
| 877 |
|
|
<pre caption="Defining a chapter">
|
| 878 |
|
|
<chapter>
|
| 879 |
|
|
<title>Chapter One</title>
|
| 880 |
|
|
<abstract>
|
| 881 |
|
|
This is a small explanation on chapter one.
|
| 882 |
|
|
</abstract>
|
| 883 |
|
|
|
| 884 |
|
|
<include href="path/to/chapter-one.xml"/>
|
| 885 |
|
|
|
| 886 |
|
|
</chapter>
|
| 887 |
|
|
</pre>
|
| 888 |
|
|
|
| 889 |
|
|
</body>
|
| 890 |
|
|
</section>
|
| 891 |
|
|
<section>
|
| 892 |
|
|
<title>Designing the Individual Chapters</title>
|
| 893 |
|
|
<body>
|
| 894 |
|
|
|
| 895 |
|
|
<p>
|
| 896 |
|
|
The content of an individual chapter is structured as follows:
|
| 897 |
|
|
</p>
|
| 898 |
|
|
|
| 899 |
|
|
<pre caption="Chapter Syntax">
|
| 900 |
|
|
<?xml version='1.0' encoding='UTF-8'?>
|
| 901 |
|
|
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
|
| 902 |
neysx |
1.42 |
<!-- $Header$ -->
|
| 903 |
swift |
1.25 |
|
| 904 |
|
|
<!-- The content of this document is licensed under the CC-BY-SA license -->
|
| 905 |
neysx |
1.49 |
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
|
| 906 |
swift |
1.25 |
|
| 907 |
|
|
<sections>
|
| 908 |
|
|
|
| 909 |
neysx |
1.35 |
<version>...</version>
|
| 910 |
|
|
<date>...</date>
|
| 911 |
|
|
|
| 912 |
swift |
1.25 |
<comment>(Define the several <section> and <subsection>)</comment>
|
| 913 |
|
|
|
| 914 |
|
|
</sections>
|
| 915 |
|
|
</pre>
|
| 916 |
|
|
|
| 917 |
|
|
<p>
|
| 918 |
|
|
Inside each chapter you can define <c><section></c>'s (equivalent of
|
| 919 |
|
|
<c><chapter></c> in a Guide) and <c><subsection></c>'s (equivalent
|
| 920 |
|
|
of <c><section></c> in a Guide).
|
| 921 |
|
|
</p>
|
| 922 |
|
|
|
| 923 |
neysx |
1.35 |
<p>
|
| 924 |
|
|
Each individual chapter should have its own date and version elements. The
|
| 925 |
|
|
latest date of all chapters and master document will be displayed when a user
|
| 926 |
|
|
browses through all parts of the book.
|
| 927 |
|
|
</p>
|
| 928 |
|
|
|
| 929 |
swift |
1.25 |
</body>
|
| 930 |
|
|
</section>
|
| 931 |
|
|
</chapter>
|
| 932 |
|
|
|
| 933 |
|
|
<chapter>
|
| 934 |
drobbins |
1.1 |
<title>Resources</title>
|
| 935 |
|
|
<section>
|
| 936 |
swift |
1.15 |
<title>Start writing</title>
|
| 937 |
|
|
<body>
|
| 938 |
|
|
|
| 939 |
|
|
<p>
|
| 940 |
neysx |
1.35 |
Guide has been specially designed to be "lean and mean" so that developers can
|
| 941 |
|
|
spend more time writing documentation and less time learning the actual XML
|
| 942 |
swift |
1.15 |
syntax. Hopefully, this will allow developers who aren't unusually "doc-savvy"
|
| 943 |
vapier |
1.50 |
to start writing quality Gentoo documentation. You might be interested
|
| 944 |
neysx |
1.35 |
in our <uri link="/proj/en/gdp/doc/doc-tipsntricks.xml">Documentation
|
| 945 |
|
|
Development Tips & Tricks</uri>. If you'd like to help (or have any
|
| 946 |
|
|
questions about guide), please post a message to the <mail
|
| 947 |
|
|
link="gentoo-doc@gentoo.org">gentoo-doc mailing list</mail> stating what you'd
|
| 948 |
swift |
1.15 |
like to tackle. Have fun!
|
| 949 |
|
|
</p>
|
| 950 |
|
|
|
| 951 |
|
|
</body>
|
| 952 |
drobbins |
1.1 |
</section>
|
| 953 |
|
|
</chapter>
|
| 954 |
|
|
</guide>
|