Tuesday, April 25, 2017

DITA Inheritance Hierarchy

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

The DITA standard is based on this concept of inheritance which allows extending or restricting the vocabulary while allowing the XML content to still be regarded as valid DITA. Even in the DITA standard there are various element which are specializations of others (for example "b" is a specialization of ph"). The XSLT styesheets which are used for publishing match all DITA elements by the value of their @class attribute so knowing how elements may extend each other may be useful when customizing the DITA XSLTs.

A DITA inheritance hierarchy list for the base DITA specification is presented below. Would you consider it useful if a future version of Oxygen would have some kind of a tool to show such hierarchies even for custom DITA specializations?

  • topic/copyryear
  • topic/foreign
    • mathml-d/mathml
    • svg-d/svg-container
  • topic/author
  • topic/example
  • topic/unknown
  • topic/titlealts
  • topic/linktext
  • topic/category
  • topic/data
    • relmgmt-d/change-request-reference
    • relmgmt-d/change-person
    • relmgmt-d/change-request-id
    • relmgmt-d/change-request-system
    • relmgmt-d/change-completed
    • relmgmt-d/change-started
    • ut-d/sort-as
    • relmgmt-d/change-item
    • relmgmt-d/change-organization
    • relmgmt-d/change-summary
    • concept/data
      • glossentry/glossPartOfSpeech
      • glossentry/glossProperty
      • glossentry/glossStatus
    • relmgmt-d/change-revisionid
  • topic/longdescref
  • topic/audience
  • topic/abstract
    • concept/abstract
      • glossentry/glossdef
  • topic/related-links
  • topic/body
    • task/taskbody
    • concept/conbody
      • glossentry/glossBody
    • troubleshooting/troublebody
    • reference/refbody
  • topic/ph
    • hi-d/overline
    • hi-d/line-through
    • hi-d/sub
    • pr-d/sep
    • equation-d/equation-inline
    • pr-d/repsep
    • equation-d/equation-number
    • hi-d/tt
    • task/cmd
    • pr-d/synph
    • sw-d/userinput
    • ut-d/coords
    • pr-d/oper
    • hi-d/sup
    • pr-d/var
    • sw-d/msgph
    • pr-d/codeph
    • ui-d/uicontrol
    • hi-d/i
    • hi-d/u
    • sw-d/filepath
    • sw-d/systemoutput
    • pr-d/delim
    • hi-d/b
    • ui-d/menucascade
  • topic/object
  • topic/fig
    • ut-d/imagemap
    • pr-d/syntaxdiagram
    • equation-d/equation-figure
  • topic/featnum
  • topic/lines
  • topic/brand
  • topic/state
  • topic/source
  • topic/link
  • topic/vrm
  • topic/sli
  • topic/navtitle
  • topic/figgroup
    • pr-d/synblk
    • pr-d/fragment
    • ut-d/area
    • pr-d/groupcomp
    • pr-d/groupseq
    • pr-d/groupchoice
  • topic/note
    • hazard-d/hazardstatement
    • concept/note
      • glossentry/glossScopeNote
      • glossentry/glossUsage
  • topic/ol
    • task/substeps
    • task/steps
  • topic/stentry
    • task/choption
    • reference/propvalue
    • reference/propvaluehd
    • reference/propdeschd
    • reference/propdesc
    • reference/proptype
    • reference/proptypehd
    • task/choptionhd
    • task/chdesc
    • task/chdeschd
  • topic/dlentry
    • pr-d/plentry
  • topic/vrmlist
  • topic/entry
  • topic/fn
    • pr-d/synnote
  • topic/xref
    • mathml-d/mathmlref
    • svg-d/svgref
    • concept/xref
      • glossentry/glossAlternateFor
    • pr-d/synnoteref
    • pr-d/fragref
    • pr-d/coderef
  • topic/component
  • topic/series
  • topic/bodydiv
    • reference/refbodydiv
    • troubleshooting/troubleSolution
    • concept/conbodydiv
  • topic/data-about
  • topic/tgroup
  • topic/keywords
  • topic/boolean
  • topic/critdates
  • topic/strow
    • task/chrow
    • reference/property
  • topic/simpletable
    • reference/properties
    • task/choicetable
  • topic/linklist
  • topic/revised
  • topic/table
  • topic/dt
    • pr-d/pt
  • topic/image
    • hazard-d/hazardsymbol
    • concept/image
      • glossentry/glossSymbol
  • topic/ul
    • hazard-d/messagepanel
    • task/choices
    • task/steps-unordered
  • topic/p
    • concept/p
      • glossentry/glossSurfaceForm
    • troubleshooting/responsibleParty
  • topic/q
  • topic/linkinfo
  • topic/dd
    • pr-d/pd
  • topic/lq
  • topic/prodinfo
  • topic/dl
    • pr-d/parml
  • topic/prolog
  • topic/indextermref
  • topic/copyright
  • topic/div
    • equation-d/equation-block
  • topic/sthead
    • task/chhead
    • reference/prophead
  • topic/tbody
  • topic/searchtitle
  • topic/colspec
  • topic/created
  • topic/tm
  • topic/text
  • topic/cite
  • topic/li
    • hazard-d/howtoavoid
    • task/step
    • task/substep
    • hazard-d/consequence
    • hazard-d/typeofhazard
    • task/choice
    • task/stepsection
  • topic/permissions
  • topic/no-topic-nesting
  • topic/dlhead
  • topic/prodname
  • topic/index-base
    • indexing-d/index-sort-as
    • indexing-d/index-see
    • indexing-d/index-see-also
  • topic/indexterm
  • topic/copyrholder
  • topic/longquoteref
  • topic/required-cleanup
  • topic/ddhd
  • topic/sl
  • topic/draft-comment
  • topic/section
    • task/postreq
    • task/result
    • troubleshooting/remedy
    • task/tasktroubleshooting
    • concept/section
      • glossentry/glossAlt
    • task/context
    • troubleshooting/cause
    • task/steps-informal
    • reference/refsyn
    • task/prereq
    • troubleshooting/condition
  • topic/pre
    • sw-d/msgblock
    • pr-d/codeblock
    • ui-d/screen
  • topic/topic
    • troubleshooting/troubleshooting
    • concept/concept
      • glossgroup/glossgroup
      • glossentry/glossentry
    • reference/reference
    • task/task
  • topic/platform
  • topic/alt
  • topic/keyword
    • ui-d/shortcut
    • markup-d/markupname
      • xml-d/parameterentity
      • xml-d/xmlatt
      • xml-d/numcharref
      • xml-d/xmlpi
      • xml-d/textentity
      • xml-d/xmlnsname
      • xml-d/xmlelement
    • pr-d/parmname
    • pr-d/option
    • sw-d/cmdname
    • ui-d/wintitle
    • ut-d/shape
    • sw-d/varname
    • pr-d/apiname
    • pr-d/kwd
    • sw-d/msgnum
  • topic/thead
  • topic/publisher
  • topic/desc
  • topic/term
    • abbrev-d/abbreviated-form
  • topic/title
    • concept/title
      • glossentry/glossShortForm
      • glossentry/glossAbbreviation
      • glossentry/glossSynonym
      • glossentry/glossterm
      • glossentry/glossAcronym
  • topic/itemgroup
    • task/steptroubleshooting
    • task/tutorialinfo
    • task/info
    • task/stepxmp
    • task/stepresult
  • topic/row
  • topic/linkpool
  • topic/param
  • topic/shortdesc
  • topic/resourceid
  • topic/dthd
  • topic/metadata
    • relmgmt-d/change-historylist
  • topic/othermeta
  • topic/prognum
  • topic/sectiondiv

Wednesday, March 08, 2017

Useful DITA OT plugins

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

The DITA Open Toolkit is the most commonly used engine for publishing DITA content to various output formats. It has a plugin-based architecture and it comes bundled by default with plugins for publishing to XHTML-based and PDF formats. There are other useful open-source plugins which can be installed in the DITA Open Toolkit and provide various publishing or reporting capabilities. I will try to compile below a list with my favorite open source plugins, many of which are bundled by default with Oxygen XML Editor:

DITA to MS Word

This very useful plugin developed by Jarno Elovirta (the main DITA OT developer) can be used to publish DITA to MS Word (OOXML): https://github.com/jelovirt/com.elovirta.ooxml. The plugin is robust and can handle quite large DITA projects.

Convert MS Word to DITA

The DITA For Publishers project developed by Eliot Kimber contains a plugin which can convert MS Word (OOXML) documents to DITA topics: http://www.dita4publishers.org/d4p-users-guide/user_docs/d4p-users-guide/word2dita/word-to-dita-plugin.html. Useful advice and other ways to migrate from MS Word to DITA can be found here: http://blog.oxygenxml.com/2016/05/how-to-migrate-from-word-to-dita.html.


The DITA For Publishers project developed by Eliot Kimber contains a plugin which can convert DITA content to EPUB3: http://www.dita4publishers.org/d4p-users-guide/user_docs/d4p-users-guide/epub-plugin/generating-epubs.html. There are also plugins which can take the EPUB3 output and generate Kindle or Mobi formats.

Use Markdown content directly in DITA Maps

This plugin developed again by Jarno Elovirta can be used to publish hybrid DITA projects containing both DITA and Markdown topics to any output format: https://github.com/jelovirt/dita-ot-markdown.

Embed video and audio resources in DITA topics

This handy little plugin developed by Oxygen allows you to embed audio, video, or Youtube resources in DITA topics and properly display the embedded content in the XHTML-based outputs: https://github.com/oxygenxml/dita-media-support.

Publish RelaxNG-based DITA topics

RelaxNG is the default schema type in which the DITA vocabulary is described by the specification developers. But the DITA Open Toolkit does not allow publishing RNG-based DITA content by default. Installing this plugin developed by Oxygen will make this possible: https://github.com/oxygenxml/dita-relaxng-defaults.

Present Oxygen track changes in the PDF output

This useful plugin developed by Oxygen allows you to preserve Oxygen change tracking highlights in the PDF output: https://github.com/oxygenxml/dita-classic-pdf-review.

Publish DITA to PDF using CSS

The hard thing about the default PDF output is the customization which involves modifying XSLT scripts and having knowledge of both XSLT and XSL-FO. This plugin developed by Oxygen allows you to use CSS to customize the PDF obtained from DITA content: https://github.com/oxygenxml/dita-css. The plugin needs a commercial license of RenderX XEP or Antenna House in order to produce the PDF: https://www.oxygenxml.com/doc/versions/18.1/ug-editor/topics/ditamap-pdf-css-x-dita2.html. But for Oxygen XML Editor 19 we are actively working on a PDF CSS engine which will allow the plugin to work from Oxygen without any additional licenses: http://archive.xmlprague.cz/2017/files/presentations/css2pdf-xslfo.pdf.

A list with all open-source DITA OT plugins developed and shared by Oxygen XML Editor can be found on GitHub: https://github.com/search?q=topic%3Adita-ot-plugin+org%3Aoxygenxml&type=Repositories. My DITA OT Day 2016 presentation covers most of these: https://www.oxygenxml.com/events/2016/dita-ot_day.html#Seven_Open-Source_DITA-OT_plugins.

Tuesday, February 14, 2017

Customizing Oxygen XML Editor (Overview)

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

Let's assume you just bought Oxygen and want to customize it in order to better suit your team's workflow or to add support for your custom XML vocabulary. I will attempt to provide a set of use cases along with indications and useful links about what customization should be done in order to cover each use case:

Add support for editing a specific XML vocabulary

This kind of support usually should include:
  • New file templates.
  • Validate opened XML documents according to a custom schema.
  • Provide custom CSS to be used in the Author visual editing mode.
  • Provide custom toolbar, menu, and contextual menu actions to be used in the Author visual editing mode.
Such support is done using a document type/framework configuration: http://blog.oxygenxml.com/2014/08/the-oxygen-sdk-part-2-frameworks.html.

Customize the existing support for a specific XML vocabulary

Oxygen comes with pre-configured framework configurations for the most commonly used XML standards such as DITA, Docbook, TEI, or XHTML. You may want to customize the existing configuration for one of these vocabularies and share the customization with others. Such customizations may include: All of these customizations can be done by extending the existing framework configuration and then sharing the extension: http://blog.oxygenxml.com/2015/08/document-type-extension-sharing.html.

Provide custom settings

You may want to provide all members of the team with a fixed set of options: http://blog.oxygenxml.com/2015/11/sharing-application-settings.html.

Modify the application appearance or behavior using plugins

Oxygen plugins can be used to:
  • Contribute custom views and toolbars for the entire application.
  • Filter out existing views or toolbar actions.
  • Contribute a fixed set of options/settings to the application.
  • Register various listeners and be notified when a document is opened, closed, saved, and so on.
  • Use the existing API to make changes to the opened documents.
A more detailed overview of Oxygen plugins can be found here: http://blog.oxygenxml.com/2013/11/the-oxygen-sdk-part-1-plugins.html.

The most popular plugin extension is the Workspace Access plugin extension: https://www.oxygenxml.com/doc/versions/18.1/ug-editor/concepts/workspace-access-plugin.html. This extension is notified when the application starts and can contribute custom views, custom main menu items, custom main toolbar actions, or add listeners for various document-related changes.

There is also a JavaScript-based workspace access plugin extension that can use JavaScript to call our Java API: https://www.oxygenxml.com/doc/versions/18.1/ug-editor/concepts/workspace-access-plugin-js.html.

A set of sample plugins built with the JavaScript-based extension can be found here: https://github.com/oxygenxml/wsaccess-javascript-sample-plugins.

Our Maven-based SDK can be used to develop both plugins and framework Java customizations: https://www.oxygenxml.com/oxygen_sdk_maven.html.

Tuesday, February 07, 2017

Sharing Schematron Validation Rules

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

Custom Schematron rules are a great way to ensure consistency for the edited XML structure, especially when there is a large team working on the same set of documents. You can use Schematron for numerous use cases. For example, to make sure that certain elements are not used at all, to impose restrictions on the amount of text for an element, or to impose restrictions on certain elements based on various attribute values or text content set in other elements. Furthermore, you can define quick fixes for each Schematron rule to give the technical writer proposed solutions for the reported problem. In a previous blog post, I described how we use Schematron rules for our Oxygen User's Manual to impose restrictions when editing DITA content: http://blog.oxygenxml.com/2015/05/schematron-checks-to-help-technical.html.

Once you define the Schematron rules, they can be shared with the other members of your team via a document type framework configuration: http://blog.oxygenxml.com/2014/08/the-oxygen-sdk-part-2-frameworks.html.

In this post, I'm going to provide some precise steps to share a set of Schematron rules with a DITA framework extension.

Instead of making changes directly to the DITA framework configuration folder (located in OXYGEN_INSTALL_DIR\frameworks\dita) and distributing it, you can choose to extend the DITA framework and distribute the extension. This way, you will benefit from new functionality added to the base framework in newer versions of Oxygen and you can still use your customizations.

The following steps describe how you can extend a DITA framework that contains an additional Schematron rules file:

  1. Create a folder structure (for example, custom_frameworks/dita-extension) somewhere on your local disk, in a place where you have full write access.
  2. In that new folder structure, create another folder (custom_frameworks/dita-extension/rules) that will contain all of your custom Schematron files.
  3. Create a new ISO Schematron file (for example, additionalRules.sch) that contains the additional rules you want to impose. For example, the following Schematron rule reports an error if the @scale attribute is used on an image:
    <schema xmlns="http://purl.oclc.org/dsdl/schematron" queryBinding="xslt2"
            <rule context="*[contains(@class, ' topic/image ')]">
                <assert test="not(@scale)">
                    Dynamically scaled images are not properly displayed, you
                    should scale the image with an image tool and keep it within
                    the recommended with and height limits.
  4. In the Document Type Association / Locations preferences page, add the path to your custom_frameworks folder in the Additional frameworks directories list.
  5. In the Document Type Association preferences page, select the DITA document type configuration and use the Extend button to create an extension for it.
  6. Give the extension a custom name (for example, DITA - Custom), then change its Storage option to External, and then save it to a path such as: path/to/.../custom_frameworks/dita-extension/dita-extension.framework.
  7. Make whatever changes you desire to the extension, go to the Validation tab, edit the default DITA validation scenario, and add an extra validation stage to it (a stage that uses your custom Schematron schema). More details about validation scenarios can be found here: https://www.oxygenxml.com/doc/versions/18.1/ug-editor/tasks/dg-validation-scenarios.html.
  8. Click OK to close the dialog box and then either OK or Apply to save the preferences changes.

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

There are several methods for sharing the framework and you can read about them here: https://www.oxygenxml.com/doc/versions/18.1/ug-editor/topics/author-document-type-extension-sharing.html.

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

You can use the framework extension mechanism to customize numerous aspects of the DITA functionality in Oxygen. For example, you can remove various elements from the content completion list: http://blog.oxygenxml.com/2015/08/document-type-extension-sharing.html. Or you can distribute custom new file templates: http://blog.oxygenxml.com/2015/12/sharing-new-custom-file-templates-for.html.

Wednesday, January 18, 2017

Your First Oxygen Add-on

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

A framework configuration provides validation, content completion, and visual editing support for a certain XML vocabulary.

Existing framework configurations that come bundled with Oxygen can be extended and modified. For example, the DITA framework configuration that adds support for editing DITA documents can be modified to remove existing actions, add custom actions, or modify many other behaviors: http://blog.oxygenxml.com/2015/08/document-type-extension-sharing.html.

One way of distributing framework configurations is by using Oxygen's add-on support: https://www.oxygenxml.com/addons.html. An add-on configuration is usually composed of only two files:
  1. A ZIP file containing the zipped framework folder.
  2. An add-on XML configuration file that references the zipped framework folder and defines various properties of the add-on. A small example can be seen below:
    <xt:extensions xmlns:xt="http://www.oxygenxml.com/ns/extension"
        xsi:schemaLocation="http://www.oxygenxml.com/ns/extension http://www.oxygenxml.com/ns/extension/extensions.xsd">
        <xt:extension id="dita-extension">
            <xt:location href="dita_extension.zip"/>
            <xt:author>Radu Coravu</xt:author>
            <xt:name>DITA Extension which removes the bold action</xt:name>
            <xt:description xmlns="http://www.w3.org/1999/xhtml">
                This extension removes the bold action
    Everybody's welcomed to use this
    In the add-on descriptor file you usually need to specify the following :
    • The ID of the extension.
    • The version of the add-on.
    • The minimum supported Oxygen version.
    • Author name.
    • Name and description of add-on.
    • Licensing details.

Changing the add-on version in the XML file will trigger notifications to the end user to install the new add-on. Therefore, you can modify the framework customization in a common location and change the add-on version to signal all end-users who have installed the add-on that a new version is available. More details about packing an add-on can be found here:https://www.oxygenxml.com/doc/versions/18.1/ug-editor/topics/packing-and-deploying-addons.html#packing-and-deploying-addons.

If you want to test the small add-on I exemplified, you can find the sample add-on resources here:https://www.oxygenxml.com/forum/files/sample-add-on.zip.

Installing an add-on is straight-forward using the Install new add-ons dialog box from the Oxygen Help menu. You can add a reference to the add-on XML descriptor file that can reside either on the local hard drive or on a web server, and Oxygen will present all available add-ons: https://www.oxygenxml.com/doc/versions/18.1/ug-editor/topics/installing-and-updating-add-ons.html

The add-ons support can also be used to install Oxygen plugins. Some of the public hosted Oxygen plugins and frameworks are also available as add-ons: http://blog.oxygenxml.com/2014/11/public-hosted-oxygen-plugin-and.html.

In conclusion, if you want to share Oxygen customizations with others, you should try the add-on approach, it is a better approach to manually distributing frameworks and plugins.

Thursday, October 13, 2016

Replacing direct image references with key references in a DITA Project

Share to Facebook Share to Twitter Email This Share on Google Plus Share on Tumblr
Let's say that you have a large DITA project and all the image references in your topics are direct, using the @href attribute like this:
<image href="../../images/Iris_sanguinea.jpg" scale="50"/>
and for better scalability and reuse you want to convert these direct references to DITA 1.2 key references:
<image keyref="Iris_sanguinea.jpg" scale="50"/>

Doing something like this manually means making replacements in hundreds of places and in addition manually building a DITA Map which maps the image file name to the image location.

This blog post will try to describe some steps that you can take in order to automate this change in your project:
  1. The first big step is the generation of the DITA Map which maps each image file name (which will be used as a key) to the image location. So the generated DITA Map will look like this:
    <!DOCTYPE map PUBLIC "-//OASIS//DTD DITA Map//EN" "map.dtd">
    <keydef href="Iris_sanguinea.jpg" keys="Iris_sanguinea.jpg"/>
    We will assume that all images are placed in an images folder and we can create an ANT build file which lists all the images in a parameter and then calls an XSLT script to process the list of images further:
    <project basedir="." name="Create Image Keys Definition Map">
        <fileset id="dist.contents" dir="images/" includes="*"/>
        <property name="prop.dist.contents" refid="dist.contents"/>
        <xslt in="createKeyrefsMap.xsl" style="createKeyrefsMap.xsl" out="images/imageKeydefs.ditamap" destdir=".">
            <param name="filesList" expression="${prop.dist.contents}"/>
    The XSLT stylesheet createKeyrefsMap.xsl is responsible for creating the mapping DITA Map:
    <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
        <xsl:param name="filesList"/>
        <xsl:output doctype-public="-//OASIS//DTD DITA Map//EN" doctype-system="map.dtd" indent="yes"/>
        <xsl:template match="/">
                <xsl:call-template name="tokenizeString">
                    <xsl:with-param name="list" select="$filesList"/>
        <xsl:template name="tokenizeString">
            <xsl:param name="list"/>
            <xsl:param name="delimiter" select="';'"/>
                <xsl:when test="contains($list, $delimiter)">
                    <keydef href="{substring-before($list,$delimiter)}" keys="{substring-before($list,$delimiter)}"/>
                    <xsl:call-template name="tokenizeString">
                        <xsl:with-param name="list" select="substring-after($list,$delimiter)"/>
                    <keydef href="{$list}" keys="{$list}"/>

    So after this step you will have a new DITA Map with all image mappings, DITA Map which you can afterwards link in your main project's DITA Map.

  2. We still need to make changes to all DITA topics and replace all image hrefs with keyrefs. Oxygen has support for XML Refactoring actions and you can define custom XSLT scripts which can be applied to modify an entire set of topics. In the OXYGEN_INSTALL_DIR/refactoring folder you can add an XSLT script along with an XML description of the refactoring action. An XSLT script which would replace @href attributes on images with @keyref would look like this:
    <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
        <xsl:function name="f:getKeyref" as="xs:string">
            <xsl:param name="element" as="element()"/>
            <xsl:variable name="imageFile" select="tokenize(translate($element/@href, '\', '/'), '/')[last()]"/>
            <xsl:variable name="key" select="substring-before($imageFile, '.')"/>
            <xsl:value-of select="$key"/>
        <xsl:template match="node() | @*">
                <xsl:apply-templates select="node() | @*"/>
        <xsl:template match="image[@href and not(@keyref)]">
                <xsl:apply-templates select="@* except @href"/>
                <xsl:attribute name="keyref" select="f:getKeyref(.)"></xsl:attribute>
                <xsl:apply-templates select="node()"/>
    In the DITA Maps Manager view you can right click and choose Refactoring->XML Refactoring, then use your custom refactor action to modify all resources.

A set of samples, including the build file, XSLT stylesheets and refactor action XML descriptor can be found here:https://www.oxygenxml.com/forum/files/batchImageHrefToKeyref.zip.

Thursday, October 06, 2016

Customizing the DITA Visual Editing Experience

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

The Author visual editing experience in Oxygen is CSS driven. Let's say I have a team of writers using Oxygen and they want to visually edit DITA dl elements in a table-like layout.

All the validation, editing and publishing support Oxygen has for a specific XML vocabulary is defined in a framework configuration.

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 that folder create a new CSS stylesheet called for example custom.css which will keep your custom CSS styles:
        display:table !important;
        display:table-row !important;
    dt, dd {
        display:table-cell !important;
        border: 1px solid black;
        padding: 2px;
  3. In the Document Type Association / Locations preferences page add in your Additional frameworks directories list the path to your custom_frameworks folder. Then click Apply in the Preferences dialog.
  4. In the Document Type Association Preferences page select the DITA document type configuration and use the Extend button to create an extension for it.
  5. 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.
  6. Make changes to the framework configuration, in the Author tab click the CSS tab and add a reference to your custom CSS. Do not set a title for the CSS and also do not check the Alternate checkbox as you want your CSS to apply by default.
  7. 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: http://blog.oxygenxml.com/2015/08/document-type-extension-sharing.html.

To check that your framework extension works, you can create a new DITA topic and insert a dl element inside it. It should now be presented in a table-like layout.

In order to know which CSS styles to override for a specific DITA element, you can right click inside that element in the Author visual editing mode and use the Inspect Styles action to see all CSS styles defined for it by default. You can also define alternate CSS styles which are applied manually by the writer by using the Author toolbar Styles drop down menu.