GDP Documentation Guidelines

5.1. XML Requirements

All GNOME documentation should conform to XML syntax requirements, which are stricter than SGML ones.

5.2. Section IDs

Section IDs are unique identifiers that you assign to each section of an XML file. You can use the section IDs to cross-reference sections.

The following sections contain suggestions as to how to write section IDs in XML files. The only real requirement for writing section IDs is that the IDs must be unique within a document.

5.2.1. How to Tag a Section ID in XML

Use the id attribute with the <sect> tag. For example:

<sect1 id="gedit-intro">.

5.2.2. How to Structure Section IDs in Online Help

These guidelines do not apply to the top-level ID associated with the <article> tag in a help manual, that is:

<article id="index" lang="en">

Use the following guidelines to write consistent section IDs in documentation:

  1. Form the first part of each ID using the filename of the XML file for the documentation. For example, if the filename of the XML book file is gedit.xml, the first part of each section ID is “gedit”. Likewise, if the name of the XML file is gnome-dictionary.xml, the first part of the section ID is “gnome-dictionary”.

  2. Follow the first part of the ID with a hyphen. For example:

    gedit-

    gnome-dictionary-

  3. If the section ID is a table section ID, follow the first part of the ID with “TBL-”:

    gedit-TBL-

  4. If the section ID is a figure section ID, follow the first part of the ID with “FIG-”:

    gedit-FIG-

  5. Form the remainder of the ID using an abbreviated form of the section title. Here are some examples:

    • If the title of the section is “Introduction”, use “gedit-intro”.
    • If the title of the section is “Preferences”, use “gedit-prefs”.
    • If the title of the section is “Save Tabbed Section”, which is a subsection of “Preferences”, you can use “gedit-prefs-save”.
    • If the title of the section is “To Save a File”, use an ID similar to “gedit-save-file”.
    • If the title of a figure is “gedit Main Window”, use an ID similar to “gedit-FIG-main-window”.

    The important thing is that all section IDs are unique within each XML file.

5.2.3. When to Change Section IDs for Online Help

If you receive a request from the developer of an application or applet to change the name of the XML file for a manual, you should also change the section IDs in your document to match the new filename. For example, if the Fish Applet is renamed the Wanda Applet and the filename changes from fish.xml to wanda.xml, you should change the first part of each section ID from “fish-” to “wanda-”.

Do not change the XML filename or section IDs without the approval of the developer as this impacts the help calls from the application to the online help manuals.

5.2.4. How to Structure Section IDs in a Book

Use the following guidelines to write consistent section IDs in a book:

  1. Form the first part of every ID using the name of the XML file that the ID is located in. For example, for a file called windows.xml, use “windows”.

  2. Follow the first part of the ID with a hyphen:

    windows-

  3. If the section ID is a table section ID, follow the first part of the ID with “TBL-”:

    windows-TBL-

  4. If the section ID is a figure section ID, follow the first part of the ID with “FIG-”:

    windows-FIG-

  5. Complete the section ID with a number that uniquely identifies the section ID:

    windows-123

    windows-TBL-456

    windows-FIG-789

It is important that all section IDs are unique within all the XML files in the book.

5.2.5. When to Change Section IDs in a Book

If you change the name of a book file, you should change the section IDs to match the new filename. For example, if the windows.xml file is renamed dialogs.xml, you should change the first part of the section IDs to “dialogs-”.

Changing section IDs in a book might affect online help calls. Contact the developer responsible for the help calls before you change any section IDs. If there are negative implications associated with changing the section IDs, you should not change the IDs to match the filename.

5.3. Authors' Names

All GNOME documentation should contain the names of all documentation authors who have worked on the document. The email address of all authors should also be included. Even if you totally rewrote the documentation you still need to include the names of any authors of previous documentation for the specific application, applet, component, or widget.

5.4.  Copyright Information

Application documentation should contain a copyright notice, stating the licensing terms. It is suggested that you use the GNU Free Documentation License. You could also use some other license allowing free redistribution, such as GPL or Open Content license. If documentation uses some trademarks (such as UNIX, Linux, Windows, etc.), proper legal junk should also be included (see templates).

If there is existing documentation then the author's copyright notice and license must be used. This is to ensure that licenses and copyrights stay intact from version to version of the application and documentation.

If you decide to use the GNU Free Documentation License, then all you need to do include the file legal.xml as a system entity (see templates). Otherwise you need to mark up the license you are going to use and include it in place of legal.xml.

5.5. Revision History

All GNOME documentation should contain the names of all previous documentation titles along with the current title for the documentation. The current documentation title should indicate the version of the documentation. The revision history should also contain the authors and their email addresses for the documentation they wrote and the publisher of the documentation. This allows anybody to see how many revision the current documentation has undergone.

The revision history can also contains notes in the description for the specific version of the documentation. If the author rewrote the documentation from scratch this should be indicated in the revision description. Any extra descriptions need to be carried over to a new version of the documentation — see the templates for an example.

5.6. Application Version Identification

Application documentation should identify the version of the application for which the documentation is written. This information should be included in the <releaseinfo> tag:

<releaseinfo>
This manual describes version 1.56 of gfoobar.
</releaseinfo>
	  

5.7. Publisher's Name

All GNOME documentation must include information about the publisher of the document. This will always be the GNOME Documentation Project (see templates).

5.8. GNOME Documentation Style Guide

The GNOME Documentation Style Guide should be followed at all times in writing and editing GNOME Documentation. It contains writing tips, word usage, and grammatical errors common in technical writing. You should read it before you start writing and use it as the authoritative resource for writing style. To obtain a copy of the GNOME Documentation Style Guide go to http://library.gnome.org/devel/gdp-style-guide/stable to view it.

5.9. Software License

All GNOME applications must contain information about the license (for software, not for documentation), either in the “About” box or in the manual.

5.10.  Bug Reporting

Application documentation should give an address for reporting bugs and for submitting comments about the documentation (see templates for an example).