[ Previous document | Content Table | Next document ]

# 19 IDL Documentation Guidelines

## 19.1 Introduction

The reference manual of the OpenOffice.org API is automatically generated by the tool autodoc from the idl files that specify all types used in the OpenOffice.org API. These files are part of the SDK. This appendix discusses how documentation comments in the idl files are used to create correct online documentation for the OpenOffice.org API.

### 19.1.1 Process

The autodoc tool evaluates the UNOIDL elements and special JavaDoc-like documentation comments of these files, but not the C++/Java-Style comments. For each element that is documented, the preceding comment is used. Put the comment within /** .... */ for multiple-line documentation, or put behind /// for single-line documentation.

| Do not put multiple documentation comments! Only the last will be evaluated for each element and appear in the output. /// This documentation will be lost. /// And this documentation will be lost too. /// Only this line will appear in the output!
--- | ---

Most XHTML tags can be used within the documentation, that is, only tags that occur between the <body>...</body> tags. Additionally, other XML tags are supported and JavaDoc style @-tags can be used. These are introduced later.

It is good practice and thus recommended to build a local version of newly written IDL documentation and browse the files with an HTML client to check if all your layouts appear correctly.

### 19.1.2 File Assembly

Each individual idl file only contains a single type, that is, a single interface, service, struct, enum, constants group or exception. Nested types are not allowed for OpenOffice.orgs local API., even though they are supported by UNOIDL.

### 19.1.3 Readable & Editable Structure

The idl files have to be structured for easy reading and re-editing. Indentation or line-breaks are generated automatically in the output of autodoc , but the simple ASCII layout of the documentation comments has to be structured for readability of the idl files. Due to HTML interpretation, the line-breaks do not appear in the output, except in <pre>...</pre> and similar areas.

The idl files should not contain any #ifdef or #if directives than those mentioned in this document because they are read by the OpenOffice.org community and others. Do not introduce task force or version dependent elements, use CVS branches instead.

Avoid leading asterisks within documentation blocks. Misplaced asterisks must be removed when reformatting is necessary, thus time consuming.

| Do not use leading asterisks as shown here: /* does something special. * * This is just an example for what you must NOT do: Using leading asterisks. */
--- | ---

### 19.1.4 Contents

The idl files should not contain implementation specific information. Always consider idl files as part of the SDK delivery, so that they are visible to customers.

## 19.2 File structure

This chapter provides information about the parts of each idl file, such as the header, body and footer, the character set to be used and the general layout to be applied.

### 19.2.1 General

#### Length of Lines

Lines in the idl files should not be longer than 78 characters, and documentation comment lines should not be longer than 75 characters. The preferable length of lines is upto 70 characters. This makes it readable in any ASCII editor and allows slight changes, that is, due to English proofreading without the need of reformatting.

#### Character Set and Special Characters

Only 7-bit ASCII characters are used in UNOIDL, even in the documentation comments. If other characters are necessary, the XHTML representation is to be used. See http://www.w3.org/TR/xhtml1/DTD/xhtml-special.ent for a list of the encodings.

#### Completeness of Sentences

In general, build grammatically complete sentences. One exception is the first sentence of an elements documentation, it may begin with a lowercase letter, in which case the described element itself is the implied subject.

#### Indentation

The indentation of sub-elements and for others is four spaces for each level of indentation.

#### Delimiters

Each major element has to be delimited by a 75 to 78-character long line from the other major elements. This line consists of “//” followed by equal signs to match the regular expression "^/\*=*$". Place it immediately in the line above the documentation comment that it belongs to.

Major elements are typedef, exception, struct, constants, enum, interface and service.

The sub elements can be delimited by a 75 to 78-character long line matched by the regular expression
"^ \( \)*/\*-*$" from the other minor elements and the major element. This is a line consisting of a multiple of four spaces, followed by “//” and dashes. Place it immediately in the line above the documentation comment that it belongs to. Minor elements are structure and exception fields, methods and properties. Interfaces and services supported by services as single constants are to be grouped by delimiters.

Examples for major and minor elements are given below.

### 19.2.2 File-Header

For legal reasons, the header has to be exactly as shown in the following snippet. Exceptions of this rule are the dynamic parts within "$...$" and the list of contributors at the end.

