The docstrings will be formatted in as terse syntax as possible. Required tags, syntax, and white space should be minimized.

The tool must support the use of Traits. Special comment syntax for Traits may be necessary. Information about the Traits package is available at http://code.enthought.com/traits/. In the following example, each trait definition is prefaced by a plain comment:

__traits__ = {

# The current selection within the frame.
'selection' : Trait([], TraitInstance(list)),

# The frame has been activated or deactivated.
'activated' : TraitEvent(),

'closing' : TraitEvent(),

# The frame is closed.
'closed' : TraitEvent(),
}

Support for ReStructuredText (ReST) format is desirable, because much of the existing docstrings uses ReST. However, the complete ReST specification need not be supported, if a subset can achieve the project goals. If the tool does not support ReST, the contractor should also provide a tool or path to convert existing docstrings.

The navigation scheme for the HTML files should not rely on frames, and should harmonize with conversion to Microsoft HTML Help (.chm) format.

The output should be structured to make navigable the architecture of the Python code. Packages, modules, classes, traits, and functions should be presented in clear, logical hierarchies. Diagrams or trees for inheritance, collaboration, sub-packaging, etc. are desirable but not required.

The output must include indexes that provide a comprehensive view of all packages, modules, and classes. These indexes will provide readers with a clear and exhaustive view of the code base. These indexes should be presented in a way that is easily accessible and allows easy navigation.

Cross-references to other documented elements will be used throughout the documentation, to enable the reader to move quickly relevant information. For example, where type information for an element is available, the type definition should be cross-referenced.

The HTML suite should provide consistent navigation back to the home page, which will include the following information:

• Bibliographic information
  • Author
  • Copyright
  • Release date
  • Version number
• Abstract
• References
  • Links to related internal docs (i.e., other docs for the same product)
  • Links to related external docs (e.g., supporting development docs, Python support docs, docs for included packages)

It should be possible to specify similar information at the top level of each package, so that packages can be included as appropriate for a given application.