Extension points for plug-ins to the DITA Open Toolkit Plug-in extension points Extensions to the DITA Open Toolkit are supported through a plug-in extension mechanism.

Plug-ins may do a number of things, such as adding support for specialized DTDs or Schemas, integrating processing overrides, or providing entirely new output transforms. Extensions are integrated using a file named plugin.xml, located in the plug-in's root directory; the plug-in directory itself is generally located within the plugins/ directory inside of the DITA-OT. This document describes all recognized extension points that are available for use within the plugin.xml file.

Plugin configuration file

The root element of the plugin.xml file is <plugin>, and must specify an id attribute. The id attribute is used to identify the plugin, as well as to identify whether pre-requisite plugins are available. The id attribute should follow the syntax rules:

id ::= token('.'token)* token ::= ( [0..9] | [a..zA..Z] | ’_’ | ’-’ )+

The <plugin> element supports the following child elements:

  • <feature> defines an extension to contribute to a defined extension point. The following attributes are supported:

    Attribute Description Required extension extension point identifier yes value comma separated string value of the extension either value or file file file path value of the extension, relative to plugin.xml either value or file type type of the value attribute no
  • <require> defines plug-in dependencies. The following attributes are supported:

    Attribute Description Required plugin vertical bar separated list of plug-ins that are required yes important flag whether plug-in is required or optional no
  • <template> defines files that should be treated as templates. The following attributes are supported:

    Attribute Description Required file file path to the template, relative to plugin.xml yes
  • <meta> defines metadata. The following attributes are supported:

    Attribute Description Required type metadata name yes value metadata value yes

Any extension that is not recognized by the DITA-OT is ignored; all elements other than <plugin> are optional. Since version 1.5.3 multiple extension definitions within a plugin configuration file are combined; in older versions only the last extension definition is used.

XML catalogs

The XML Catalogs extension point is used to update the XML Catalogs used to resolve DTD or Schema document types, or to add URI mappings. To do this, first create a catalog with only your new values, using the OASIS Catalog format, and place that in your plugin.

dita.specialization.catalog.relative
dita.specialization.catalog

Adds the content of the catalog file defined in file attribute to main DITA-OT catalog file.

The dita.specialization.catalog extension is deprecated. Use dita.specialization.catalog.relative instead.
org.dita.pdf2.catalog.relative

Adds the content of the catalog file defined in file attribute to main PDF plug-in catalog file.

<feature extension="dita.specialization.catalog.relative" file="catalog-dita.xml"/>
New Ant targets

The Ant conductor extension point is used to make new targets available to Ant processing.

dita.conductor.target.relative
dita.conductor.target

Add Ant import to main Ant build file.

The dita.conductor.target extension is deprecated. Use dita.conductor.target.relative instead.

To do this, first place your extensions in an Ant project file within your plugin, such as myAntStuff.xml. Create a small wrapper file myAntStuffWrapper.xml in the same directory:

<dummy> <import file="myAntStuff.xml"/> </dummy>

Then create the following feature:

<feature extension="dita.conductor.target.relative" file="myAntStuffWrapper.xml"/>
Add Ant targets to the preprocess pipeline

There are extension points to execute an Ant target before or after all preprocessing.

depend.preprocess.pre
Preprocessing pre-target
depend.preprocess.post
Preprocessing post-target

In addition, there are extension points to execute an Ant target before a given preprocessing step.

