Element Domain Specialization Step 5-1: Create Blank Specialization-Specific XSLT Transform Plugin

Create a directory to hold the plugin. As for document type plugins (see [reference to doctype plugin packaging section]), you should give your plugin a globally unique name, such as a Java-style package name like "org.example.xmldomain.html". The plugin name should reflect both the domain it supports and the transformation type it extends so it's clear what it's purpose is. As a matter of practice, I like to use the same engineering practice for Toolkit plugins that one normally uses for Java classes, namely keep them small and focused. Thus I typically have a separate plugin for each domain/transformation type pair. By naming them all with the same "package" prefix it is easy to see all the related plugins in a Toolkit's plugins directory. It aslo makes it easy to do things like use Ant to manipulate a set of plugins (for example, to package them for distribution or automate deployment from your development environment to your test Toolkit environment).

Because the plugin will contain a normal XSLT module, you can implement and test the XSLT in isolation before you build and test your plugin. This is easiest in the context of an XSLT integrated development environment like OxygenXML or XML Spy, which handles the details of applying the transform to your test data.

In your chosen directory, create the file "xmlDomain2html.xsl" and give it this content:
<?xml version="1.0" encoding="UTF-8" ?>
<!-- ===========================================================
     HTML generation templates for the XML Construct DITA domain
     Copyright (c) 2010 Your Name Here
     =========================================================== -->
<xsl:stylesheet version="2.0"

As of version 1.5, the Open Toolkit requires the use of the Saxon XSLT engine, which means you can use XSLT 1 or XSLT 2. For this exercise the processing is so simple that it doesn't matter whether you use version 1 or 2. However, since the Toolkit allows XSLT 2 there's no reason not to declare your stylesheet as being an XSLT 2 style sheet.

For more complicated processing you will definitely want to use XSLT 2.

To be a Toolkit plugin, the directory must contain a file named plugin.xml. This file declares the name of the plugin and otherwise configures the plugin [reference to more general section on creating Toolkit plugins]. For this simple plugin, the plugin descriptor is:
<plugin id="org.example.xmldomain.html">
  <require plugin="org.example.xmldomain.doctypes"/> 
  <feature extension="dita.xsl.xhtml" value="xmlDomain2html.xsl" type="file"/>  

The part in bold is the plugin name. The name must be unique across all plugins installed in a given Toolkit, so it's important to give the plugin a globally unique name. Again, using Java-style package names ensures that.

The <require> element indicates that this plugin requires the corresponding doctype plugin that contains the specialization module itself. The Toolkit's integration process checks this dependency and makes sure that all the necessary parts are available.

The <feature> element says that the XSLT file xmlDomain2html.xsl hooks into the extension point named "dita.xsl.xhtml" and is of type "file". This tells the Toolkit's integration process to add a reference to the file xmlDomain2html.xsl at the point in the base HTML files where the extension point "dita.xsl.xhtml" is defined. Note that you don't care where that extension point is defined, you only care about the name. Any number of plugins can extend that same extension point.

Tip: Common errors to watch for: