(Also contributed to CIDM Newsletter)

In November 2011,The Center of Information-Development Management organized the seventh annual Content Management Strategies/ DITA Europe conference in the historic center of Prague, the capital of Czech Republic.

This event offered a great opportunity for the participants to gain insights into effective implementation of topic-based information management through experts who presented their experiences, complex challenges and innovative, successful solutions.

While in former DITA events, most talks centered around the principles of DITA/topic-oriented documentation and how organizations were starting and succeeding with first projects, in this event, it became clear that the topic-oriented approach has become a mature, highly adopted standard in most industries. Many interesting use cases and successful implementations, also going beyond technical documentation,  along with some motivating ideas around DITA were presented.

We had an educating experience in learning how SAP Education migrated their training content to DITA, which business objectives they want to achieve with their Modular Multi-Modal Content Production Project and which challenges they are facing in meeting their commitment to DITA for their product documentation.

Chris Kravogel shared his DITA-based project for drug-labeling documents and NXP semiconductors showed how they improved an internal website by rearranging it to be more task based with DITA concept in mind, thereby receiving a lot of positive feedback for the change. In ITT Fluid Technology, translation cost and lead time was reduced by more automated updating of manuals in case of user interface text string change.

For those moving to DITA from a book oriented traditional environment, Dorthe Sonne’s (Siemens Wind Power) and Keld Jellesen’s (advice2u) contribution would be very helpful. Tips and tricks on how to avoid “DITA Spaghetti” were provided by Jang Graat in a very witty presentation.

IBM’S Sophie McMonagle gave an insight of their CICS software documentation with DITA and explained the benefits they incur from keyref implementation.

Another important subject discussed in several presentations was visualization. This came in several flavors: Marie-Louise Flacke and technical communication experts of Oracle discussed how visualization can support the end-user to better understand the content and its message and Frank Shipley of Componize demonstrated how visualization can support information architects and authors to better understand their content.

Don Day and Kristof Van Tomme shed some light on the relation between DITA and Social Media. Jonathan Lundin presented the usage of SeSamfor making DITA content findable. Other related subjects like optimizing translation processes, working with metrics to ensure the creation of important content, and the advantages of evolving content scenarios completed the agenda.

Throughout the entire event, interested parties were able to obtain information and demos on DITA related products and services at the vendors’ stands.

After long days packed with exciting new information and a comprehensive presentation schedule, the vibrant city of Prague offered a great opportunity of recreation. Whether it was visiting the beautiful historic center, listed as a UNESCO world heritage site, including Old Town Square, Charles Bridge, the Prague Castle and the Jewish Quarter,or enjoying the hearty Bohemian cuisine and great Czech beer or shopping for typical souvenirs like the famous Bohemian glass, Bohemian garnet or string puppets – there was something “on the agenda” for everybody.

In this webinar, Alexej Spas talked about how the otherwise complicated activity of DITA specialization can be handled comfortably in a visual way. The benefits of having infrastructure support for DITA specialization in terms of model validation, import, export and integration with version control and documentation environment were also talked about. The webinar was structured as follows:

• Traditional approach to doing DITA Specializations
• Main challenges in doing DITA Specializations
• Traditional vs. Visual Specialization/Benefits of visual over traditional Specializations
• Demo by doing an example Specialization using visual tools

For those who had missed the webinar or those who want to go through it again, we have uploaded the webinar at:

Webinar: Tools for Visual support for Doing DITA Specializations

The presentation slides for the webinar are separately available at:

http://www.slideshare.net/instinctools/dita-specialization-tools-for-visual-support

DITA Visual Specialization Manager contains comprehensive modeling functions. In productivity area, it provides benefits in terms of lesser time, optimal quality of deliverables, and single-sourcing of the model by its ability to export DTD and XML Schema. The main features of this application are listed as follows:

• Wizard-based Visual Editor for DITA specializations with support of structural, domain and attribute specializations
• Import of existing specializations from DTD
• DITA model validation (checking for validity of specialization)
• Export of managed specializations to DTD or XML Schema
• Export of Specializations in the form of DITA OT plug-in
• Integration with version control

All these benefits and functionalities have been developed to give substantial support to Information Architects and Documentation Project Managers in designing and maintaining their DITA specializations. It is done by providing a wizard-based visual editor for DITA information types. The development of these functionalities has been made possible through a mix of technological expertise and practical experience gained from various DITA projects.