depend.preprocess.clean-temp.pre
Clean temp pre-target
depend.preprocess.gen-list.pre
Generate list pre-target
depend.preprocess.debug-filter.pre
Debug and filter pre-target
depend.preprocess.conrefpush.pre
Content reference push pre-target
depend.preprocess.move-meta-entries.pre
Move meta entries pre-target
depend.preprocess.conref.pre
Content reference pre-target
depend.preprocess.coderef.pre
Code reference pre-target
depend.preprocess.mapref.pre
Map reference pre-target
depend.preprocess.keyref.pre
Key reference pre-target
depend.preprocess.mappull.pre
Map pull pre-target
depend.preprocess.chunk.pre
Chunking pre-target
depend.preprocess.maplink.pre
Map link pre-target
depend.preprocess.move-links.pre
Move links pre-target
depend.preprocess.topicpull.pre
Topic pull pre-target
depend.preprocess.copy-files.pre
Copy files pre-target
depend.preprocess.copy-image.pre
Copy images pre-target
depend.preprocess.copy-html.pre
Copy HTML pre-target
depend.preprocess.copy-flag.pre
Copy flag pre-target
depend.preprocess.copy-subsidiary.pre
Copy subsidiary pre-target
depend.preprocess.copy-generated-files.pre
Copy generated files pre-target

The following feature adds "myAntTargetBeforeChunk" Ant target to be executed before the chunk step in preprocessing:

<feature extension="depend.preprocess.chunk.pre" value="myAntTargetBeforeChunk"/>
New transtype

The transtype extension point is used to define a new "transtype", or transform type, which makes use of targets in your Ant extensions.

dita.conductor.transtype.check
Add new value to list of valid transformation type names.
dita.transtype.print
Declare transtype as a print type.
The following feature defines a transform type of "newtext" and declare it as a print type; using this transform type will cause the build to look for a target dita2newtext, defined previously in your Ant extension: <feature extension="dita.conductor.transtype.check" value="newtext"/> <feature extension="dita.transtype.print" value="newtext"/>
XSLT overrides

The XSLT import extension points are used to override various steps of XSLT processing. For this, the extension attribute indicates the step that the override applies to; the value attribute is a relative path to the override within the current plugin; the type attribute should be set to "file". The plugin installer will add an XSL import statement to the default code, so that your override becomes a part of the normal build. The following XSLT steps are available to override in the core toolkit:

dita.xsl.xhtml
Override default (X)HTML output (including HTML Help and Eclipse Help) with the following
dita.xsl.xslfo
Override default PDF output (formerly known as PDF2) with the following
dita.xsl.docbook
Override default DocBook output with the following
dita.xsl.rtf
Override default RTF output with the following
dita.xsl.eclipse.plugin
Override the step that generates plugin.xml for Eclipse with the following
dita.xsl.conref
Override conref processing
dita.xsl.topicpull
Override topicpull processing (the step that pulls text into <xref> elements, among other things)
dita.xsl.mapref
Override mapref processing (the step that resolves references to other maps)
dita.xsl.mappull
Override mappull processing (the step that updates navtitles in maps and causes attributes to cascade)
dita.xsl.maplink
Override maplink processing (the step that generates map-based links)
dita.xsl.fo
Override the (now deprecated) original PDF output with the following
<feature extension="dita.xsl.xhtml" file="xsl/modifyXhtml.xsl"/>
Generated text

The generated text extension point is used to add new strings to the default set of Generated Text.

dita.xsl.strings
Add new strings to generated text file.

Copy the file xsl/common/strings.xml to your plugin, and edit it to contain the languages that you are providing translations for ("en-us" must be present).  Copy the file xsl/common/strings-en-us.xml to your plugin, and replace the content with your own strings, being sure to give them unique name attributes. Do the same for each language that you are providing a translation for.

Use the following extension code to include your strings in the set of generated text:

<feature extension="dita.xsl.strings" file="xsl/common/strings.xml"/>

The string is now available to the XSLT "getString" template.

Pass parameters to XSLT

You can pass parameters from the Ant build to XSLT pipeline stages, usually to have those parameters avalable as global <xsl:param> values in your XSLT overrides. Create a file insertParameters.xml which contains one or more Ant <param> elements:

<dummy> <!-- Any Ant code allowed in xslt task is possible. Common example: --> <param name="paramNameinXSLT" expression="${antProperty}" if="antProperty"/> </dummy>

