projectdoc Toolbox

A short overview over tools in the projectdoc Toolbox that support authors and information architects to rename elements of their technical documentation.

When working on projects or products, teams continue to learn. It is important to reflect what has been learned in the naming and structure of the produced artifacts.

When software developers understand a concept of the problem domain better, they immediately need to alter their model or maybe just their vocabulary to reflect this better understanding. If they would not alter their views on the domain and reflect this in their artifacts, their solutions would probably be more complex than necessary. The code would not be as easy to understand as it could be.

The same is true for any form of documentation. In case a term or name is not accurate for the referred thing, it probably will evoke an inaccurate understanding of the thing.

These required changes may require refactorings or reengineering. A refactoring is a change that will not alter the external observable behavior. In software development projects changing names of types or methods is a refactoring. In case a change alters the way of processing that will alter the generated output, we speak of reengineering.

In the domain of technical communication, we also refer to changing the name of a document, a property, or the title of a section as refactoring. We may want to extract blocks of a document and move it to its own referenceable document. Or move documents to another space. For these refactorings it is necessary to find all locations in the documentation that refer to the refactored content to check if these referencing locations also need to be altered.

In this topic we show which content elements of the projectdoc domain have names and introduce tools that allow to locate the documents in which these names are used. This article explains refactorings with the projectdoc Toolbox, focusing on naming.

Names and Naming

 

Find more information on names and naming on our blog!

  1. On Names
  2. On Naming

Named Elements

The projectdoc Toolbox uses names to identify elements of the technical communication domain. Some names are referring to a unique element, other names refer to a collection of elements. Looking at names in this domains reveals two contexts of using names:

  1. Context where a name is defined
  2. Context where a name is referenced

Definition of a Name

A name is defined by naming an element of the technical communication. Creating a projectdoc document requires the author to provide a name for that document. Once created other authors can refer to the document by this name. The same is true when adding a property to a document. The property requires a name, and optionally a value. Once added authors may reference the property within a given document by that property name.

Here is a list of elements that can be named within the domain of the projectdoc Toolbox.

ElementDesignator of NameDescription
Unique DocumentIn Confluence this is the title of a page which is also the title of a projectdoc document. The title of a document is unique within a single space.
DocumentThe name of a document is often identical to the title of the document. But they may be different in case two documents within a space require to have the same name. For instance there could be a resource document for a website with the title "Domain Driven Design" and there may be an entry in a glossary in the same space that has also the name "Domain Driven Design".
Property

Each document has a set of properties. Some properties are first class citizens in the domain, other properties are metadata. Some properties are derived from the context and are called artificial properties.

Each property has a name and an optional value. It may also have metadata in form of property controls.

Property ControlA property control is metadata for a property. It controls how a property is perceived. A property control has a name and an optional value.
SectionSection TitleThe title of a section identifies a section within a document. The title of a section is not required to be unique. Multiple sections within a single document may share the same title.
Unique Content

A unique content, which may be a section or a smaller block of content within  a document may be identified uniquely within a document.

Technical the content has an HTML identifier. An identifier of an HTML element is required to be unique. Therefore sections with such an identifier that share the same title show a suffix in their identifiers, such as Description.1 and Description.2.

Content

Content may be tagged by names shared by many contents on the same document. The content tag is defined within macros and may be referenced by other macros.

A typical use case is transclusion. Authors tag a couple of sections with a content tag and refer to that tag by the transclusion macro. The transclusion will render all content tagged with the specified content tags.

MacroMacro Identifier

Macros are identified by their name. All macro instances share that name.

For instance, the name of the Content Marker Macro is projectdoc-content-marker.

Macro ParameterMacros are configured by parameters. A parameter has a mandatory name and a value. The name of the parameter is defined by the author of the macro.
Macro InstanceMacro Instance Identifier

A macro instance is a macro on a document. There may be macro instances of the same macro on a single page. For instance a document typically has multiple sections. Each section is rendered by a Section Macro. Hence there are multiple macros by the name projectdoc-section, but each section macro with its own identity.

CSS Class

A CSS class is a name that references a set of styles that are applied to an element on a document. The CSS class is defined in a stylesheet.

The name of the set of styles can be referenced by a selector. Some macros allow to add names of CSS classes to apply a set of styles.

Referencing a Name

By referencing a named element something needs to be applied to that element or information is fetched from that element.

Most of the defined names can be referenced by macro parameters. Some names, like CSS classes are simply matched by CSS selectors to apply styles. Other names cannot, at least currently, be referenced like property controls or macro names. These names are used internally to control the way processes are executed.