Besides the standard commercial license for DITA Visual Specialization Manager, *instinctools offers a free-of-cost non-commercial license for development and maintenance of publicly available DITA Specializations and a time-limited evaluation license.

For first information on working with DITA Visual Specialization Manager for typical modeling tasks, we have provided tutorial videos for creating Model Projects, Shell DTDs, Structural and Domain DITA Specialization, and Export to DTD and DITA Open Toolkit on website: http://www.ditaworks.com/Vids.

Downloads for DITA Visual Specialization Manager (for evaluation and
non-commercial free-of-charge use) are available from http://www.ditaworks.com/dl.

For more information about DITA Visual Specialization Manager, please
visit http://www.ditaworks.com/modeling or write to info@instinctools.com.

DITA Visual Specialization Manager is planned to be released this week, but now you have a possibility to get a first preview of available functionality by watching some fresh screen casts published on DITAworks website. These demos cover following functions of DVSM:

Creating Modeling Project
Creating new DITA Infotypes
Performing Structured DITA Specialization
Performing Domain DITA Specialization
Export of Managed Models to DTD and DITA Open Toolkit

We are looking forward for your feedbacks on features presented there.

I remind that DITA Visual Specialization Manager will be available free-of-cost for non-commercial usage and for architects developing DITA models that are publically accessible.

Stuttgart, Germany, November 5, 2009 — *instinctools GmbH, a company providing software solutions and services, has been previously instrumental in bringing an innovative structured documentation solution in the form of DITAworks Documentation Application in the market. They have also brought productivity enhancement benefits in documentation area like full Eclipse IDE integration with their documentation application DITAworks. Now, they have decided to make a contribution to the DITA community by providing their DITAVisual  Specialization Manager totally free of charge for the purpose of development and maintenance publicly available DITA Specializations. This will provide a much needed impetus to DITA standard by lowering barriers to DITA adoption as a result of simplification of the DITA specialization process.
The DITA Visual Specialization Manager contains comprehensive modeling functions that allow development and maintenance of project specific documentation models (DITA Specializations). This application opens a new dimension in the ease of customizing DITA to specific needs in a user-friendly way. It simplifies the DITA specialization processes while providing productivity benefits in terms of lesser time, optimal quality of deliverables, and single-sourcing of the model (export of DTD and XML Schema possible). Furthermore, it can facilitate an integrated environment with 100% DITA-based tools like DITAworks. The main features of this application are listed as follows:

• Wizard-based Visual Editor for DITA specializations with support of structural, domain and attribute specializations
• Import of existing specializations from DTD.
• DITA model validation (checking for validity of specialization)
• Export of managed specializations to DTD or XML Schema
• Export of Specializations in form of DITA OT plugin
• Integration with version control

All these benefits and functionalities have been developed to give substantial support to Information Architects and Documentation Project Managers in designing and maintaining their DITA specializations by providing wizard-based visual editor for DITA information types. The development of these functionalities has been made possible through a mix of technological expertise and practical experience gained from various DITA projects.

This free-of-cost license for DITA Visual Specialization Manager will be limited to development of or working with models available publically and prohibit any commercial use of the tool other than evaluation. The license will be made available starting from the first week of December.

For more information about DITA Visual Specialization Manager from *instinctools, please visit www.ditaworks.com/modeling

I would not go deep into the details of Eclipse Help subsystem now. It will be a subject for another blog post which will come later. The only thing I’d like to emphasize now is that Eclipse Help subsystem expects documentation to be provided in Eclipse Help format. This documentation can be used in two ways:

• In the “book” mode or so called “Infocenter” mode, where users can browse documentation structure, search through the documentation, browse documentation index. You can explore this mode with Eclipse online documentation.
• As context-sensitive help, when appropriate help page is shown depending on the application context (window).

We use DITA Open Toolkit in order to transform DITA based documentation to Eclipse Help format.  This transformation works well for the Infocenter mode out-of-the-box . DITA OT creates special Eclipse plug-in out of the DITA documentation.  This plug-in should be distributed with an Eclipse RCP application.

At the same time, additional XML objects need to be created in order to provide context–sensitive help. These objects describe the association between context IDs which are declared in the RCP application source code and the list of links to related topics and optional text description of the context. The main complexity here is synchronization of IDs used in source code with context definitions, taking into account that IDs and documentation are created by different and often distributed teams. This is why we have to maximally automate Eclipse Help context creation and maintenance.

