Thursday, August 27, 2015

DITA 1.3 Implementation Status in upcoming Oxygen XML Editor 17.1

Share to Facebook Share to Twitter Email This Share on Google Plus Share on Tumblr

We plan to release Oxygen 17.1 in about a month or two, probably at the beginning of October this year. Starting with version 17.1, Oxygen includes experimental support for editing and publishing using some of the DITA 1.3 features. If you want to test this support and give us feedback please contact us directly to obtain an Oxygen 17.1 beta kit.

To enable DITA 1.3 editing support in Oxygen 17.1 and use the custom bundled DITA Open Toolkit 2.1 for publishing, open the Preferences dialog box, go to DITA, and select the Built-in DITA OT 2.x radio button.

The following table is a list of DITA 1.3 features and their implementation status:

DITA 1.3 Features Implementation Status
Feature Editing Publishing [Latest DITA Open Toolkit 2.x is used.]
DITA 1.3 DTD, XML Schema, and Relax NG-based maps/topics/tasks/references, etc.

New DITA 1.3 file templates. Also by default DITA topics and maps which do not specify version in the DOCTYPE declaration are also considered to be DITA 1.3.

Specific annotations presented in the content completion window and documentation tooltips for all new DITA 1.3 elements.

See below
Learning Object and Group maps New file templates No specific support implemented
Troubleshooting specialization Create and edit new troubleshooting topics No specific support implemented
XML markup domain Validation and Content Completion Special rendering in PDF and XHTML-based outputs.
Equation and MathML domain

Validation and content completion

Display and Insert equations

Special rendering in PDF and XHTML-based outputs.
SVG domain

Validation and content completion

Display referenced SVG content

Special rendering in PDF and XHTML-based outputs.
Other new DITA 1.3 elements (div, strike-through, overline, etc) Validation and Content Completion. Special rendering in PDF and XHTML-based outputs.
Release management domain Validation and Content Completion No specific support implemented.
Scoped keys

Define key scopes

Validate and check for completeness

Resolve keyrefs and conkeyrefs taking key scopes into account.

Partially implemented. Various issues may still be encountered.
Branch filtering Display, create and edit ditavalref elements. Partially implemented. Various issues may still be encountered.
Shorthand to address syntax that identifies elements in the same topic Properly resolved for validation, links, and conrefs. Implemented.
Various table attributes (orientation, rotation, scope, and headers on cells) Not implemented in the Table Properties action support. But attributes can be changed from the Attributes view. Not implemented.
New Map topicref attributes (cascade, deliveryTarget) Allow setting new attributes, propose proper values for them. Implemented.

Monday, August 24, 2015

DITA 1.3 Key Scopes - Next Generation of Reuse

Share to Facebook Share to Twitter Email This Share on Google Plus Share on Tumblr

Thanks to the hard working OASIS DITA TC Group the DITA 1.3 standard is quite close to being released. Oxygen 17.1 which will be released probably in September this year will have experimental DITA 1.3 support. This will include publishing using a custom build of the latest DITA Open Toolkit 2.x engine in which the main developer Jarno Elovirta has already added incipient support for key scopes and branch filtering.

In this blog post I'm going to give you a small example of how key scopes can benefit simple cases of reuse which could not be done previously.

Let's say you have a simple DITA task in which you have described how a certain task can be performed for a certain product. In our case, the task describes peeling a potato:

The task works and at some point in your Vegetables Soup publication you realise you need to write a similar task about peeling cucumbers. The task is exactly the same, except the product name. So naturally you want to reuse the existing written task. For this we re-write the task so that instead of of the product potatoes it contains a key reference:
<ph keyref="vegetable"/>
Next we need to define in our DITA Map the vegetable key and bind it to a specific value in the potatoes context:
 <topicref href="potatoes_overview.dita" keyscope="potatoes">
  <!-- Define the vegetable key value in this key scope -->
  <keydef keys="vegetable">
   <topicmeta>
    <keywords>
     <keyword>potatoes</keyword>
    </keywords>
   </topicmeta>
  </keydef>
  <!-- Reference to the common task -->
  <topicref href="peeling.dita"/>
 </topicref>