Here are some examples.

  1. The Display Document Property Macro allows to reference a property by its name within a document referenced by its title. The Name List Macro allows to reference a document by its name.
  2. Sections can be referenced by the Transclusion Macro  or  Transclude Documents Macro  by its section title, unique content identifier, or content classes.
  3. Macro instances and macro parameters are referenced by macros supporting Remote Control .

Working with Names

When a name references an element, such as a document, there is a link between the location where the name is mentioned and the document with that name.

When the referencing name is altered, it may be of two reasons.

  1. The location refers to the wrong element. The name is changed to a name that refers to the right element and the issue is resolved. The names of the elements need not to be changed.
  2. The name of the element is wrong. Now it may be that the referencing location refer to the correct element, in which case the reference name needs to be adjusted accordingly. Or the reference has the correct name, but the element with that name does not exist.

The projectdoc Toolbox provides two concepts to deal with the use cases of reason number 2.

Artificial Properties related to Naming

Since version 4.7 of the projectdoc Toolbox naming information is stored in form of artificial properties, named projectdoc Metadata Property.

This information is especially useful for refactoring tasks. To rename an element typically requires to locate all location where this name is currently used. Then the author can decide, which name references must also be altered.

Here is a list of document properties that can be used to query for documents that define a given name.

NameShort DescriptionSince
projectdoc IDs for Document Parts
Lists all used part identifier of a given projectdoc document.
4.7
projectdoc Macro Parameter Names
Lists the parameter names of all macros on a projectdoc document.
4.7
projectdoc Property Names
Lists the names of all properties, excluding projectdoc metadata properties, of a projectdoc document.
4.7
projectdoc Property Values
Lists the values of all properties, excluding projectdoc metadata properties, of a projectdoc document.
4.7
projectdoc Tags for Document Parts
Lists all used part identifier classes or tags of a given projectdoc document.
4.7

Here is a list of document properties that can be used to query for documents that use a given name by reference.

NameData TypeShort DescriptionSince
projectdoc Anchor IDs in Document Part ReferencesContent Identifiers
Lists identifiers used by macros of a projectdoc document to identify anchored content on other documents.
4.7
projectdoc CSS Class ReferencesCSS Classes
Lists all used CSS classes of a given projectdoc document that are mentioned as parameters of projectdoc macros.
4.7
projectdoc Display in Property Name ReferencesProperty Names
Lists the names of all properties that are referenced by a given projectdoc document via display property macros.
4.7
projectdoc Document Name ReferencesDocument Name
Lists the names of all documents that are referenced by a given projectdoc document.
5.0
Document Titles
4.10
projectdoc IDs for Document Part ReferencesContent Identifiers
Lists identifiers used by macros of a projectdoc document to identify content on other documents.
4.7
projectdoc Macro Parameter Name ReferencesMacro Parameter Names
Lists the names of all macro parameters that are referenced by a given projectdoc document.
4.7
projectdoc Macro Parameter Name References in Remote ControlMacro Parameter Name
Lists macro parameter names used in the context of remote controls.
4.7
projectdoc Property Control Name ReferencesProperty Control Names
Lists the control names used by properties of a projectdoc document.
4.7
projectdoc Property Control Value ReferencesProperty Control Values
Lists the control values used by properties of a projectdoc document.
4.7
projectdoc Property Name ReferencesProperty Names
Lists the names of all properties that are referenced by a given projectdoc document.
4.7
projectdoc Select in Property Name ReferencesProperty Names
Lists the names of all properties that are referenced by Select parameters in a projectdoc document.
4.7
projectdoc Sort By in Property Name ReferencesProperty Names
Lists the names of all properties that are referenced by a given projectdoc document in Sort By parameters.
4.7
projectdoc Tags in Document Part References
Lists tags used by macros of a projectdoc document to identify content on other documents.
4.7
projectdoc Tokens in Document Part ReferencesStrings
Lists identifiers and tags used by macros of a projectdoc document to identify content on other documents.
4.7
projectdoc Transclusion IDs in Document Part ReferencesContent Identifiers
Lists identifiers used by macros of a projectdoc document to identify transcluded content on other documents.
4.7
projectdoc Transclusion Tags in Document Part References
Lists tags used by macros of a projectdoc document to identify transcluded content on other documents.
4.7
projectdoc Value References in Remote ControlStrings
Lists all values of remote controls that are not mapped to a property name by a macro parameter name.
4.7
projectdoc Where in Property Name ReferencesProperty Names
Lists the names of all properties that are referenced by Where parameters in a projectdoc document.
4.7

