Creating Content

A Technical Document is an instance of the Technical Document ItemType. However, the design of the Technical Documentation Editor enables building documents by aggregation. That is, one Technical Document can include one or more other Technical Documents, which in turn could include other Technical Documents, and so on. Constructing documents in this manner enables content reuse, allows for the separation of content by specialty, and concurrent authoring. Because each Technical Document is a separate Item, each can have their own access rights and evolve through independent workflows / lifecycles.

The content of each Technical Document is determined by the associated Technical Document Type. The Technical Document Type defines a taxonomy; a set of Document Elements along with the allowed hierarchy and cardinality of each. For example, the following diagram describes a simple Technical Document Type.

Figure 16.
The diagram in Figure 3 identifies the following Document Elements:

• Standard-Doc
• Title
• Subtitle
• Section
• Chapter
• TOC-Section
• TOC
• TOC-Item
• Text
• Graphic
• List
• List Item
• Table
• Row
• Entry
• ItemInfo

Each Document Element can either be of type Container, Formatted Text, Unformatted Text, Image, Item, Container – List, Container – List Item, Container – Table, Container – Row, and Container – Cell. These types are described in section Adding Document Elements. Figure 3 also shows allowed hierarchies of Document Elements along with the number and sequence of Document Elements within them. For example, the Standard-Doc Document Element can contain the following Document Elements as direct children: a mandatory Title, an optional Subtitle, and any number (including 0) of Sections in this order. Likewise, if a Section Document Element is added, it must contain a Title followed optionally by either a Text, a Graphic, a List, a Table or an ItemInfo Document Element in any order and in any number (including 0 for each). These simple rules allow for elaborate and complex content structures.

The standard ItemType Classification property can be used to classify the content of a Technical Document. Each Classification value is assigned to the Technical Document ItemType. When used, a single Classification value can be bound to a single Document Element. When a Technical Document instance is created with a Classification value (see Figure 1 for a diagram of the Technical Document Form view) the Technical Document Element will ensure that the top-most node in the Document Element instance hierarchy for the document is set correctly.

For example, assume that an administrator added the Classification value of ‘Document Section’ to the Technical Document Element and associated that classification value with the Document Element ‘Section’. When a Technical Document is created with the classification ‘Document Section’ the Editor will automatically insert a ‘Section’ Document Element as the root in the Document and disallow any peer Document Elements. That is, there will be one root Document Element – Section – only. All child Document Elements will be restricted based on what is defined by the Technical Document Type.

Using Classification in this manner will help in the organization of Technical Document components such that they can be searched more easily. Items with separate Classifications can also have alternate Forms associated with them. When an author would like to reuse a Technical Document, they will know that documents with the corresponding classification value will contain a single root node and thus can be inserted into an existing hierarchy of Document Elements wherever Document Elements of the type of the root node can be.