The process we are using for the RCP documentation development can be split in two parts.  The first part needs to be done by RCP developers and the second part is documentation team’s responsibility.

Part 1 (RCP development team)

1. Assigning context IDs to UI widgets in RCP application source code
2. Exporting context IDs data and delivering them to documentation team
3. Creating Eclipse Help plug-in in RCP application where documentation will be stored

Part 2 (documentation team)

1. Creating DITA documentation
2. Creating specialized DITA map for editing Eclipse Help contexts
3. Importing context IDs provided by RCP development team
4. Creating context definitions
5. Publishing Eclipse Help content to the plug-in provided by RCP developers

To simplify first group of activities, we have created a special Eclipse plugin that should be installed to RCP developers’ environment. Second group of activities is automated by DITAworks.

Let’s consider these steps in more details.

1.1 Defining Contexts IDs in Eclipse RCP Source Code

As a first step, RCP developers should assign unique context ID to UI controls. Each UI component can have one context ID.  Later, it will be possible to link several related topics and provide a text description for each Context ID.  Context ID assignments can be static or dynamic.  Below, I shortly explore each of the methods.

Static contexts can be defined using setHelp method in org.eclipse.ui.help.IWorkbenchHelpSystem which will associate a context ID with a Control, IAction, Menu, or MenuItem. The context ID should be fully qualified with the plug-in ID. For example, the following snippet associates the id “com.example.helpexample.panic_button” with a button in the application.

PlatformUI.getWorkbench().getHelpSystem()
                        .setHelp(myButton, "com.example.helpexample.panic_button");

Dynamic contexts are calculated automatically during run time.  This can be archieved through the implementation of org.eclipse.help.IContextProvider interface which ensures dynamic Context ID calculation.  It is also possible to use the following code:

PlatformUI.getWorkbench().getHelpSystem()
             .setHelp(control,
                      HelpUtil.getContextId(IHelpContexts.MY_CONTEXT1,
                                            "my.application.main.ui"));

This method is recomended for dialogs but works well everywhere.

Dynamic context allow us to store all context IDs in one place which can be then delivered to the documentation team e.g. in an XML file which can also contain additional information (comments, descriptions etc.).

To simlify and speed up help related activites for RCP developers, we’ve implemented a special Eclipse plug-in which should be deployed to RCP developers’ Eclipse environment. All functions provided by this plugin can be found in right-click menu item “Eclipse Help” which is available for java projects, java packages or java classes:

Let’s take a look at the functionality provided by this plugin:

Convert Static contexts to Dynamic

This operation will find all static contexts in the selected scope (project, package or java class) and convert them to dynamic contexts. When a developer executes this function, a special wizard will be started which will search for static contexts and present them in the dialog form.  There, the developer will see all static contexts which are found in the application and will be able to modify values automatically assigned by the wizard HelpKey.

The wizard will also allow the developer to specify a class where constants will be defined.

Assign contexts for new components

This operation will search for new UI components that do not have Context ID assigned to them yet.  Then, developers will be able to modify autogenerated IDs and generate a Java code which will assign these IDs to the corresponding UI widgets.

1.2 Delivering Context IDs Data to the Documentation Team

In this step, RCP developers should transfer a file with Context IDs definitions to the documentation team. Eclipse plug-in described in the item 1.1 above provides Export Contexts to DITAworks function that  should be used in order to export context IDs to the documentation team.  When this function is executed, a wizard will be started which will search for contexts and will allow to edit descriptions and make comments. These should be delivered to the documentation team. After this operation is done, a directory, where context definitions will be stored, should be selected. Merging with existing context definition file is also supported by the plugin.

Exported file with Context IDs should be provided to the documentation team. We suggest to use version control in order to organize smooth sharing of this file between development and documentation teams.

1.3  Creating Eclipse Help Plug-in in RCP Application

RCP developers should create an eclipse plug-in project in Eclipse IDE and link it from the target platform of the RCP application.  This plug-in project will be used to exchange information between the development and the documentation teams. More detailed description of plugin creation procedure can be found in Eclipse online help.

After creating Eclipse Help Plug-in, the plug-in project should be shared with documentation team through the version control (CVS, SVN or any other which is used in your organization). Later, documentation team will use this project as an output for Eclipse Help publishing.