Refactorings

Currently there are not many refactorings that are conducted automatically. A Confluence link, once the title of the referenced document is changed, will be automatically updated.

In all other cases, changing the name of a property, the name of a macro parameter, or the identifier or tag of a text content currently users need to find and update all referencing locations manually.

Here are some examples:

Changing a Property Name

In case the name of a property in the Document Properties Marker Macro is changed, users need to find all documents that refer to that name. The name may be uses in a Display Document Property Macro, in the Select, Where, or Sort By parameter of a Display Table Macro and many other locations.

The artificial property projectdoc Property Name References lists many of the locations that use a specific property.

 

There may be locations that are not reflected by the artificial properties. For instance the use of property names in user macros or in REST clients.

To query for documents using a given property name use the following constraint.

$<projectdoc Property Name References>=[My old Property Name]

Users need to open the documents in the result list of the query and adjust the property name accordingly.

Changing a matching Value

In this example the Where parameter of a Display Table Macro matches a property with a specified value.

Where Constraint
$<Flags>=[Our old Value]

The artificial property projectdoc Property Control Value References lists the locations that use a specific value.

To query for documents using a given value use the following constraint.

$<projectdoc Property Value References>=[Our old Value]

Users need to open the documents in the result list of the query and adjust the property name accordingly.

Changing a Content Tag

In case a tag of a Content Marker Macro is altered, users need to find all documents from which this content is referred to. The projectdoc Tags in Document Part References of each document with such a reference contains this tag.

$<projectdoc Tags in Document Part References>=[my-old-tag]

Users need to open the documents in the result list of the query and adjust the tag name accordingly.

Changing a CSS Class

Users may have a new CSS class to render some tables that are currently rendered with a generic class. Some of the tables that use this class should use the new class.

To find the location where the generic table CSS class is used, use the following in your query.

$<projectdoc CSS Class References>=[our-generic-table]

Users need to open the documents in the result list of the query and adjust the CSS class name accordingly.

Tips working with Names

Here are a couple of tips for users of the projectdoc Toolbox when working with names.

Refer to Self by Placeholder

In case authors want to list documents that refer to the current document by some property should use the placeholder ${Name}.

For instance there is a Risk Severity doctype that needs to list all Change documents with a property named Severity with that value. The value of the Where parameter of the Display Table Macro would read:

$<Doctype>=[change] AND $<Risk>=[${Name}]

Some notes:

  1. For convenience the doctype constraint is typically specified by the Doctype parameter.
  2. In case the property named Risk is changed to Risk Severity or the name of the doctype change is altered to change-request, then the Documentation Architect needs to find all locations where the old names are used.
  3. More information on defining queries is found in Search Tips.

Use Name References in Queries

A Lucene search allows to specify the name of a property to match a given value.

Plain query with Lucene
Risk=high

To allow projectdoc to identify the left hand side of a constraint as a property name, it should be used like this:

Exact match query
$<Risk>=[high]
Exact match list query
$<Risk>~(high, medium)

Only property names that are identified by $<...> or $[...] are recognized as property names. And only then are the values added to the artificial property named projectdoc Property Names and can be found with queries.

Reference Document Name by Transclusion

Transclusion macros allow to render the name of the document from which content is transcluded by the parameter Name as Heading.

Where the Transclude Documents Macro has no alternative approach, the Transclusion Macro may be wrapped inside a Section Macro and add a title manually. By using the Name as Heading parameter the rendered title will always be in sync with the document name.

Publishing Spaces

When working with multiple spaces publishing may be tricky if the publishing tool does not support publishing multiple spaces at once.

The projectdoc Toolbox allows to define delegate spaces for each space. The publishing spaces may define a coherent version of the spaces, while the publishing spaces define another delegate space. The names of the documents in the published and in the working space are the same. Only the space keys are different. In case a document with a dynamic link is copied, the link will automatically find the correct document identified by the name by looking up the space in which the document is stored. This approach requires that the names (in case of theName List Macro which works on names) or title (in case of the Dynamic Document Link Macro which works on titles) of the documents are unique.

Resources

More information on names and related topics.

On Names
A blog post on names. Names are essential since they provide scope and control the artifacts having a name.
On Naming
A blog post on how to find names and use them consistently in projects or products.
Name
Every document instance requires a name that should uniquely identify it within its doctype.
Name and Title
The purpose and the differences between the name and title property of a doctype.