About DITA-OT Toolkit Roles

Descriptions of the following user roles for the toolkit: CSS Customizers, Build Scripters, and potentially End Users of third-party authoring tools.

If you don't know what a build script is, or whether your authoring tool should or does use DITA OpenToolkit, you may be reading the right document in the in the DITA-OT documentation suite. User Roles are a useful way to present and approach the documentation, enabling the reader to bypass information that is not relevant to the specific task she is performing when this document is read. The followige roles are addressed in this guide:

Many readers may be unaware of the toolkit's presence, but it is the "engine" of whatever writing tool you use to write and maintain XML-based, DITA-compliant content. CSS Stylesheet Customizers read this guide when they are unable to specify custom stylesheets, or .css files from their third-party authoring application. Build Scripters consult this guide when the toolkit is unable to process an Ant build script. The Quick Start Guide features an up-to-date tables of all supported parameters for both Ant and the Java command line interface, useful information if your documentation is generated automatically as part of an automated daily build. As my first manager warned me long, long ago, 'The howling hordes descend when the build breaks'.

If you need to fix a broken build, time is of the essence. If you know how to edit CSS stylesheessor run Ant build scripts, then read on. If you don't recognize CSS and Ant, you're likely an End User and you should refer to your third-party documentation. If like the author, you also enjoy hacking with your tools this is definitely the guide for you. Although the Quick StartGguide currently provides more information for build scripters than css customizers, revisions will describe the use of XSLT and the new plugin architecture for this audience. When your third-party authoring tool breaks down, this guide is the mechanic's manual you didn't know you had. If you're unafraid of a command line and willing to "get your hands dirty" under the hood, an up-to-date, and maintained table of Ant build properties can be the difference between a broken build and a bad day or a gently purring build in a background chron chron job that never demands attention. If the build has already broken by the time you read this, your may be the "build hero" who magically "fixes" the build which no one cares about, except that it is usually only then that the fire-breathing IT dragon returns to it's cave and everyone can relax again until the next "emergency".

If you use the Eclipse plugin architecture to distribute online help to Eclipse developers, you should start with Create Eclipse Plugins.