/*************************************************************************

*

* $RCSfile: IDLDocumentationGuide.fsxw,v $

*

* $Revision: 1.1 $

*

* last change: $Author: jsc $ $Date: 2003/08/13 10:30:59 $

*

* The Contents of this file are made available subject to the terms of

* either of the following licenses

*

* - GNU Lesser General Public License Version 2.1

* - Sun Industry Standards Source License Version 1.1

*

* Sun Microsystems Inc., October, 2000

*

*

* GNU Lesser General Public License Version 2.1

* =============================================

* Copyright 2000 by Sun Microsystems, Inc.

* 901 San Antonio Road, Palo Alto, CA 94303, USA

*

* This library is free software; you can redistribute it and/or

* modify it under the terms of the GNU Lesser General Public

* License version 2.1, as published by the Free Software Foundation.

*

* This library is distributed in the hope that it will be useful,

* but WITHOUT ANY WARRANTY; without even the implied warranty of

* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU

* Lesser General Public License for more details.

*

* You should have received a copy of the GNU Lesser General Public

* License along with this library; if not, write to the Free Software

* Foundation, Inc., 59 Temple Place, Suite 330, Boston,

* MA 02111-1307 USA

*

*

* Sun Industry Standards Source License Version 1.1

* =================================================

* The contents of this file are subject to the Sun Industry Standards

* Source License Version 1.1 (the "License"); You may not use this file

* except in compliance with the License. You may obtain a copy of the

* License at http://www.openoffice.org/license.html.

*

* Software provided under this License is provided on an "AS IS" basis,

* WITHOUT WARRUNTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING,

* WITHOUT LIMITATION, WARRANTIES THAT THE SOFTWARE IS FREE OF DEFECTS,

* MERCHANTABLE, FIT FOR A PARTICULAR PURPOSE, OR NON-INFRINGING.

* See the License for the specific provisions governing your rights and

* obligations concerning the Software.

*

* The Initial Developer of the Original Code is: Sun Microsystems, Inc..

*

* Copyright: 2002 by Sun Microsystems, Inc.

*

* All Rights Reserved.

*

* Contributor(s): _______________________________________

*

*

************************************************************************/

The filename in "$RCSfile: IDLDocumentationGuide.fsxw,v $" is replaced automatically by the version control system, as well as "$Revision: 1.1 $", "$Author: jsc $" and "$Date: 2003/08/13 10:30:59 $". Contributors add their names to the list at the end.

The copyright date has to be adapted to the actual last year of work on the file.

The #ifdef and #define identifiers consist of two underscores "__", the module specification, each nested module separated by a single underscore "_" and the name of the file separated with a single underscore "_" as shown above and trailing two underscores "__".

### 19.2.3 File-Footer

The files do not have a footer with VCS fields. The history can only be viewed from CVS directly. This is to avoid endless expanding log lists.

## 19.3 Element Documentation

### 19.3.1 General Element Documentation

Each element consists of three parts:

1. a summary paragraph with XHTML/XML markups

2. the main description with XHTML/XML markups

3. extra parts formed by @-tags

#### Summary Paragraph

The first part ending with an XHTML paragraph tag, that is, <p>, <dl>, <ul>, <ol> etc.) or "@..." tag, is used as the summary in indexes.

| In contrast to JavaDoc, the first sentence is not used for the summary, but the first paragraph.
--- | ---

The first sentence begins with a lowercase letter if the name of the described element is the implied noun. In this case, the sentence must be logical when reading it with that name. Sometimes an auxiliary verb. in the most cases "is", has to be inserted.

#### Main Description

Between the summary paragraph and the "@..." tag there should be a clear and complete description about the declared element. This part must be delimited from the summary paragraph with an XHTML paragraph tag, including "<dl>" and "<ol>", that are starting a new paragraph.

#### @-Tagged Part

Put the @ tags at the end of each element's documentation. The tags are dependent on the kind of element described. Each of the @-tag ends when the elements documentation ends or the next @-tag begins.

The @author tag is superfluous, because the author is logged by the version control system. They are only used for OpenOffice.org contributions if declarations are taken from other projects, such as Java.

The @version tag, known from JavaDoc, is not valid, because there cannot be more than one version of any UNOIDL element, due to compatibility.

On the same line behind the @-tag, only a single structural element is allowed. The parameter name is @param without the type and any attributes, the qualified exception is @throws , the qualified type is @see, and the programming language is @example. The @returns is by itself on the same line.

| Do not put normal text behind an @-tag on the same line: /** ... @param nPos put nothing else but the argument name here! it is correct to put your documentation for the parameter here. @throws com::sun::star::beans::UnknownPropertyException nothing else here! when <var>aName</var> is not a known property. */
--- | ---

### 19.3.2 Example for a Major Element Documentation

Each major element gets a header similar to the example shown below for an interface:

//===========================================================================

/** controls lifetime of the object. Always needs a specified object owner.

<p><em>Logical</em> "Object" in this case means that the interfaces

actually can be supported by internal (i.e. aggregated) physical

objects. </p>

@see com::sun::star::uno::XInterface

for further information.

*/

interface XComponent: XInterface

{

### 19.3.3 Example for a Minor Element Documentation

Each minor element gets a header similar to the example shown below for a method:

//------------------------------------------------------------------------

/** adds an event listener to the object.

<p>The broadcaster fires the disposing method of this listener if

the <method>XComponent::dispose()</method> method is called. </p>

@param xListener

refers the the listener interface to be added.

@returns

<TRUE/> if the element is added, <FALSE/> otherwise.

@see removeEventListener

*/

boolean addEventListener( [in]XEventListener xListener );

## 19.4 Markups and Tags

### 19.4.1 Special Markups

These markup tags are evaluated by the XSL processor that generates a layout version of the documentation, that is, into HTML or XHTML. These tags have to be well formed andin pairs with exactly the same upper and lowercase, as well.

To accentuate identifiers in the generated documentation and generate hyperlinks automatically when building the cross-reference table and checking consistency, all identifiers have to be marked up. Additionally, it is important for proofreading, because a single-word method name cannot be distinguished by a verb. Identifiers have to be excluded from re-editing by the proofreading editor.

The following markups are used:

#### <atom>

This markup is used for identifiers of atomar types, such as long, short, and string. If a sequence or array of the type is referred to, add the attribute dim with the number of bracket-pairs representing the number of dimensions.

Example:

<atom>long</atom>

For an example of sequences, see <type>.

#### <type>

This markup is used for identifiers of interfaces, services, typedefs, structs, exceptions, enums and constants-groups. If a sequence or array of the type is referred to, add the attribute dim with the number of bracket-pairs representing the number of dimensions.

Example:

<type scope="com::sun::star::uno">XInterface</type>

<type dim="[][]">PropertyValue</type>

#### <member>

This markup substitutes the deprecated method, field and property markups, and is used for fields of structs and exceptions, properties in service specifications and methods of interfaces.

Example:

<member scope="com::sun::star::uno">XInterface::queryInterface()</member>

#### <const>

This markup is used for symbolic constant identifiers of constant groups and enums.

Example:

<const scope="...">ParagraphAdjust::LEFT</const>

#### <TRUE/>, <FALSE/>

These markups represent the atomic constant for the boolean values TRUE and FALSE.

Example:

@returns

<TRUE/> if the number is valid, otherwise <FALSE/>.

#### <NULL/>

This markup represents the atomic constant for a NULL value.

#### <void/>

This markup represents the atomic type void. This is identical to <atom>void</atom>.

#### <code>

This markup is used for inline code.

Example:

Use <code>queryInterface( NULL )</code> for:

<listing>

This markup is used for multiple line code examples.

Example:

@example StarBASIC

<listing>

aCmp = StarDesktop.loadComponentFromURL( ... )

if ( isnull(aCmp) )

....

endif

</listing>

### 19.4.2 Special Documentation Tags

This group of special tags are analogous to JavaDoc. Only what has previously been mentioned in this guideline can appear in the line behind these tags. The pertaining text is put into the line following . Each text belonging to a tag ends with the beginning of the next special tag ("@") or with the end of the documentation comment.

#### @author Name of the Author

This tag is only used if an element is adapted from an externally defined element, that is, a Java class or interface. In this case, the original author and the in-house author at Sun Microsystems is mentioned.

Example:

@author John Doe

#### @see qualifiedIdentifier

This tag is used for extra cross references to other UNOIDL-specified elements. Some are automatically generated, such as all methods using this element as a parameter or return value, and services implementing an interface or include another service. If there is no other method that should be mentioned or an interface with a similar functionality, it should be referenced by this @see statement.

A @see-line can be followed by further documentation.

Example:

@see com::sun::star::uno::XInterface::queryInterface

For this interface you have always access to ...

| Do not use markups on the identifier on the same line behind the @see-tag! /** ... @see <type>these markups are wrong</type */
--- | ---

#### @param ParameterName

This tag describes the formal parameters of a method. It is followed by the exact name of the parameter in the method specification. The parameter by itself may be the implicit subject of the following sentence, if it begins with a lowercase letter.

Examples:

@param xListener

contains the listener interface to be added.

@param aEvent

Any combination of ... can be used in this parameter.

#### @return/@returns

This tag starts the description of the return value of a method. The description is in the line folloiwng. If it begins with a lowercase letter, the method is the implied subject and "returns" is the implied verb. See the following example:

@returns

an interface of an object which supports

the <type>Foo</type> service.

#### @throws qualifiedException

This tag starts the description of an exception thrown by a method in a particular case. The exception type is stated behind in the same line and must be fully qualified, if it is not in the same module. The description is in the line following. If it begins with a lowercase letter, the method is the implied subject and "throws" is the implied verb.

Example:

@throws com::sun::star::uno::lang::InvalidArgumentException

if the specified number is not a specified ID.

#### @version VersionNumber

This was originally used to set a version number for the element. This tag is deprecated and should not be used.

### 19.4.3 Useful XHTML Tags

Only a few XHTML tags are required for writing the documentation in idl files. The most important ones are listed in this section.

#### Paragraph: <p> ... </p>

This tag marks a normal paragraph. Consider that line breaks and empty lines in the idl file do not cause a line break or a paragraph break in the layout version. Explicit paragraph break markups, are necessary.

| Do not use <br/> or CR/LF for marking paragraphs. CR and LF are ignored, except within <pre>...</pre> and <listing>...</listing> areas. The <br/> tag is only for rare cases of explicit linebreaks. /** does this and that. This sentence should start with a "&lt;p&gt;". If not, it still belongs to the previous paragraph! This still belongs to the first paragraph. <br/> As this sentence is as well! */ Consider using &lt; for < and &gt; for >, as shown in the example above.
--- | ---

#### Line Break: <br/>

This tag marks up a line break within the same paragraph. Consider line breaks and empty lines in the idl file do not cause a line break or a paragraph break when presented by the HTML browser. Explicit paragraph break markups are necessary.

#### Unordered List: <ul><li> ... </li>... </ul>

These tags mark the beginning and end of an unordered list, as list items.

Example:

<ul>

<li>the first item </li>

<li>the second item </li>

<li>the third item </li>

</ul>

results in a list similar to:

- the first item

- the second item

- the third item

#### Ordered List: <ol><li> ... </li>... </ol>

These tags mark the beginning and end of an ordered list, as list items.

Example:

<ol>

<li>the first item </li>

<li>the second item </li>

<li>the third item </li>

</ol>

results in a list similar to:

1.the first item

2.the second item

3.the third item

#### Definition List: <dl><dt> ... </dt><dd> ... </dd>... </dl>

These tags mark the beginning and end of a definition list, the definition tags and the definition data.

Example:

<dl>

<dt>the first item</dt>

<dd>asfd asdf asdf asdf asdf</dd>

<dt>the second item</dt>

<dd>asfd asdf asdf asdf asdf</dd>

<dt>the third item</dt>

<dd>asfd asdf asdf asdf asdf</dd>

</dl>

results in a list similar to:

the first item

asfd asdf asdf asdf asdf

the second item

asfd asdf asdf asdf asdf

the third item

asfd asdf asdf asdf asdf

#### Table: <table><tr><td>...</td>...</tr>...</table>

Defines a table with rows (tr) and columns (td).

#### Strong Emphasis: <strong> ... </strong>

These tags present a piece of text that is emphasized. In most cases this is bold, but the HTML-client defines what it actually is.

#### Slight Emphasis: <em> ... </em>

These tags present a piece of text emphasized slightly. In most cases this is italic, but the HTML-client defines what it actually is .

#### Anchor: <a href="..."> ... </a>

These tags specify a link to external documentation. The first "..." specifies the URL.

[ Previous document | Content Table | Next document ]