Monday, September 07, 2015

A Short Story of Reuse

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

Give the smartest human in the world a piece of wood and ask him/her to make paper. Give him/her no prior tools and it will take years to come up with a decent process which would result in some brown almost usable thick piece of paper.

This blog post is about reuse, not necessarily reuse of tools and materials, but reuse of knowledge. Humanity has evolved not because each generation is smarter than the last one but because we learned to reuse and pass knowledge to larger and larger audiences and from one generation to another.

Almost all tools that we use today are made up of quite a complex set of components which interact with each other. There is no one person in a car assembly factory who still knows all the pieces and how they come together.

Although using the tool is easier than interacting with all components which make it up, you still need knowledge to operate it and in this day and age having enough people to teach how a certain tool can be used is no longer an option. You need to pass knowledge in other forms, on paper or in some kind of digital form. So I would define technical communication as a means of passing knowledge about using tools to a larger audience.

Reuse in technical communication can be structured on many levels:
  • Reuse written content by publishing it to more than one format (PDF, HTML, EPUB, MS Word).

    It turns out that XML is perfect for publishing content in more than one format. XML is not designed to be consumed directly by end users and its benefit lies directly in this. Your XML content should contain all the data necessary for obtaining all the output formats. So if you are using XML in your technical content, no matter what standard or custom vocabulary, you can safely check the first and most important level of reuse.

  • Create larger publications from existing ones.

    Either using an XML standard like XInclude or using standards with their own diverse and powerful methods of reuse like DITA, or by performing custom techniques you can merge XML content in larger publications.

  • Reuse content written for a certain tool to document the functionality and behavior of a very similar tool.

    In most mature XML standards like DITA and Docbook there is this implemented concept of profiling which allows you to dynamically filter at publishing time content marked with certain attributes from your original XML project. In this way from the same XML content you can publish documentation for multiple similar tools.

  • Reuse smaller pieces of common content in more than one publication.

    Again, using XML standards like XInclude or DITA specific standards like content references you can create and maintain small libraries of reusable XML content, then reuse these components across various publications.

  • Reuse images and other binary resources in multiple publications.

    Because XML content does not embed binary resources, these resources are stored separately and thus they can be reused in multiple places.

So these are what I consider to be the main selling points for using XML in technical documentation. As usual any feedback is welcomed.

Wednesday, September 02, 2015

DITA 1.3 Branch Filtering - 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 branch filtering can benefit two cases of reuse which could not be done previously. You can read more about branch filtering in the DITA 1.3 specs.

Case 1 - Combine Two Profiles in the Same Publication

Let's say you have a DITA Project about preparing and cooking vegetables. And your DITA Map looks like this:
<!DOCTYPE map PUBLIC "-//OASIS//DTD DITA Map//EN" "map.dtd">
<map>
 <title>Cooking vegetables</title>
 <topicref href="cleaningTableArea.dita" audience="novice"/>
 <topicref href="preparingVegetables.dita"/>
 <topicref href="addingExtraFlavor.dita" audience="expert"/>
 </map>
You have some content common both for expert and novice users but you also have content which is specific for a target audience. You do not need to teach expert chefs how to clean the table and you do not want to teach novice cooks about enhanced flavoring techniques.
All is fine until at some point you decide to produce a publication which contains merged inside both the novice and the expert map contents. And here's where branch filtering comes for help. You can create a main DITA Map which reuses your current DITA Map with two profiling contexts:
<!DOCTYPE map PUBLIC "-//OASIS//DTD DITA Map//EN" "map.dtd">
<map>
 <title>Cooking Vegetables.</title>
 <topichead navtitle="Cooking for Beginners" keyscope="novice">
  <topicref href="vegetables.ditamap" format="ditamap">
   <ditavalref href="novice.ditaval"/>
  </topicref>
 </topichead>
 
 <topichead navtitle="Cooking for Experts" keyscope="expert">
  <topicref href="vegetables.ditamap" format="ditamap">
   <ditavalref href="expert.ditaval"/>
  </topicref>
 </topichead>
</map>

Case 2 - Reusing Common Topics with Different Product Names

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 potatoes:

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 two consecutive profiled product names:
Peeling <ph product="potatoes">potatoes</ph><ph product="cucumbers">cucumbers</ph>
and include the task in the main DITA Map in two places with different ditaval filters applied:
<!DOCTYPE map PUBLIC "-//OASIS//DTD DITA Map//EN" "map.dtd">
<map>
 <title>Peeling Vegetables.</title>
 <topichead navtitle="Potatoes">
  <topicref href="peeling.dita">
   <ditavalref href="potatoes.ditaval"/>
  </topicref>
 </topichead>
 
 <topichead navtitle="Cucumbers">
  <topicref href="peeling.dita">
   <ditavalref href="cucumbers.ditaval"/>
  </topicref>
 </topichead>
</map>

This kind of usage will produce in the HTML output folder two topic HTML files from the single peeling.dita, one for each filter context.

The DITA samples for this post can be downloaded from http://www.oxygenxml.com/forum/files/branchFilteringBlogSamples.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: support@oxygenxml.com.