projectdoc Toolbox

Features of the projectdoc Toolbox

The list of features of the projectdoc Toolbox on a single page.

Or step through at your own pace using the presentation with Prezi !

See projectdoc Introduction for more information on all the topics in the video!

Document Types

Document types allow to guide authors producing information of a given type. They also help readers to find the information they are looking for quickly.

If you start a new document from scratch you have to think about a lot of things. Since you are adding a page to a wiki some of the decisions have already been made for you. Less freedom in this context is actually a good thing! Authors are experts with important information on their minds that needs to be turned into an externalized form to communicate with stakeholder and team members (including the author's future self).

Document types are page blueprints or templates with some extras. This includes homepages for doctypes and navigation to related document types.

Style already defined

A decision that is already made is the layout of the pages. Authors using a wiki typically do not need to bother with decision. There is one, sometimes more, templates for applying styles. Even if there are more than one, it is usually pretty clear which one to apply in a given situation.

Structure somewhat defined

Form follows function. So authors usually expect freedom on how the document is structured to pass the information effectively to the reader. But on the other hand the reader expects similar information to be presented similar. The reader should also not notice which author has actually written the document.

Therefore authors need tools to help them to align the new document with the existing documentation and the expectation of the readers seamlessly. A template can help. But we must not force the authors to follow the structure of the template mindlessly. The authors are still in charge to create the structure that delivers the information best, but the template is a guide to allow the authors to follow if no better solution is at hand.

Here are some structures a template defines that are usually best kept in sync with other documents.

  • Properties of document types
    • Names of properties
    • Values of properties
    • Order of properties
  • Sections of document types
    • Name of the sections
    • Order of the sections

Usually these rules can be followed without any negative influences on the readability.The authors must not be forced to follow this structure. If a value of a property is not available and not important for comprehension, it must be left off. If a specific section is irrelevant or may not provide further understanding, it is important to leave it blank. Do not add any decoy text. If a paragraph, sentence, or even a single word does make the point clearer then drop it. In some cases it may also add to the understanding of a document, if sections are set in a different order or the content of several sections is written to one with an individual title.

Last but not least we are not writing to win the Pulitzer Prize for literary achievements. There are certain kinds of documents that are best consumed if they follow a rigid structure. Glossary items do not gain much appreciation if every entry presents its information in an arbitrary sequence. Meeting minutes are best parsed by readers if they follow a predefined structure. Every document that comes in numbers, that are aggregated in a number of views benefit the reader if they are similarly structured.

Content marginally defined

If the information in the document is not genuine, there is no entitlement for it to exist. So there is no constraint on the content with the exception of controlled vocabulary and probably a style guide. Again this is necessary to provide a consistent documentation for the reader with the least surprise according style, structure, and content.

Homepages

A homepage is a page that lists instances of a document type in a hierarchy. Besides the homepage there may be Confluence's index pages, which list all documents of that type in a flat list.

A homepage typically also provides links to more information on this doctype online and links to homepages of related doctypes.

Resources

More information on this feature.

projectdoc Document
projectdoc is based on projectdoc documents. Creating a projectdoc document is easy: A projectdoc document is a Confluence page using document properties and sections.
Doctypes
Doctypes define properties and sections for documents. They are essentially Confluence Blueprints that help to create pages in your wiki based on templates.
Guided Writing & clutter-free Reading
Do not clutter the view with non-information sections. Instead help authors writing identical structured content by the use of templates.
Extensible by Spaces, Templates, and Macros
Never be limited to the vendor's ideas: Create your own spaces, templates/blueprints/doctypes and macros based on components provided by the projectdoc Toolbox!
Section Macro
Renders a section, if the body is not empty. Supports authors to create content, clutter-free rendering without empty sections. Allows to transclude the content.
Document Properties Marker Macro
A table containing document properties. Three columns: name, value and meta data (aka controls) to a property.
Doctype Maven Plugin
Create doctype add-ons (OBRs) for the projectdoc Toolbox with Confluence Blueprints based on XML model descriptions easily!

Rich Custom Document Metadata

Authors may add any metadata to a document and use these in their queries. The metadata may be displayed or hidden. This way authors can use metadata target at the reader and metadata used for authoring purpose.

The metadata for a document is specified by the use of the Document Properties Marker Macro. Each piece of metadata is called a document property, consisting of a name, a value, and document property controls.

The metadata can be used by query macros like the Display Table Macro or the Transclude Documents Macro to select on projectdoc Documents.

Properties can also be transcluded by the use of the for instance by the Display Document Property Macro and Display Document Properties Macro.

Resources

More information on this feature.

Document Properties Marker Macro
A table containing document properties. Three columns: name, value and meta data (aka controls) to a property.
projectdoc Document
projectdoc is based on projectdoc documents. Creating a projectdoc document is easy: A projectdoc document is a Confluence page using document properties and sections.
Document Property
Document the usage of a document property for your users.
Document Property Controls
Lists valid controls for properties to be used in document properties tables.
Dynamic Linking
A document template that uses query macros enables documents to dynamically render links to a set of related documents. If new documents are added to the system that meet the query criteria, links to these documents are automatically added to the querying document. This feature is also called dynamic lists or automatic linking.
Transclusion
The technique to render parts of one document within another document.
Display Document Property Macro
Renders the value of a property of a document.
Display Document Properties Macro
Renders a template with property references.

Enhanced Transclusion

Transclude more than one self-contained snippet and mark transcluded information for authors. The projectdoc toolbox allows multi-transclusion from one document and even several documents.

The projectdoc Toolbox provides macros to transclude elements from a document into another document. These elements may be properties or sections / marked content. There is no limitation on the number of properties and sections to transclude.

Transclusion is the technique to render parts of one document within another document.

The inclusion of part of one hypertext document in another one by means of reference rather than copying.

Wiktionary. transclusion

The projectdoc Toolbox provides macros to define content within a document to be transcluded (by the use of the Section Macro and the Content Marker Macro) and macros to transclude this content into a document (for instance Transclusion Macro and Transclude Documents Macro).

Excerpt and multi-excerpt

 

Users of Confluence know transclusion support by the Excerpt Macro and the Excerpt Include Macro. The article Excerpt and Transclusion compares the features of the native Confluence macros with those of the projectdoc Toolbox.

Checkout Compare with built-in Features to learn more about the differences between built-in features of Confluence and features of the projectdoc Toolbox.

Note that the projectdoc Toolbox makes it easy to list documents that transclude from a document (see Module) and there are tools for authors (see Transclusion Box) to make jumping to transcluded content very easy.

Resources

More information on this feature.

Transclusion
Tools to provide or consume content to support reuse.
Content Reuse
The projectdoc Toolbox provides a number of features to help teams to reuse content. Content can be transcluded individually or in form of a multitransclude. Authors can even transclude content from multiple documents in the wiki, effectively combining transclusion with automatic lists.
Multi-transclusion
Describes the technique to transclude one or more content fragments from one or more documents.
Multi-excerpt
The term is used by Confluence to describe the technique to transclude one or more content fragments from one or more documents.

Dynamic Linking

A document template that uses query macros enables documents to dynamically render links to a set of related documents. If new documents are added to the system that meet the query criteria, links to these documents are automatically added to the querying document. This feature is also called dynamic lists or automatic linking.

Dynamic linking allows to render links dependent on the context. This can be a single link or a list of links as shown in the following screenshot.

You specify queries like this:

SELECT PropertyOne, PropertyTwo, PropertyFour
WHERE PropertyOne = "Some String" AND 
        (PropertyTwo = "Another String" OR PropertyFive = "Something")
SORT BY PropertyOne, PropertyThree

Note that this is pseudo syntax. The values for SELECT, WHERE and SORT BY are passed to the macros as parameters.

Dynamic linking is supported with

Display List Macro
Lists references to projectdoc documents in a list. List contain names and optional short descriptions.
Display List Template Macro
Lists references to projectdoc documents in a list. List items are defined by templates referencing properties.
Display Table Macro
Lists references to projectdoc documents in a table. Allows to select document properties for columns. Also non-list representations are provided.
Index Card Macro
Renders transcluded content fetched from documents of a result set.
Index Entries Table Macro
Renders a table of index entries.
Transclude Documents Macro
Renders transcluded content fetched from documents of a result set.

Resources

More information on this feature.

Dynamic List
Tools to render information based on queries at view-time.
Glossary
Terms used in and defined for projectdoc.
Dynamic List
In the glossary: Enhances navigation by showing a list of links to related information that is the result of a query on document properties.
Rendering Navigation Links
There are basically five ways to render navigation links with additional properties with the projectdoc Toolbox.
Dynamic Links
Build a navigation to related and associated information by the use of document properties and dynamic linking.

Guided Writing & clutter-free Reading

Do not clutter the view with non-information sections. Instead help authors writing identical structured content by the use of templates.

A template typically puts a demand on the author: fill out everything! Or remove what you did not fill out now! Neither is appreciated. The authors have a set of information in their minds they want to contribute. Maybe the document is created collaboratively. Certainly it is created iteratively. This especially applies to project documentation, where the team writes for the team. In this case the documentation is typically never finished. Rather the documents are in different states of the iteration cycle. Yet the information provided is already relevant for other team members. Do we want our readers to be confronted with empty sections only attached to a decoy title? Do we add value by some decoy text like "TBD"? On the other hand, if the boiler plate parts are removed, we have no access to them when we or other teammates need it.

The result of this feature is that an author is provided with support adding relevant information at the expected positions and also has guidance according to what information may be relevant for my audience for this kind of document. On the other hand the reader is only seeing section with actual content. The same is true for properties.

  • Properties are only rendered, if they provide a non-blank value
  • Sections are only rendered, if the body has actually content

As a screenshot this feature looks like this:

In edit mode the authors have access to the structure that is defined by the template. The authors decide which information they need to add to the document and stores it at the defined locations. They may add any number of additional properties or sections. Any properties or sections that are not yet (or never relevant), are left empty. Once the document is saved, only those properties and sections are presented to the reader that actually contain relevant information. On the left side there is the view of an editor with sections that have content or have no content. On the right side you see what reader's see in view mode. Sections with no content are not rendered.

The Section Macro allows to define possible information for a given doctype at a defined position within the document. Typically this section contains text supporting the author to know which information is expected by the reader for each section. The Section Macro also allows to link to more information by the use of the help button (marked with the image of a question mark (question)).

Resources

More information on this feature.

Section Macro
Renders a section, if the body is not empty. Supports authors to create content, clutter-free rendering without empty sections. Allows to transclude the content.
documentation-json-uri
The URI to a JSON document containing the URLs to the documentation for the blueprints.
DocumentationMap
Stores the documentation map to link to doctype documentation.
Content Marker Macro
Marks a piece of content within a document. This content can be referenced for transclusion.
Document Types
Document types allow to guide authors producing information of a given type. They also help readers to find the information they are looking for quickly.
Extensible by Spaces, Templates, and Macros
Never be limited to the vendor's ideas: Create your own spaces, templates/blueprints/doctypes and macros based on components provided by the projectdoc Toolbox!

Space Properties

Properties may be set on space level and are inherited through space hierarchies.

Document properties defined on the space homepage are called space properties. Space properties may be defined via space properties extensions, so that they can be defined on other pages. Space property values may contain placeholders to reference other space property. Space properties are inherited via delegate spaces.

Space properties can be accessed with the Display Space Property Macro.

Space properties can be used to suppress rendering of sections and content.

Resources

More information on space properties.

Using Space Properties
Space properties are defined for spaces and are accessed via the Space Property Macro. This tip goes into detail in how to use space properties with inheritence and extension pages.
Space Hierarchies
Organize spaces in hierachies with delegate and search spaces.

Space Hierarchies

Organize spaces in hierachies with delegate and search spaces.

According to the projectdoc Toolbox for Confluence spaces may be related in two ways:

delegate-space
List of spaces to delegate documents on creation to. Also works as a search space for upstream spaces.
search-space
List of spaces to include in downstream searches. Use @all to refer to all spaces.

The Delegate Space feature is used to define hierarchies. A space property defined in a delagate space is inherited to the delegating space. Also homepages for doctypes, not defined in the delegating space will be inherited from the next delegate space.

A space attached to the Search Space of a space enables macros selecting documents (for instance the Display Table Macro) to automatically include documents from the search space.

Resources

Delegate Space
Delegate spaces help to organize information that is used by more than one space. Resources may be delegated to other spaces. This includes the definition of space properties and providing homepages for documents of a given type.
delegate-space
List of spaces to delegate documents on creation to. Also works as a search space for upstream spaces.
Search Space
Search spaces extend the search with projectdoc macros for a space per default on a number of other spaces.
search-space
List of spaces to include in downstream searches. Use @all to refer to all spaces.
Space Property
A property defined on the space homepage that takes effect on the space and delegating spaces.
Doctype Homepage
Provides a link to the document's type homepage.

Default Locations

Document types have their default location within a documentation space. These default locations are called 'homepages'. If authors create new documents they can send them to these default locations within a given space. Delegate spaces expand this feature to find the default location in associated spaces.

If authors know what information they want to keep accessible for any stakeholder, found a template to support their task, they may still not know where to put it. Every wiki may have a different structure. On the one side this is a strength of wikis. They can evolve and are refactored to a new structure once the problem domain has been better understood. One the other side the individualism makes it hard for teams to create a comprehensible structure to live in - for readers and authors. If documents of similar content are stored at different locations, they are probably hard to find. If authors cannot derive the right location for their document, other stakeholder will probably have a hard time to find it.

Projects of similar objectives may be served by similar structures quite well. Software development teams know that the actual location for a file is arbitrary, but it should be the same folder for the same types of files. Furthermore it would be useful if different projects would define the same locations. This way developers who are new to a team will find out easily where to look if they need to find Java or JavaScript source files or the folder where all the sources are compiled to during the build process. This is called a standard directory layout.

Homepages to store Documents

Each template is defined by a doctype that defines the basic structure of every document instance of this type. The structure is a compilation of properties and sections.

In projects documents of the same type tend to be accessed together. Think of documents that describe roles or personas. Or design decisions, meeting minutes, the documentation of aspects of a software architecture. projectdoc defines a default location called homepage for each (with some exceptions that should not bother us here) document type. The homepages are similar to index pages you may already know. There is only a slight difference. While index pages collect every page that has a certain label on it, the documents on the homepage are the most important documents of that type. There may be more documents that are children of these root types. Think of roles! There may be a role document that describes the most generic user of a system. Subdocuments of the User document may be specialized users, like Power User or Admin User. The homepage only has a reference to the User document and allows the reader to drill deeper into the hierarchy step by step. If the user needs an alphanumeric listing of all roles, the index page is still around. But the documents are typically not stored on the index page, but as pages of the homepage or as a descendent of one of the root documents of their type.

If you create a space, all homepages are created by default. The space homepage lists references to the homepages (either directly or indirectly).

Here is an example from a space created by a projectdoc space blueprint.

The 'Topics' link on the space homepage refers to the homepage of the Topic doctype. There is one document instance on this homepage called 'Installation Howto'. On the homepage there are more links to homepages of doctypes (for instance Tours, FAQs, and Glossary). If a team defines a basic structure for their spaces of a given type, new group members, who have worked with other teams on other projects, will have an easier time to get familiar with the domain of a new project. They still have to learn the new domain, but they are already familiar with the structure of the documentation for this domain.

Default Target to store Documents

Each page wizard for a doctype that supports a homepage, there is a flag to store the document either as a child to the current page (default) or to send it to the homepage for this type.

The screenshot shows the creation of a document for a role named 'User'. The author decided to store the document to the homepage of the 'Role' doctype instead of saving it as a child to the current page. The current page is the page the author viewed when she decided to create a new page by starting the wizard.

Delegate Spaces and Homepages

Some documents are relevant to more than one space. If you have a large project with multiple large components you may want to have a space for each component you describe. Each component may share the same roles and topic types. So there is no need to have them copied around spaces. Instead have them stored in a collaboratively used delegate space.

There may be more than one delegate space. Delegates spaces are specified in an ordered list.

Whenever an author sends a document to its doctype homepage, the document is stored to the immediate homespace page found in the delegate space hierarchy. Assume for instance that the current space has a delegate space with a homepage for roles, but has itself no such homepage. If a document of type 'Role' is sent to its homepage, then it will be stored on the role's homepage on the delegate space.

Resources

More information on this feature.

projectdoc.doctype.(doctype).home
Controls the location of the homepage of a given document type. Use the identifier of the doctype.
projectdoc Spaces
projectdoc introduces structure on a Confluence space. It adds the concept of homepages for document types.

Single Sourcing

The projectdoc Toolbox provides doctypes and macros to support teams to modularize their documentation.

Single sourcing is an approach to reuse content by making sure that each piece of information has only one authoritative location.

There are a couple of tools in the projectdoc Toolbox to support single sourcing:

  1. The Section Macro and the Content Marker Macro allow to define pieces of information on a projectdoc Document. Using the Transclusion Macro or the Transclude Documents Macro the content, defined in a single location, can be rendered on any other page.
  2. Also Dynamic Linking allows to automatically pick sections from other documents.
  3. The Module and Module Type doctypes allow to specify a piece of information on a separate document. By defining types of modules, the individual pieces may be organized to be found by browsing. Additionally the documents may provide additional metadata used to filter or be provided as helpful information for other authors.

Resources

More information on single sourcing.

Single Sourcing
Description of single sourcing as a practice: Reduce redundancy by having one source of truth for each information. This way the written information is more easily reusable in other documents and - which is even more important - it is referenceable. Single sourcing demands automation.
Single Sourcing
Entry in the glossary: Method for systematically re-using information.
Transclusion
The technique to render parts of one document within another document.
Multi-transclusion
Describes the technique to transclude one or more content fragments from one or more documents.
Dynamic List
Enhances navigation by showing a list of links to related information that is the result of a query on document properties.

Delegate Document

Delegating documents transclude sections and properties from a delegate document. Information may be overridden.

The delegate document is closely related to transclusion. With the Document Properties Marker Macro a single document may be specified as the delegate document.

  1. For each section of the delegating document the content provided by the delegate document is automatically transcluded. Only if the section is not present on the delegating document or the section already contains content, the transclusion of this particular section is revoked.
  2. For each property, activated by the document property control named delegate, the property value is transcluded.

The use case for this feature is to use another document for defaults and override or add information to it.

Resources

More information on this feature.

Delegate Document
A delegate document references one document to inherit properties and sections.
Document Properties Marker Macro
A table containing document properties. Three columns: name, value and meta data (aka controls) to a property.
Section Macro
Renders a section, if the body is not empty. Supports authors to create content, clutter-free rendering without empty sections. Allows to transclude the content.

Live Templates / Impersonator

Use the structure from a page and render it in the current page's context.

The Impersonator is closely related to transclusion. But instead of transcluding content from another page, the impersonator transcludes only the unrendered content and renders it in its own context. The transcluded, unrendered content is used as a template that is rendered at request time. Therefore it is called live template.

For more information and an example of usage, read the tip Impersonator - using Live Templates!

Resources

More information on this feature.

Transclusion
Tools to provide or consume content to support reuse.
Transclusion Macro
Transcludes content from a document marked with the content marker macro.
Section Macro
Renders a section, if the body is not empty. Supports authors to create content, clutter-free rendering without empty sections. Allows to transclude the content.
Content Marker Macro
Marks a piece of content within a document. This content can be referenced for transclusion.
Impersonator - using Live Templates
A short introduction using the impersonator feature of the projectdoc Toolbox. In this example we examine what to do to reuse a layout defined in another document.

Deep Links

With deep links properties from referenced properties can be accessed for rendering.

Web API

To integrate projectdoc documents with remote systems the projectdoc Toolbox provides a REST API. This API is installed separately with a free extension add-on.

The Web API allows to access projectdoc documents remotely via REST.

Use the REST API Browser of Confluence to start using the REST API provided by projectdoc.

The browser is accessible via plugins/servlet/restbrowser. For more information please refer to Using the REST API Browser.

The Web API also supports users to create bookmarklets to automate recurring tasks.

The Bookmarklets Extension allows to integrate calls to the web API into the user's browser.

With bookmarklets services are brought to the fingertips of the users. The organization of bookmarks can be personalized very easily.

The Bookmarklets Extension provides a number of bookmarklets to get started. With the Bookmarklet Editor these bookmarklets can be loaded and installed. The editor also allows to create new bookmarklets.

An overview over projectdoc bookmarklets is available on Bookmarklets List Macro.

Resources

More information on this feature.

Web API Extension
Add-on to extend projectdoc with an API to access on the web.
Bookmarklets Extension
Add-on to extend the Toolkit with Bookmarklets. Allows to execute tools via the browser.
REST Login to Confluence with cURL
To access Confluence via its REST API with cURL you typically need to authenticate. Learn how to login with cURL and avoid some common security pitfalls.
Accessing projectdoc Properties with cURL
Learn how to access projectdoc properties via REST API with cURL.
Confluence as the Information Hub
Tools from the projectdoc Toolbox to import from and export to other information systems.

Information Systems Integration

Via a free extension information from remote information systems may be rendered on a wiki page.

Information from remote services can be integrated in a page. This includes transcluding texts and images, but also information from artifact repositories, Javadoc API documentation, or model repositories.

# Name Short Description
1
Renders an image generated from an Enterprise Architect diagram, transcluded from a server.
2
Transclude HTML content from a remote server.
3
4
5
Renders an image transcluded from a remote server.
6
7
Transclude content from a resource from a remote system.
8
Transclude text content from a remote server.

OAuth and basic authentication options as well as autoconverters for links are also provided.

Resources

More information on this feature.

Information Systems Extension
Add-on to extend the projectdoc Toolbox to integrate remote information systems.

Remote Control

The projectdoc Toolbox supports rendering a page controlled by request properties. This way a URL controls the contents of a page.

A remote controlled document uses macros that expose some or all of their parameters to be controlled by query parameters provided with the HTTP request. Effectively the request parameters override macro parameters.

 

For instance the Select and Where parameter of a Display Table Macro can be overridden to render a different set of properties and query a different set of documents. Another example would be to transclude a different document.

This feature is useful for use cases where the content of a page should be controlled by an external information system. A typical use case is to aggregate a page based on an error code. The remote system can reference a remote controlled document on a Confluence server and select the information by providing the error code and some context information.

Supporting Macros

Not all macros are remote controllable nor are all parameters capable of being overridden. The following list of macros from the projectdoc Toolbox support being controlled remotely:

Display List Macro
Lists references to projectdoc documents in a list. List contain names and optional short descriptions.
Display List Template Macro
Lists references to projectdoc documents in a list. List items are defined by templates referencing properties.
Display Table Macro
Lists references to projectdoc documents in a table. Allows to select document properties for columns. Also non-list representations are provided.
Index Entries Table Macro
Renders a table of index entries.
Random Transclusion Macro
Transcludes random content from a document marked with the content marker macro.
Tour-by-Property Macro
Renders a predefined list of documents in a table . Documents are selected by a document property. Allows to select document properties for columns. Also non-list representations are provided.
Transclude Documents Macro
Renders transcluded content fetched from documents of a result set.
Transclusion Macro
Transcludes content from a document marked with the content marker macro.
Transclusion Reference Macro
Transcludes content via a reference from a document marked with the content marker macro.
Transclusion to Text Macro
Transcludes content from a document marked with the content marker macro and renders it as plain text.

Resources

More information on this feature.

Remote Control
The projectdoc Toolbox supports rendering a page controlled by request properties. This way a URL controls the contents of a page.
Remote Controlled Document
A remote controlled document uses macros that enable to control the content being rendered by request parameters.

Extensible by Spaces, Templates, and Macros

Never be limited to the vendor's ideas: Create your own spaces, templates/blueprints/doctypes and macros based on components provided by the projectdoc Toolbox!

The projectdoc Toolbox for Confluence is a set of tools to support you and your team to define your own page blueprints and space blueprints. It also allows you to build your own macros based on the infrastructure the projectdoc Toolbox provides.

 

Note that the Java API is currently not stable. Therefore we recommend to do the integration work for your tools by the use of the Web API Extension.

If you do need to use our Java API we recommend to get in touch!

To define your blueprints, you could use any approach that allows you to use macros from the projectdoc Toolbox. Make sure that your page blueprint creates a projectdoc Document!

 

Consider to use the Doctype Maven Plugin to define your project based on the projectdoc Toolbox on models. These models hide some of the more complex requirements to build your blueprint add-on.

Note that we call page blueprints doctypes since these doctypes provide some more features than blueprints do.

Also note that you need programming skills, especially you need to know how to work with Maven to create a deployable artifact from a project.

Resources

More information on this feature.

projectdoc Document
projectdoc is based on projectdoc documents. Creating a projectdoc document is easy: A projectdoc document is a Confluence page using document properties and sections.
Document Type
A document type (doctype) defines the properties and section for document instances. It also provides home and index pages. In Confluence these doctypes are implemented as page blueprints, usually with one template. This template is used to create new pages in Confluence.
Web API Extension
Add-on to extend projectdoc with an API to access on the web.
Doctype Maven Plugin
Create doctype add-ons (OBRs) for the projectdoc Toolbox with Confluence Blueprints based on XML model descriptions easily!
Guided Writing & clutter-free Reading
Do not clutter the view with non-information sections. Instead help authors writing identical structured content by the use of templates.
Document Types
Document types allow to guide authors producing information of a given type. They also help readers to find the information they are looking for quickly.