2.1  Creating DITA Documentation

This step is done by the documentation team which should create required deliverables, DITA topics and maps. It can be executed in parallel to the RCP development team activities 1.1 - 1.3 described above.

2.2  Creating Specialized DITA Map for Editing Eclipse Help Contexts

As it was described in our previous post, we use specialized DITA map object to store Eclipse Help context data. This allows us to store context data in DITA and use available tools and validation mechanisms. DITAworks provides EclipseHelpPluginMap specialization that should be used for these kinds of maps. To create it in DITAworks, start  “New Map” wizard, type a title, choose document type “eclipsehelpplugin” and choose a folder to store new map.

As a result DITAworks will create a new map with the eclipse help plug-in structure.

2.3 Importing Context IDs Provided by RCP Development Team

DITAworks already provides functionality that should be used for importing Context IDs data provided by the development team. It can be done by using DITA | Import Context IDs wizard available in the right click menu on a content project.  This wizard allows to specify a file for import, define the destination folder. It also supports file merging in the case of context IDs already imported earlier.

2.4 Defining Contexts

In this step, the documentation team should create context definition using DITAworks map editor.

2.5  Publishing Documentation to the Plug-in Available for RCP Developers

In this step, DITA documentation should be published to the plug-in which was created by RCP developers in the step 1.1.  The publishing can be started by selecting a map and choosing  Publish » Publish to… from the right-click menu.  It is necessary to select ”Eclipse help with contexts” format as a type of deliverable and the plug-in root folder as a publishing destination.

Conclusions

This is how we facilitate collaboration during Eclipse Help documentation development. We would very much appreciate any feedback on the approach described above. We also welcome you to share any experiences which you might have regarding complex RCP documentation development.

Defining glossaries

Glossaries in DITA are defined using <glossentry> elements that represent a separate glossary entries. glossentry is defined as independent topic type specialized from standard DITA topic.

We have point out to significant difference about how glossaries are defined in DITA 1.1 and DITA 1.2.

In DITA 1.1 glossentries are quite simple topics consisting of glossterm and glossdef elements + optional related-links. As in DITA 1.2 content model of glossentry is pretty much developed, providing possibility to define abbreviations, synonyms and s.o.

In both DITA 1.1 and DITA 1.2 glossentry elements can be defined either in separate files (one entry per file) or inside of DITA composite topic (<dita> element).

Example:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE dita PUBLIC "-//OASIS//DTD DITA Composite//EN"

 "glossary.dtd">
<dita>

 <glossentry id="Term_1_dita_glossentry_3">

    <glossterm>Term 1</glossterm>

    <glossdef>Definition 1</glossdef>

 </glossentry>

 <glossentry id="Term_2_dita_glossentry_4">

    <glossterm>Term 2</glossterm>

    <glossdef>Definition 2</glossdef>

 </glossentry>

 <glossentry id="Term_3_dita_glossentry_5">

    <glossterm>Term 3</glossterm>

    <glossdef>Definition 3</glossdef>

 </glossentry>

</dita>

Later glossentries are linked to publications using glossarylist element of bookmap.

Example:

<backmatter>

  <booklists>

    <indexlist/>

    <bibliolist/>

    <glossarylist >

        <topicref format="dita" href="../../TBD/Glossary_2.dita" toc="no" type="glossary"/>

    </glossarylist>

  </booklists>

</backmatter>