and add in our DITA Map another key scope with the overview and the task which deal with cucumbers peeling:
 <topicref href="cucumbers_overview.dita" keyscope="cucumbers">
  <!-- Define the vegetable key value in this key scope -->
  <keydef keys="vegetable">
   <topicmeta>
    <keywords>
     <keyword>cucumbers</keyword>
    </keywords>
   </topicmeta>
  </keydef>
  <!-- Reference to the common task -->
  <topicref href="peeling.dita"/>
 </topicref>
As you may have noticed, we have not used the key scope names for anything. Just by defining the key scopes, we made the product name to be expanded differently in both contexts. But our Vegetables Soup publication may also contain a topic which lists all possible vegetables. This topic is defined in a context outside any key scope:
<topicref href="vegetables_over.dita"/>
and this overview topic can refer to each product name using the full keyscope key reference value:
<!DOCTYPE topic PUBLIC "-//OASIS//DTD DITA Topic//EN" "topic.dtd">
<topic id="vegetables_over">
  <title>Vegetables Overview</title>
  <body>
    <p>This is an overview of all vegetables necessary to make soup. You will learn how to use
      vegetables like <ph keyref="potatoes.vegetable"/> and <ph keyref="cucumbers.vegetable"/> to
      make a great starter soup.</p>
  </body>
</topic>

As stated before, this kind of reuse was not possible using the standard DITA 1.2 standard constructs. As it turns out, with DITA 1.3 we can also implement this kind of reuse using branch filtering. The DITA samples for this post can be downloaded from http://www.oxygenxml.com/forum/files/keyscopesBlogSamples.zip.

As usual any feedback is welcomed.

If you would like to beta test Oxygen XML Editor 17.1 with experimental DITA 1.3 support please contact us to support@oxygenxml.com.

Wednesday, August 12, 2015

Document Type Extension Sharing

Share to Facebook Share to Twitter Email This Share on Google Plus Share on Tumblr

Instead of copying an entire framework configuration folder (like DITA or Docbook), modify and distribute it you can choose to extend that framework and distribute the extension. In this way, you will benefit of new functionality added to the base framework by newer Oxygen versions and still use your customizations.

The steps below describe how an extension of the DITA framework which removes certain elements from the content completion list can be constructed and shared:
  1. Create somewhere on your disk, in a place where you have full write access a folder structure like: custom_frameworks/dita-extension.
  2. In the Document Type Association / Locations preferences page add in your Additional frameworks directories list the path to your custom_frameworks folder.
  3. In the Document Type Association preferences page select the DITA document type configuration and use the Extend button to create an extension for it.
  4. Give a custom name to the extension, for example DITA - Custom and then change its Storage to external, then save it to a path like: path/to/.../custom_frameworks/dita-extension/dita-extension.framework.
  5. Make changes to the extension, for example go to the Author->Content completion tab and add in the Filter - Remove content completion items list elements which should not be presented to the end users.
  6. Click OK to close the dialog and then either OK or Apply to save the preferences changes.

After you perform the steps above you will have in the dita-extension folder a fully functioning framework which can be shared with others.

The framework can then be shared with others in several ways:
  • Copy it to their [OXYGEN_DIR]/frameworks directory.
  • Create somewhere on disk a custom_frameworks folder, copy the framework there and then from the Document Type Association / Locations preferences page add in your Additional frameworks directories list the path to the custom_frameworks folder.
  • Distribute the framework along with a project.

    Follow these steps:
    1. On your local drive, create a directory with full write access, containing the project files and a custom_frameworks folder containing your dita-extension.
    2. Start the application, go to the Project view and create a project. Save it in the newly created directory.
    3. In the Document Type Association / Locations preferences page, select Project Options at the bottom of the page.
    4. Add in the additional framework directories list an entry like ${pd}/custom_frameworks.
    5. Add other resources to your project, for example you can have all your DITA content located inside the project folder.
    6. You can then share the new project directory with other users. For example you can commit it to your version control system and have they update their working copy. When they open the customized project file in the Project view, the new document type becomes available in the list of Document Types.
  • Deploy the framework/document type configuration as an add-on.

After your team members install the framework they can check in Document Type Association preferences page in the list of Document Types to see if the framework is present and if it appears before the bundled DITA framework (meaning that it has higher priority).