| 1 |
swift |
1.1 |
<?xml version='1.0' encoding='UTF-8'?> |
| 2 |
|
|
|
| 3 |
nightmorph |
1.5 |
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gdp/doc/metadoc-guide.xml,v 1.4 2006/05/23 13:26:41 nightmorph Exp $ --> |
| 4 |
swift |
1.1 |
|
| 5 |
|
|
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> |
| 6 |
|
|
|
| 7 |
|
|
<guide link="metadoc-guide.xml"> |
| 8 |
|
|
<title>Gentoo Metadoc XML Guide</title> |
| 9 |
|
|
|
| 10 |
|
|
<author title="Author"> |
| 11 |
|
|
<mail link="swift@gentoo.org">Sven Vermeulen</mail> |
| 12 |
|
|
</author> |
| 13 |
|
|
|
| 14 |
neysx |
1.2 |
<author title="Editor"> |
| 15 |
|
|
<mail link="neysx@gentoo.org">Xavier Neys</mail> |
| 16 |
|
|
</author> |
| 17 |
|
|
|
| 18 |
swift |
1.1 |
<abstract> |
| 19 |
|
|
This guide informs developers how to use the Metadoc XML format that allows the |
| 20 |
|
|
Gentoo Documentation Project to keep its documentation in a hierarchical manner |
| 21 |
|
|
and allow more information to be stored about each document. |
| 22 |
|
|
</abstract> |
| 23 |
|
|
|
| 24 |
|
|
<!-- The content of this document is licensed under the CC-BY-SA license --> |
| 25 |
|
|
<!-- See http://creativecommons.org/licenses/by-sa/2.0 --> |
| 26 |
|
|
<license/> |
| 27 |
|
|
|
| 28 |
neysx |
1.3 |
<version>1.2</version> |
| 29 |
|
|
<date>2005-04-04</date> |
| 30 |
swift |
1.1 |
|
| 31 |
|
|
<chapter> |
| 32 |
|
|
<title>Introduction</title> |
| 33 |
|
|
<section> |
| 34 |
|
|
<title>Why is MetadocXML Needed?</title> |
| 35 |
|
|
<body> |
| 36 |
|
|
|
| 37 |
|
|
<p> |
| 38 |
|
|
MetadocXML is not needed, it's an additional resource for the Gentoo |
| 39 |
neysx |
1.2 |
Documentation Project to keep track of documents, even if they are located |
| 40 |
|
|
outside of the normal <path>[gentoo]/xml/htdocs/doc</path> scope. |
| 41 |
swift |
1.1 |
</p> |
| 42 |
|
|
|
| 43 |
|
|
<p> |
| 44 |
|
|
Thanks to MetadocXML, we can now |
| 45 |
|
|
</p> |
| 46 |
|
|
|
| 47 |
|
|
<ul> |
| 48 |
|
|
<li> |
| 49 |
nightmorph |
1.5 |
track documents that are located inside project webspaces |
| 50 |
swift |
1.1 |
(<path>/proj</path>) instead of the usual documentation repository |
| 51 |
|
|
(<path>/doc</path>) |
| 52 |
|
|
</li> |
| 53 |
|
|
<li> |
| 54 |
|
|
categorize documentation into various categories (or subcategories) with the |
| 55 |
|
|
additional benefit that we can now automatically generate the documentation |
| 56 |
|
|
index (and more) |
| 57 |
|
|
</li> |
| 58 |
|
|
<li> |
| 59 |
nightmorph |
1.5 |
track unofficial documentation team members (such as translators) |
| 60 |
swift |
1.1 |
</li> |
| 61 |
|
|
<li> |
| 62 |
|
|
use parts of big documents (Handbooks) as individual guides on certain |
| 63 |
|
|
topics |
| 64 |
|
|
</li> |
| 65 |
|
|
<li> |
| 66 |
|
|
assign bugs to particular documents for quick reference and with the |
| 67 |
|
|
possibility of masking out a document in case of a major showstopping bug |
| 68 |
|
|
</li> |
| 69 |
|
|
<li> |
| 70 |
nightmorph |
1.5 |
primitively check if a translated file is in sync with its English |
| 71 |
swift |
1.1 |
counterpart or not |
| 72 |
|
|
</li> |
| 73 |
|
|
</ul> |
| 74 |
|
|
|
| 75 |
|
|
<p> |
| 76 |
|
|
Note that the last advantage is primitive and will probably not be extended. |
| 77 |
|
|
There are more powerful tools (such as Xavier's <uri |
| 78 |
|
|
link="http://dev.gentoo.org/~neysx/trads/trads-doc.html">trads-doc</uri> script) |
| 79 |
nightmorph |
1.4 |
that have many more features than this. |
| 80 |
swift |
1.1 |
</p> |
| 81 |
|
|
|
| 82 |
|
|
<p> |
| 83 |
|
|
Translation teams that do not use MetadocXML yet don't need to worry - they will |
| 84 |
neysx |
1.2 |
not lose any current functionality as it only builds upon the existing |
| 85 |
swift |
1.1 |
infrastructure - there are no changes to the GuideXML format that need |
| 86 |
|
|
MetadocXML. |
| 87 |
|
|
</p> |
| 88 |
|
|
|
| 89 |
|
|
</body> |
| 90 |
|
|
</section> |
| 91 |
|
|
<section> |
| 92 |
|
|
<title>How does MetadocXML Work?</title> |
| 93 |
|
|
<body> |
| 94 |
|
|
|
| 95 |
|
|
<p> |
| 96 |
|
|
There is one central file in which all meta information on the documentation is |
| 97 |
|
|
maintained. We call this file <path>metadoc.xml</path>. This file should be |
| 98 |
|
|
located inside your main repository (<path>/doc/${LANGUAGE}</path>) although |
| 99 |
|
|
this is not hard-coded. |
| 100 |
|
|
</p> |
| 101 |
|
|
|
| 102 |
|
|
<p> |
| 103 |
|
|
Inside this file, all meta information is stored: |
| 104 |
|
|
</p> |
| 105 |
|
|
|
| 106 |
|
|
<ul> |
| 107 |
|
|
<li>Members of the team</li> |
| 108 |
|
|
<li>Categories in which documents participate</li> |
| 109 |
|
|
<li>Files that are covered</li> |
| 110 |
|
|
<li>Documents that are covered</li> |
| 111 |
|
|
<li>Bugs that are part of a document</li> |
| 112 |
|
|
</ul> |
| 113 |
|
|
|
| 114 |
|
|
<p> |
| 115 |
neysx |
1.2 |
Next to <path>metadoc.xml</path>, one also can have a dynamically generated index |
| 116 |
swift |
1.1 |
file (usually called <path>index.xml</path>), an overview listing of all |
| 117 |
|
|
documentation (usually called <path>list.xml</path>) and an overview listing of |
| 118 |
|
|
all members, files and bugs (usually called <path>overview.xml</path>). |
| 119 |
|
|
</p> |
| 120 |
|
|
|
| 121 |
|
|
</body> |
| 122 |
|
|
</section> |
| 123 |
|
|
</chapter> |
| 124 |
|
|
|
| 125 |
|
|
<chapter> |
| 126 |
|
|
<title>The metadoc.xml File</title> |
| 127 |
|
|
<section> |
| 128 |
|
|
<title>XML Structure</title> |
| 129 |
|
|
<body> |
| 130 |
|
|
|
| 131 |
|
|
<p> |
| 132 |
|
|
The <path>metadoc.xml</path> file is started with the usual XML initialisation |
| 133 |
|
|
code and Gentoo CVS header information: |
| 134 |
|
|
</p> |
| 135 |
|
|
|
| 136 |
|
|
<pre caption="XML Initialisation"> |
| 137 |
|
|
<?xml version='1.0' encoding="UTF-8"?> |
| 138 |
|
|
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/metadoc.xml,v 1.25 2004/12/23 09:51:30 swift Exp $ --> |
| 139 |
|
|
<!DOCTYPE metadoc SYSTEM "/dtd/metadoc.dtd"> |
| 140 |
|
|
</pre> |
| 141 |
|
|
|
| 142 |
|
|
<p> |
| 143 |
|
|
Then, one starts with the MetadocXML declaration. |
| 144 |
|
|
</p> |
| 145 |
|
|
|
| 146 |
neysx |
1.2 |
<pre caption="English MetadocXML declaration"> |
| 147 |
swift |
1.1 |
<metadoc lang="<comment>en</comment>"> |
| 148 |
|
|
</pre> |
| 149 |
|
|
|
| 150 |
|
|
<p> |
| 151 |
neysx |
1.2 |
Translators should reference the main <path>/doc/en/metadoc.xml</path> in the |
| 152 |
|
|
<c>parent</c> attribute. This lets metadoc identify untranslated files and find |
| 153 |
|
|
out whether versions of translated versions and originals still match. |
| 154 |
|
|
</p> |
| 155 |
|
|
|
| 156 |
|
|
<pre caption="Translated MetadocXML declaration"> |
| 157 |
|
|
<metadoc lang="<comment>language code</comment>" parent="/doc/en/metadoc.xml"> |
| 158 |
|
|
</pre> |
| 159 |
|
|
|
| 160 |
|
|
<p> |
| 161 |
|
|
Beneath the <c>metadoc</c> entity, the following entities should be declared (in |
| 162 |
swift |
1.1 |
the given order): |
| 163 |
|
|
</p> |
| 164 |
|
|
|
| 165 |
|
|
<ul> |
| 166 |
|
|
<li> |
| 167 |
neysx |
1.3 |
<c>version</c> to help keep track of changes |
| 168 |
|
|
</li> |
| 169 |
|
|
<li> |
| 170 |
swift |
1.1 |
<c>members</c> which declares all members of the given language team |
| 171 |
|
|
</li> |
| 172 |
|
|
<li> |
| 173 |
|
|
<c>categories</c> which declares the possible categories used |
| 174 |
|
|
</li> |
| 175 |
|
|
<li> |
| 176 |
|
|
<c>files</c> which contains all files covered by the Metadoc file |
| 177 |
|
|
</li> |
| 178 |
|
|
<li> |
| 179 |
|
|
<c>docs</c> which contains all documents covered by the Metadoc file |
| 180 |
|
|
</li> |
| 181 |
|
|
</ul> |
| 182 |
|
|
|
| 183 |
|
|
</body> |
| 184 |
|
|
</section> |
| 185 |
|
|
<section> |
| 186 |
neysx |
1.3 |
<title>The Version Entity</title> |
| 187 |
|
|
<body> |
| 188 |
|
|
|
| 189 |
|
|
<p> |
| 190 |
|
|
The version number should be increased when a document or a file is added or |
| 191 |
|
|
removed, when a path is changed or on any update that might have an impact on |
| 192 |
|
|
translated versions. |
| 193 |
|
|
</p> |
| 194 |
|
|
|
| 195 |
|
|
</body> |
| 196 |
|
|
</section> |
| 197 |
|
|
<section> |
| 198 |
swift |
1.1 |
<title>The Members Entity</title> |
| 199 |
|
|
<body> |
| 200 |
|
|
|
| 201 |
|
|
<p> |
| 202 |
|
|
Inside the members entity, one can declare two 'types' of members: <c>lead</c> |
| 203 |
|
|
and <c>member</c>. A <c>lead</c> should be known by the Gentoo Developers |
| 204 |
|
|
Relations as it takes only the nickname of the Lead developer and looks it up in |
| 205 |
|
|
the Gentoo Memberlist. A <c>member</c> can either be a Gentoo Developer (in |
| 206 |
|
|
which case only a nickname is given) or a contributor. |
| 207 |
|
|
</p> |
| 208 |
|
|
|
| 209 |
|
|
<p> |
| 210 |
|
|
In case of a contributor, a <c>member</c> tag is given two attributes, |
| 211 |
|
|
<c>mail</c> and <c>fullname</c>, containing the contributor's e-mail address and |
| 212 |
|
|
full name. |
| 213 |
|
|
</p> |
| 214 |
|
|
|
| 215 |
|
|
<pre caption="Example use of the members entity"> |
| 216 |
|
|
<members> |
| 217 |
|
|
<lead>swift</lead> |
| 218 |
|
|
<lead>neysx</lead> |
| 219 |
|
|
<member>dertobi123</member> |
| 220 |
neysx |
1.3 |
<member mail="gentoo_contributor@gmail.com" fullname="John Doe">jdoe</member> |
| 221 |
swift |
1.1 |
</members> |
| 222 |
|
|
</pre> |
| 223 |
|
|
|
| 224 |
|
|
</body> |
| 225 |
|
|
</section> |
| 226 |
|
|
<section> |
| 227 |
|
|
<title>The Categories Entity</title> |
| 228 |
|
|
<body> |
| 229 |
|
|
|
| 230 |
|
|
<p> |
| 231 |
|
|
Inside the <c>categories</c> entity one only declares <c>cat</c> entities. Each |
| 232 |
|
|
<c>cat</c> entity covers one Category. It uses one mandatory parameter <c>id</c> |
| 233 |
|
|
which is used to reference the category. You can also define a parameter |
| 234 |
|
|
<c>parent</c> in case the category is a child of another category. |
| 235 |
|
|
</p> |
| 236 |
|
|
|
| 237 |
|
|
<p> |
| 238 |
|
|
In this case, the <c>parent</c> attribute references the <c>id</c> attribute of |
| 239 |
|
|
the parent category. |
| 240 |
|
|
</p> |
| 241 |
|
|
|
| 242 |
|
|
<pre caption="Example use of the categories entity"> |
| 243 |
|
|
<categories> |
| 244 |
|
|
<cat id="faq">Frequently Asked Questions</cat> |
| 245 |
|
|
<cat id="install">Installation Related Resources</cat> |
| 246 |
|
|
<cat id="install_guides">Installation Guides</cat> |
| 247 |
|
|
</categories> |
| 248 |
|
|
</pre> |
| 249 |
|
|
|
| 250 |
|
|
</body> |
| 251 |
|
|
</section> |
| 252 |
|
|
<section> |
| 253 |
|
|
<title>The Files Entity</title> |
| 254 |
|
|
<body> |
| 255 |
|
|
|
| 256 |
|
|
<p> |
| 257 |
|
|
The <c>files</c> entity contains only <c>file</c> entities. |
| 258 |
|
|
</p> |
| 259 |
|
|
|
| 260 |
|
|
<p> |
| 261 |
|
|
Each <c>file</c> entity references a single XML file. It has a mandatory |
| 262 |
neysx |
1.2 |
<c>id</c> attribute which should be seen as a primary key to lookup the file. |
| 263 |
|
|
Metadoc will compare the file name defined with the same <c>id</c> attribute in |
| 264 |
|
|
the metadoc's parent file (defined in the root element) to find out whether the |
| 265 |
|
|
file is a translation or an untranslated file. File names would be identical in |
| 266 |
|
|
the latter case. |
| 267 |
swift |
1.1 |
</p> |
| 268 |
|
|
|
| 269 |
neysx |
1.3 |
<p> |
| 270 |
|
|
The metadoc file itself can be listed and will appear on the overview page. |
| 271 |
|
|
</p> |
| 272 |
|
|
|
| 273 |
|
|
<pre caption="Files entity examples"> |
| 274 |
swift |
1.1 |
<files> |
| 275 |
neysx |
1.3 |
<file id="metadoc">/doc/en/metadoc.xml</file> |
| 276 |
|
|
<file id="ati-faq">/doc/en/ati-faq.xml</file> |
| 277 |
swift |
1.1 |
</files> |
| 278 |
|
|
</pre> |
| 279 |
|
|
|
| 280 |
|
|
</body> |
| 281 |
|
|
</section> |
| 282 |
|
|
<section> |
| 283 |
|
|
<title>The Docs Entity</title> |
| 284 |
|
|
<body> |
| 285 |
|
|
|
| 286 |
|
|
<p> |
| 287 |
|
|
The <c>docs</c> entity should only contain <c>doc</c> entities. |
| 288 |
|
|
</p> |
| 289 |
|
|
|
| 290 |
|
|
<p> |
| 291 |
|
|
Each <c>doc</c> entity has a mandatory <c>id</c> attribute which should be seen |
| 292 |
|
|
as a primary key for the document. |
| 293 |
|
|
</p> |
| 294 |
|
|
|
| 295 |
|
|
<p> |
| 296 |
|
|
Inside each <c>doc</c> entity, at least one entity should be available: the |
| 297 |
|
|
<c>fileid</c> entity, which refers to the <c>id</c> attribute of a <c>file</c> |
| 298 |
|
|
entity corresponding with the main file for the document. |
| 299 |
|
|
</p> |
| 300 |
|
|
|
| 301 |
|
|
<p> |
| 302 |
|
|
In case of a handbook chapter, one must refer to the main handbook page (the top |
| 303 |
|
|
handbook XML file). The <c>fileid</c> entity then contains two additional |
| 304 |
|
|
parameters, called <c>vpart</c> and <c>vchap</c> which refer to the |
| 305 |
|
|
corresponding part and chapter of the document inside the handbook. |
| 306 |
|
|
</p> |
| 307 |
|
|
|
| 308 |
|
|
<p> |
| 309 |
|
|
Inside the <c>doc</c> entity, two other entities are possible: |
| 310 |
|
|
</p> |
| 311 |
|
|
|
| 312 |
|
|
<ul> |
| 313 |
|
|
<li> |
| 314 |
nightmorph |
1.5 |
One or more <c>memberof</c> entities, referring to the category or |
| 315 |
|
|
categories in which the document is located (note that a document can be in |
| 316 |
|
|
several categories at once) |
| 317 |
swift |
1.1 |
</li> |
| 318 |
|
|
<li> |
| 319 |
|
|
One <c>bugs</c> entity containing one or more <c>bug</c> entities. A |
| 320 |
|
|
<c>bug</c> entity refers to a bugnumber that covers a bug in the document. |
| 321 |
|
|
In case of a major bug, one can add the attribute <c>stopper="yes"</c> to |
| 322 |
|
|
the <c>bug</c> entity in order for the document not to appear on the |
| 323 |
|
|
generated index page. |
| 324 |
|
|
</li> |
| 325 |
|
|
</ul> |
| 326 |
|
|
|
| 327 |
|
|
<pre caption="Example Docs entity"> |
| 328 |
|
|
<docs> |
| 329 |
|
|
<doc id="handbook_x86"> |
| 330 |
|
|
<memberof>install_guides</memberof> |
| 331 |
|
|
<fileid>handbook-x86</fileid> |
| 332 |
|
|
<bugs> |
| 333 |
|
|
<bug>70753</bug> |
| 334 |
|
|
</bugs> |
| 335 |
|
|
</doc> |
| 336 |
|
|
<doc id="portage-intro"> |
| 337 |
|
|
<memberof>gentoo_portage</memberof> |
| 338 |
|
|
<fileid vpart="2" vchap="1">handbook-x86</fileid> |
| 339 |
|
|
</doc> |
| 340 |
|
|
<doc id="uml"> |
| 341 |
|
|
<memberof>sysadmin_general</memberof> |
| 342 |
|
|
<fileid>uml</fileid> |
| 343 |
|
|
</doc> |
| 344 |
|
|
</docs> |
| 345 |
|
|
</pre> |
| 346 |
|
|
|
| 347 |
|
|
</body> |
| 348 |
|
|
</section> |
| 349 |
|
|
</chapter> |
| 350 |
|
|
|
| 351 |
|
|
<chapter> |
| 352 |
|
|
<title>The Additional MetadocXML Files</title> |
| 353 |
|
|
<section> |
| 354 |
|
|
<title>Automatically Generated Index</title> |
| 355 |
|
|
<body> |
| 356 |
|
|
|
| 357 |
|
|
<p> |
| 358 |
|
|
When you want an automatically generated index, you should start the document |
| 359 |
|
|
with the following code: |
| 360 |
|
|
</p> |
| 361 |
|
|
|
| 362 |
|
|
<pre caption="Dynamically Generated Index"> |
| 363 |
|
|
<?xml version='1.0' encoding='UTF-8'?> |
| 364 |
|
|
<?xml-stylesheet href="/xsl/metadoc.xsl" type="text/xsl"?> |
| 365 |
|
|
<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?> |
| 366 |
|
|
|
| 367 |
|
|
<!-- $Header$ --> |
| 368 |
|
|
|
| 369 |
|
|
<!DOCTYPE dynamic SYSTEM "/dtd/metadoc.dtd"> |
| 370 |
|
|
|
| 371 |
|
|
<comment><!-- Substitute "/doc/en/metadoc.xml" with the location of your metadoc file --></comment> |
| 372 |
|
|
<dynamic metadoc="<i>/doc/en/metadoc.xml</i>"> |
| 373 |
|
|
<title><i>Gentoo Documentation Resources</i></title> |
| 374 |
|
|
<intro> |
| 375 |
|
|
|
| 376 |
|
|
<comment>(...)</comment> |
| 377 |
|
|
|
| 378 |
|
|
</intro> |
| 379 |
|
|
|
| 380 |
|
|
<catid><i>faq</i></catid> |
| 381 |
|
|
<catid><i>install</i></catid> |
| 382 |
|
|
|
| 383 |
|
|
</dynamic> |
| 384 |
|
|
</pre> |
| 385 |
|
|
|
| 386 |
|
|
<p> |
| 387 |
|
|
In between the <c>intro</c> tags you should write one or more sections which |
| 388 |
|
|
will always appear on the top of the page. You will probably want to write an |
| 389 |
|
|
introduction and some additional information for the reader to know who to |
| 390 |
|
|
contact in case of translation mishaps or other issues. |
| 391 |
|
|
</p> |
| 392 |
|
|
|
| 393 |
|
|
<p> |
| 394 |
|
|
Inside the <c>intro</c> tags you can use plain GuideXML starting from |
| 395 |
|
|
<c>section</c>. |
| 396 |
|
|
</p> |
| 397 |
|
|
|
| 398 |
|
|
<p> |
| 399 |
|
|
The <c>catid</c> tags refer to the main categories used by the dynamical index. |
| 400 |
|
|
You should list each possible non-child category that is declared in your |
| 401 |
nightmorph |
1.5 |
metadoc file. <e>Do not list</e> categories that are children of another |
| 402 |
|
|
category. |
| 403 |
swift |
1.1 |
</p> |
| 404 |
|
|
|
| 405 |
|
|
</body> |
| 406 |
|
|
</section> |
| 407 |
|
|
<section> |
| 408 |
|
|
<title>Dynamically Generated List Document</title> |
| 409 |
|
|
<body> |
| 410 |
|
|
|
| 411 |
|
|
<p> |
| 412 |
|
|
A dynamically generated list document starts identically to a dynamically |
| 413 |
|
|
generated index file: |
| 414 |
|
|
</p> |
| 415 |
|
|
|
| 416 |
|
|
<pre caption="Dynamically generated list document"> |
| 417 |
|
|
<?xml version='1.0' encoding='UTF-8'?> |
| 418 |
|
|
<?xml-stylesheet href="/xsl/metadoc.xsl" type="text/xsl"?> |
| 419 |
|
|
<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?> |
| 420 |
|
|
|
| 421 |
|
|
<!-- $Header$ --> |
| 422 |
|
|
|
| 423 |
|
|
<!DOCTYPE dynamic SYSTEM "/dtd/metadoc.dtd"> |
| 424 |
|
|
|
| 425 |
|
|
<comment><!-- Substitute "/doc/en/metadoc.xml" with the location of your metadoc file --></comment> |
| 426 |
|
|
<dynamic metadoc="<i>/doc/en/metadoc.xml</i>"> |
| 427 |
|
|
<title><i>Gentoo Documentation Listing</i></title> |
| 428 |
|
|
</pre> |
| 429 |
|
|
|
| 430 |
|
|
<p> |
| 431 |
|
|
However, there is no <c>intro</c> tag. What needs to be added are all the top |
| 432 |
|
|
categories used by the listing. To differentiate this from the index (which will |
| 433 |
|
|
also display the abstract information on each document) this happens between |
| 434 |
|
|
<c>list</c> tags inside <c>listing</c>: |
| 435 |
|
|
</p> |
| 436 |
|
|
|
| 437 |
|
|
<pre caption="Listing of categories"> |
| 438 |
|
|
<listing> |
| 439 |
|
|
<list>faq</list> |
| 440 |
|
|
<list>install</list> |
| 441 |
|
|
</listing> |
| 442 |
|
|
</pre> |
| 443 |
|
|
|
| 444 |
|
|
</body> |
| 445 |
|
|
</section> |
| 446 |
|
|
<section> |
| 447 |
|
|
<title>Dynamically Generated Overview Document</title> |
| 448 |
|
|
<body> |
| 449 |
|
|
|
| 450 |
|
|
<p> |
| 451 |
|
|
The overview document is started similarly as the two documents decribed above: |
| 452 |
|
|
</p> |
| 453 |
|
|
|
| 454 |
|
|
<pre caption="Dynamically generated overview document"> |
| 455 |
|
|
<?xml version='1.0' encoding='UTF-8'?> |
| 456 |
|
|
<?xml-stylesheet href="/xsl/metadoc.xsl" type="text/xsl"?> |
| 457 |
|
|
<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?> |
| 458 |
|
|
|
| 459 |
|
|
<!-- $Header$ --> |
| 460 |
|
|
|
| 461 |
|
|
<!DOCTYPE dynamic SYSTEM "/dtd/metadoc.dtd"> |
| 462 |
|
|
|
| 463 |
|
|
<comment><!-- Substitute "/doc/en/metadoc.xml" with the location of your metadoc file --></comment> |
| 464 |
|
|
<dynamic metadoc="<i>/doc/en/metadoc.xml</i>"> |
| 465 |
|
|
<title><i>Documentation Development Overview</i></title> |
| 466 |
|
|
</pre> |
| 467 |
|
|
|
| 468 |
|
|
<p> |
| 469 |
|
|
You can again write up a small introduction in GuideXML between the <c>intro</c> |
| 470 |
|
|
XML tags, starting from a <c>section</c> up. Once that is finished, a single tag |
| 471 |
|
|
<c><overview/></c> is sufficient. |
| 472 |
|
|
</p> |
| 473 |
|
|
|
| 474 |
|
|
<pre caption="Intro and overview tags"> |
| 475 |
|
|
<intro> |
| 476 |
|
|
<comment>(...)</comment> |
| 477 |
|
|
</intro> |
| 478 |
|
|
|
| 479 |
|
|
<overview/> |
| 480 |
|
|
</pre> |
| 481 |
|
|
|
| 482 |
|
|
</body> |
| 483 |
|
|
</section> |
| 484 |
|
|
</chapter> |
| 485 |
|
|
|
| 486 |
|
|
</guide> |
Parent Directory
| 
Revision Log