Pass the value using the following extensions:

dita.conductor.html.param
Pass parameters to HTML and HTML Help XSLT
dita.conductor.xhtml.param
Pass parameters to XHTML and Eclipse Help XSLT
dita.preprocess.conref.param
Pass parameters to conref XSLT
dita.preprocess.mapref.param
Pass parameters to mapref XSLT
dita.preprocess.mappull.param
Pass parameters to mappull XSLT
dita.preprocess.maplink.param
Pass parameters to maplink XSLT
dita.preprocess.topicpull.param
Pass parameters to topicpull XSLT
dita.conductor.pdf2.param
Pass parameters to PDF2 XSLT
<feature extension="dita.conductor.html.param" file="insertParameters.xml"/>
Add Java libraries to the classpath

If your Ant or XSLT extensions require additional Java libraries in the classpath, you can add them to the global Ant classpath.

dita.conductor.lib.import
Add Java libraries to DITA-OT classpath.
<feature extension="dita.conductor.lib.import" file="myJavaLibrary.jar"/>
Add diagnostic messages

Plug-in specific warning and error messages can be added to the set of messages supplied by DITA-OT.

dita.xsl.messages
Add new messages to diagnostic message file.

To add your own messages, create the message in an XML file myMessages.xml:

<dummy> <!-- See resource/messages.xml for the details. --> <message id="myMessageId" type="WARN"> <reason>...</reason> <response>...</response> </message> </dummy>

And incorporate them with the extension:

<feature extension="dita.xsl.messages" file="myMessages.xml"/>
Manage plugin dependencies

The <require> element requires the plugin attribute. It is used to identify pre-requisite plug-ins. If the current plugin requires a plugin with id="plugin-id" before it can be installed, it would include the following:

<require plugin="plugin-id">

Prerequisite plugins are integrated before the current plugin is integrated. This does the right thing with respect to XSLT overrides. If your plugin is a specialization of a specialization, it should <require> its base plugins, in order from general to specific.

If a prerequisite plugin is missing, a warning will be printed during integration. To suppress this, but keep the integration order if both plugins are present, add importance="optional" to the <require> element.

If your plugin can depend on any one of several optional plugins, separate the plugin ids with a vertical bar. This is most useful when combined with importance="optional":

<require plugin="pluginA|pluginB" importance="optional"/>
Version and support information

The following extension points are used by convention to define version and support info within a plugin:

  • package.support.name
  • package.support.email
  • package.version

The toolkit does not currently do anything with these values, but may do so in the future.

The package.version value should follow the syntax rules:

version ::= major ( '.' minor ( '.' micro ( '.' qualifier )? )? )? major ::= number minor ::= number micro ::= number qualifier ::= ( [0..9] | [a..zA..Z] | ’_’ | '-' )+

The default value is 0.0.0.

<feature extension="package.support.name" value="Joe the Author"/> <feature extension="package.support.email" value="joe@example.com"/> <feature extension="package.version" value="1.2.3"/>
Create your own extension points

If your plugin needs to define its own extension point in an XML file, add the string "_template" to the filename before the file suffix. During integration, this file will be processed like the built-in DITA-OT templates. To mark the file as a template file, use the <template> element.

<template file="myTemplateFile_template.xsl"/>
Example plugin.xml file

The following is a sample of a plugin.xml file. This file adds support for a new set of specialized DTDs, and includes an override for the XHTML output processor. It would go into a directory such as DITA-OT\plugins\music\ and referenced supporting files would also exist in that directory. A more extensive sample using these values is available in the actual music plug-in, available at the DITA-OT download page at SourceForge

<plugin id="org.metadita.specialization.music"> <feature extension="dita.specialization.catalog.relative" file="catalog-dita.xml"> <feature extension="dita.xsl.xhtml" file="xsl/music2xhtml.xsl"/> </plugin>