In DITA 1.2 support of glossaries is much more mature (see http://dita.xml.org/sites/dita.xml.org/files/DITA1.2GlossaryTerminologySpecialization.pdf). Content model itself is more developed and there is a way to make references to glossary entries from content using <term> element.

Publishing glossaries

DITA does not define any restrictions or guidelines as to processing of <glossarylist>. It is completely responsibility of processing engine. In DITA Open Toolkit 1.5. glossaries have no special processing and are published like ordinary topics. So we can say that glossary publication is not supported properly in DITA Open Toolkit yet.

Support in DITAworks

DITAworks 1.1 is based on DITA 1.1 and it uses all data structures available in DITA 1.1 to define glossaries. Possibilities of DITA 1.1 glossaries are enough to be able to define new glossary terms and link them to published documentation. There are some difficulties with linking to glossary topics from <term> elements though.

In DITAworks version 1.2 we plan to fully support DITA 1.2 and users will get all advantages of new support of glossaries in DITA 1.2 starting from this version.

As to publishing glossaries:  DITAworks 1.1 extends standard DITA Open Toolkit and provides convenient way to generate standard alphabetically grouped glossaries in our books based on <glossarylist> element.

Presentation describes the issues in producing documentation for Eclipse RCP applications and how DITAworks addresses these issues by introducing single source publishing approach. Presentation addresses how certain specifics of Eclipse Help format are managed by DITAworks.

The event took place on the premises of Wirtschaftsfoerderung Region in Stuttgart and was organized by *instinctools GmbH in a joint effort with WeigleWilzcek, Eclipse Foundation and Wirtschaftsfoerderung Region Stuttgart.

You can download the presentation from the following link: Eclipse_stammtisch_2009_06_041

Thank you for everyone who attended the event and especially for Ralph Muller.

On June 22, 2009 *instinctools will present released DITAworks 1.1 as an important innovation on the 9th Single Source Forum in Munich.

This event is an ideal opportunity for visitors from all kinds of business areas to get information on challenges and innovations in the documentation world.

This year, emphasis is placed on new developments in the provision of information. How suitable are Web 2.0 technologies for the documentation environment? How can clients be directly involved in the creation process? And how do collaboration platforms promote the exchange of information?

Answers to these questions are given by acclaimed field experts in the form of lectures and practice examples on themes such as virtual team work, collaborative tools and user involvement.

Professor Dr. Volker Markl from the Technical University of Berlin opens the program with an exciting insight into the intelligent search machines of tomorrow. To round off the day, a panel of experts from science and business will discuss the latest trends in technical documentation.

In the accompanying exhibition, renowned software manufacturers present their proven tools and interesting new developments.

Visit our booth on Single Source forum..

More about Single Source Forum

About Eclipse Help

The Eclipse Platform includes its own help system based on an XML table of contents referencing HTML files.  This is a standard way to document Eclipse-based software products.

But eclipse help format is not reduced to usages only inside of Eclipse platform. It is available as standalone server solution and can be used for providing ANY help content via Web server. Eclipse help system provides such important functions like navigation through TOCs, search, indexing, bookmarking and s.o.

When Eclipse help is used for documentation of Eclipse-based software, it allows much more sophisticated mechanisms for context-dependent help definitions like: search expressions, contexts, so called cheat sheets and s.o.

Additionally, due to component-oriented architecture of Eclipse, Eclipse help is structured in form of plugins that can be independently deployed and interlinked. This enables creation of scalable documentation that fits to complex product configurations.

Eclipse Help and DITA

DITA as single-source architecture opens a promising approach for maintaining all your documentation in single format. Eclipse help as one of the publishing formats can address needs of context dependent application help as well as generic online help.

DITA Open Toolkit provides a way to transform DITA maps and topics into Eclipse help plugins, but these possibilities are quite limited. Namely DITA OT will generate a TOC file and set of HTML topics linked to source map, but it does not address following important specifics of Eclipse Help:

• Definition of contexts (used for context-dependent help)
• Interlinking topics between several Eclipse help plugins
• Definition of search phrases
• Definition of cheat sheets
• Tuning of plug-in contents (Manifest properties, amount of TOCs, indexes, contexts and s.o.)
• Some other advanced features of eclipse help.

These limitations are hindering adoption of Eclipse help as publishing output format for DITA content.  They need to be addressed if we want to use the full capability of Eclipse help system and this issue can be seen as a current challenge for DITA-oriented tooling.

Eclipse Help and documentation process

Another main challenge in the area of Eclipse help can be found in organization approach to documentation process. In tasks that require definition of context-sensitive help, authoring team needs to work closely together with software development teams. This is required because software developers need to integrate IDs of help topics and contexts inside of software UI code. Same IDs should be mapped to help content created by authoring team.

The documentation process and software development process very often have iterative nature. So the synchronization of IDs, which are defined in software code and in documentation itself, can become a serious quality issue.

Documentation management tools have to support documentation team in this process and provide efficient ways to automate this process. It needs to be ensured that all software UI components are assigned with the contextual help IDs and these IDs are linked to help content.

Contextual help mapping strategies

As there is a need for mapping between software UI elements and documentation contexts, let’s take a look on how this is actually done in Eclipse Help.

In most of the cases, two alternative strategies of ID mapping are used. These are:

1. Direct mapping. When context IDs of help content are placed “AS IS” in software code. This is the easiest approach, but it has a set of disadvantages e.g. this approach requires a lot of discipline in the issue of ID generation and mapping. In most of the cases, one of the teams (software development or documentation) will own the responsibility to generate unique IDs and to assign them. The other team will need to map those. This approach creates a lot of organizational overhead and does not provide needed flexibility.
2. Indirect mapping. In this approach, the software development and documentation teams can define their own context IDs independently.  Later on, these IDs are mapped to each other using a special mapping tool. This approach makes it possible to separate the processes of software development, documentation development and documentation mapping. It provides much greater flexibility in organizational aspects. Example of this approach can be seen here (DTP Approach to Eclipse Help mapping): http://www.eclipse.org/datatools/doc/20080310_DTP_Help-Helper.pdf

Advanced support of Eclipse Help in DITAworks

As DITAworks is an Eclipse-based tool, our product team decided to address challenges described above by the release of DITAworks 1.0. One of the objectives of this release is to make creation of Eclipse Help documentation in DITA as easy as possible.

The main features that will make this possible in DITAworks are described below.

Eclipse help DITA model

To define missing semantics and data structures that are needed for Eclipse Help features, we will create a new EclipseHelp DITA model (specialization). Model in DITAworks is a container for meta information that includes various elements like DITA infotypes, transformation styles, templates, editorial tools configurations and s.o.  It can be roughly compared to DITA Open Toolkit plug-in.

EclipseHelp model will include a set of specialized DITA infotypes:

• EclipseHelpPlugin - specialization of DITA map covering the specifics of Eclipse help plug-in descriptors
• EclipseHelpContext - specialization of DITA map that will be used to model context sensitive help contexts

Model will also define transformations for these infotypes, the set of visualization settings for map editor, preview templates, content validation rules and s.o.

Eclipse help model will also define an Eclipse Help project template that will make it easy for the user to start working with Eclipse Help projects.

Transformation styles will be adjusted to resolve cross plug-in links in Eclipse Help properly.

Mapping strategies in DITAworks

DITAworks will support both the strategies of ID mapping mentioned above: Direct and Indirect.

Indirect mapping strategy will be the recommended approach and it will follow the ideas described in DTP Approach to Eclipse Help mapping.

DITAworks will also provide a set of tools that will support software developers and documentation team members in the process of context ID mapping. These tools include:

1. Plugin for SW development Eclipse IDE that will support developers to generate and assign help contexts according to Indirect mapping approach. It will also detect UI elements that do not have help contexts assigned and then propose to generate context IDs for them.
2. Set of Import/Export actions that will enable the exchange of context IDs between software development and documentation teams.
3. Assignment plugin for documentation team. (out of scope for release 1.0)  It will provide the visual support in indirect assignment of generated UI context IDs to documentation context IDs. It will be possible to deploy this plugin directly into the documented Eclipse software and perform the assignment by browsing the documented UI and checking out available help content for it. In the case where content is not assigned, plugin will offer a set of available context IDs for the assignment or a possibility to add “TODO” for future.

Documentation process in DITAworks

To address the challenges described in “Eclipse Help and documentation process” section, DITAworks will support indirect mapping approach “out-of-the-box” when the development and documentation teams are working independently.

In the diagram below, we can see a sequence of actions that need to be performed for one documentation cycle/iteration:

The documentation process can start in parallel with the developers’ coding software components. The developers will use the plugins described in the previous section to automatically generate and assign context IDs to user interface elements. These IDs will be later used by the documentation team for assignment.

In the next step, the assigned IDs will be exported from IDE into the special mapping file and will be passed on to the documentation team (import to DITAworks). This is one of the possible ways to hand over the context IDs. Some alternatives can also be considered like the direct extraction of IDs from source code and s.o.

Next, documentation team documents software elements not documented yet and then maps already documented parts to incoming IDs. This mapping could be done directly in DITAworks or by using the special Assignment plugin.

Optionally, the assigned IDs can be back-synced to the Developer IDE.

In the last step, DITAworks generates a set of Eclipse help plugins from DITA source and ID mapping information. Eclipse help plugins are split into content plugins and context plugins. The content plugins contain topics and TOCs and the context plugins contain context assignments.

In the next development iteration, this process can start from the beginning with only difference being that the imported IDs will extend already existing IDs and documentation team will need to document only the newly added UI elements.