Category Archives: xml
You got it. :) Avisi have developed two nifty macros to display an XML schema (XSD) in tabular and graphic format on a Confluence page. The XSD Viewer is a new add-on for Confluence wiki, and the Avisi developers are keen for input from technical writers and others interested in XML schemas.
I’ve been playing around with the add-on, so I’d love to show you a couple of examples and tell you how to get it working for yourself. I’ve also chatted with Yanne from Avisi, who says that he and his team would love to have your feedback.
Example 1: A purchase order schema
I’ve grabbed the sample schema for a purchase order from MSDN: http://msdn.microsoft.com/en-us/library/ms256129.aspx. I’ve instructed the XSD viewer to start with the
purchaseOrder element, and show a depth of 2 levels.
Example 2: Graham Hannington’s schema for the Confluence storage format
Hehe, if you put Confluence and XSD in the same blog post, then ‘twould be remiss not to include Graham’s XML schema for the Confluence storage format. :D
The XSD Viewer is using
confluence.xsd, starting with the
One point of interest here is that the
confluence.xsd file references two other schema files:
confluence-xhtml.xsd. All I had to do to make this work, was to attach all three XSD files to the page. This screenshot shows the attachments on the above page:
A couple of times, the XSD Viewer has declined to show any rows in the table. I’m not sure why this occurs. If it happens to you too, it’s worth letting the Avisi team know.
I’m using Confluence 5.0.1, with version 1.1.1 of the XSD Viewer. I’m running Confluence on my Windows 7 laptop, and I’m using Chrome to view the wiki pages.
How to get your own XSD viewer
To make this happen, you need to do the following:
- Download and install Confluence, if you don’t already have it. You can try it for free for 30 days. See the Confluence download page.
- Download the XSD Viewer add-on and install it into Confluence. The add-on is also available for free for 30 days. See the XSD Viewer page on the Atlassian Marketplace.
- Create a page in Confluence.
- Attach your XSD file to the Confluence page, just as you would attach a screenshot or other file. See the documentation on adding attachments.
- Edit the page.
- Add the “XSD Image” and/or the “XSD Table” macros to the page. See the documentation for the XSD Viewer.
- Save the page.
- The XSD Viewer page on the Atlassian Marketplace.
- The documentation for the XSD Viewer.
- A getting-started video for the XSD Viewer on YouTube.
- The issue tracker for the XSD Viewer.
Feedback so far
I’ve given Yanne at Avisi some feedback already:
- At first the error messages were a bit too generic to be useful. Avisi have already followed up on this in the latest version of the add-on, which gives more specific error messages. Great!
- Currently the macro autocomplete in Confluence is triggered by “XSD”. Suggestion: Add “schema” and “XML” to the list of triggers.
- Add the option to add a border and other styling to the image.
The Avisi team like the latter two suggestions, and are waiting for more feedback before implementing them. Would you be interested in an XSD viewer in Confluence, and what requirements would you have for it?
Michael started off by telling us what DITA is and giving us some historical background.
What is DITA and who is using it?
DITA (Darwin Information Typing Architecture) is an open standard for designing, creating and publishing modular information, such as technical publications, help sets and websites. The standard is owned by OASIS. It was originally created for technical communication, but was designed to be more broadly applicable. We are starting to see other types of content adopt the DITA standard now too, such as learning and training. As a result, some LMS systems are now adapting to support DITA too.
The latest DITA standard, OASIS DITA 1.2, was approved in December 2010.
A public survey at ditawriter.com conducted a survey and found that around 250 companies have posted public case studies. Breaking the usage down by industry sector, around 30% of companies that use DITA are in the software sector. Geographically, the largest number of DITA users is in North America, followed by Europe.
In technical communication, a survey in 2008 found that DITA was the most popular standard, at 35%.
Michael discussed some case studies from around 2008-9,including the reasons why the companies adopted DITA :
- Avaya adopted DITA to solve problems of low-quality for globalised content, inconsistency in content and style, and problems in training new writers. They reported improvements in these areas, as well as increased user satisfaction and happier writers,
- CaridianBCT adopted DITA to reduce translation costs. They reported savings of $100,000 in the first year.
- Medtronic needed to improve productivity. The metrics quoted were based on the amount of content that the team managed to produce using the new reuse model.
- WebSphere adopted DITA for content reuse in the documentation for their application server product. They report 80% reuse of their content across the entire set. Note that the percentage of reuse required depends on the amount of commonality across the different products.
Michael discussed a study by the Gilbane Group, called “Smart Content in the Enterprise”. One of the most interesting aspects was a shift from an inward-facing to an outward-facing view of the content. Focus on what the users need from the content, and on delivery as the starting point of design.
The core elements are providing metadata, integrating social systems with the content, and using structured content as the source.
Getting practical – DITA topics and maps
DITA is all about chunks of content called topics. This concept has nothing to do with reuse. It’s all about content use. With all types of content other than novels, people jump in and out of a book or manual to find what they need. They don’t read the book from start to finish. What we must do is understand what the user needs to do, and prioritise that over the needs of the product.
Here Michael took us through the core elements of DITA:
- The high-level structure of a topic in DITA.
- An example of a DITA map. A map does all the referencing and organising. You would have a map per output format.
- A map in topic links.
- A map with generated navigation and links. The build process takes the information in the map, and turns it into a table of contents and supported linking patterns.
Michael showed us the underlying DITA tags for conditional processing. We don’t assert that you should include or exclude something. Instead, we assert that it applies to a specific product or products.
Then you set conditions as part of the build process, to include or exclude products, or to flag specific content.
In some cases, you want to reuse a fragment of a topic or a fragment of a map. In those cases, you would use a conref.
A conref is basically an empty element that instructs the build process to pull in the content from another element at publication time.
Note that you should do this as little as possible. In most cases, you would use conditional processing to include or exclude a topic. Reason: If people change a paragraph, it could mess up your content reuse. Topics are a more basic unit of structure, and so are less subject to breaking changes.
The idea is that different types of information are best served by different structures. What’s more if a particular type of information is presented in a particular structure, that will help the user understand the information.
DITA defines a specific set of structures for tasks. For example
Each of the above elements has sub-elements, and rules about what can go where. The task is a type of topic. You can use a task anywhere that you would use a topic. The task has rules unique to it. We call this “specialisation”.
What’s new in DITA 1.2?
- Taxonomies. Michael showed us the big vision of how his team uses taxonomies to provide progressive disclosure from the product UI to the web-based user assistance.
- Learning and training specialisations.
What’s coming in DITA1.3?
The group is working to provide a lighter-weight DITA editing experience, for technical communicators and other DITA users too.
Michael’s presentation style is easy and authoritative. Thank you Michael for an informative insight into DITA.
We’re in the final stages before sending my book off to the printers. Exciting! While we wait, let me tell you a bit about how the publishing team and I have produced the book. We’re using a Confluence wiki and DocBook XML.
- Plan, write and review the book on a Confluence site.
- Use the Scroll Wiki DocBook Exporter to convert the content to DocBook XML.
- Use DocBook XSL-FO style sheets to create a PDF file for sending to the printers.
- Use XSL to generate ebook formats too.
This post is about writing and reviewing the book on the wiki, and converting the Confluence content to DocBook XML – the first two points in the list above. Richard Hamilton, at XML Press, is the expert on the further DocBook processing.
A bit about the book
The book is called Confluence, Tech Comm, Chocolate: A wiki as platform extraordinaire for technical communication. Details are at XML Press. It is all about developing technical documentation on a wiki, with a focus on Confluence wiki. And just to be ultra meta, I’ve written the book on a Confluence site. Dogfooding FTW!
Writing, planning and technical review on the wiki
Richard Hamilton and I have spent the last nine months on a Confluence wiki site. We kicked off our planning there in May 2011. Since then, I’ve spent around 400 hours writing the content on the wiki. Ryan Maddox, our illustrator, has uploaded his images onto the wiki. For two weeks in early December, the technical reviewers joined us there too – six knowledgeable and enthusiastic people:
- Alan J. Porter – Writer, speaker, consultant
- Anne Gentle – Technical writer for OpenStack
- Ellen Feaheny – CEO of AppFusions
- Mark Fidelman – Social business GM at harmon.ie
- Robert Rhyne Armstrong – Director of documentation for RouteMatch Inc
- Sherif Mansour – Technical product manager at Atlassian
The wiki was abuzz with review comments, opinions and counter-opinions, laughter and chat.
Now it’s gone a bit quiet while Richard and I work on the last stages of book production. When we launch the book, we’ll open up the wiki site too. You’ll be able to join us there and make it buzz again. :)
DocBook for the publication processes
DocBook is an XML standard for documents, developed by O’Reilly as a means of making their publishing process more efficient. It is now an open standard maintained by OASIS. Richard Hamilton, at XML Press, uses DocBook XML to publish a range of books on the subject of technical communication. Using a customised set of the open source XSL style sheets for DocBook, Richard can create HTML, PDF (through XSL-FO), EPUB and other epublishing formats from the DocBook source.
Converting content from Confluence wiki to DocBook XML
So, I’ve finished writing the book and the reviewers have worked their magic too. It’s all on a Confluence wiki. The content is stored in the Confluence database in wiki format. How do we get it to DocBook so that Richard can create the print and ebook formats?
Enter the Scroll Wiki DocBook Exporter.
Scroll Wiki DocBook Exporter is a plugin for Confluence, developed by K15t Software. (A plugin is a small piece of software that extends the functionality of the wiki. It is similar to an add-on for a web browser.) Once you have installed the Scroll Wiki DocBook Exporter on your Confluence site, you can export a page, a set of pages or an entire space, to DocBook XML.
How to use the Scroll Wiki DocBook Exporter
The first thing is to add the plugin to your Confluence site. You need to be a Confluence system administrator, then you can install the plugin in the usual way:
- Log in as a Confluence system administrator.
- Choose “Browse” > “Confluence Admin” > “Plugins” > “Install”.
- Type “scroll wiki docbook exporter” into the search box and click “Search”.
- Click the name of the plugin in the list of search results, to open the panel showing the plugin details.
- Click “Install Now”.
See the Confluence documentation on installing plugins.
You will need a license key from K15t Software. They provide a free evaluation license that gives you full functionality for 30 days.
Once the plugin is installed, a new option appears in the Confluence “Tools” menu, allowing you to export the content to DocBook format.
- Go to the page that you want to export. If you want to export a set of pages, go to the parent page of the set.
- Click “Tools” > “Export to DocBook”.
- Adjust the options in the dialog that pops up:
When you are ready, click “Start Export”. The plugin will create a zipped file containing the DocBook XML and attachments, and will offer the file to you for downloading.
A sample of the output
Here is one of the book’s pages on the wiki:
And here is an extract of the DocBook XML:
<?xml version=”1.0″ encoding=”UTF-8″?>
<book xmlns=”http://docbook.org/ns/docbook” xmlns:xlink=”http://www.w3.org/1999/xlink” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xsi:schemaLocation=”http://docbook.org/ns/docbook http://docbook.org/xml/5.0/xsd/docbook.xsd” version=”5.0″ xml:id=”scroll-bookmark-1″>
<title>Confluence, Tech Comm, Chocolate</title>
<title>Confluence, Tech Comm, Chocolate</title>
<title>A wiki as platform extraordinaire for technical communication</title>
<para>By Sarah Maddox</para>
Index, footnotes and figure captions
The Scroll Wiki DocBook Exporter supports these too. The plugin adds a number of macros to Confluence, which you can use to mark up the index entries, footnotes and figure captions. I’ll write another post with the details. I’m sure many people are agog to know how this works. ;)
Working with K15t Software and XML Press
Richard and I have worked on this project with Tobias Anstett and the rest of the team K15t Software. They are great people to work with: knowledgeable, enthusiastic and energetic. As far as I know, this is the first time anyone has written a book on Confluence for publication via DocBook XML. We have added new functionality to the plugin, especially for the index and footnotes, adapting and tuning as we go.
Thank you all. It’s exciting to help perfect a plugin that many other authors and technical writers will be able to use.
And I can’t wait to get my hands on a copy of the book!
A couple of weeks ago I attended AODC 2010, the Australasian Online Documentation and Content conference. We were in Darwin, in Australia’s “Top End”. This post is my summary of one of the sessions at the conference and is derived from my notes taken during the presentation. All the credit goes to Dave Gash, the presenter. Any mistakes or omissions are my own.
This year’s AODC included a number of useful sessions on DITA, the Darwin Information Typing Architecture. I’ve already written about Tony Self’s session, an update on DITA features and tools, and about Suchi Govindarajan’s session, an introduction to DITA.
Now Dave Gash presented one of the more advanced DITA sessions, titled “Introduction to DITA Conditional Publishing”.
At the beginning of his talk, Dave made an announcement. He has presented in countries all over the world, many times, and he has never ever ever before done a presentation in shorts!
Introducing the session
To kick off, Dave answered the question, “Why do we care about conditional processing?” One of the tenets of DITA is re-use. You may have hundreds or even thousands of topics. In any single documentation set, you probably don’t want to publish every piece of the documentation every time.
Conditional processing is a way to determine which content is published at any one time.
Dave’s talk covered these subjects:
- A review of DITA topics, maps and publishing flow
- The use of metadata
- The mechanics of conditional processing
- Some examples
Metadata and the build process
Dave ran us through a quick review of the DITA build process and the concept of metadata. Metadata has many uses. Dave talked specifically about metadata for the control of content publication.
Metadata via attributes
There are a number of attributes available on most DITA elements. These are some of the attributes Dave discussed:
- audience – a group of intended readers
- product – the product name
- platform – the target platform
- rev – product version number
- otherprops – you can use this for other properties
Using metadata for conditional processing
Basically, you use the metadata to filter the content. For example, let’s assume you are writing the installation guide for a software application. You may store all the instructions for Linux, Windows and Mac OS in one file. When publishing, you can filter the operating systems and produce separate output for each OS.
In general, you can put metadata in these 3 locations (layers):
- maps – metadata on the <map> element. You might use metadata at this layer to build a manual from similar topics for specific versions of a product.
- topics – metadata to select an entire topic. You might use metadata at this layer to build a documentation set for review by a specific person.
- elements – metadata on individual XML elements inside a topic. You might use this metadata to select steps that are relevant for beginners, as opposed to intermediate or advanced users.
Dave gave us some guidelines on how to decide which of the above layers to use under given circumstances.
Defining the build conditions to control the filtering
Use the ditaval file to define the filter conditions. This file contains the conditions that we want to match on, and actions to take when they’re matched. The build file contains a reference to the ditaval file, making sure it drives the build.
Dave talked us through the <prop> element in the ditaval file, and its attributes:
- att – attribute to be processed
- val – value to be matched
- action – action to take when match is found
A hint: You can use the same attribute in different layers (map, topic and element). Also, you don’t need to specify the location. The build will find the attributes, based on the <prop> element in the ditaval file.
Next we looked at the “include” and “exclude” actions. Remember, the action is one of the attributes in the <prop> element, as described above. Here’s an example of an action:
<prop att="audience" val="novice" action="exclude" />
Dave’s recommendation, very strongly put :) is:
Don’t use “include”. Stick to “exclude”.
The basic rule is: Everything not explicitly excluded is included.
Dave’s final recommendation
Go get DITA and play with it!
It was great to have a focus on the conditional publishing side of DITA. It’s something I haven’t had a chance to get into before. Now I know the basics, which rounds off the DITA picture for me. Thank you Dave for an entertaining and information-packed talk.
This week I’m at AODC 2010, the Australasian Online Documentation and Content conference. We’re in Darwin, in the “top end” of Australia. In this session, though, we’re dealing with wolves, not crocodiles. ;) This post is my summary of one of the sessions at the conference. The post is derived from my notes taken during the presentation. All the credit goes to Suchi Govindarajan, the presenter. All the mistakes and omissions are my own.
Suchi Govindarajan had a catchy title for her talk: “Who’s Afraid of the DITA Wolf?”
At the beginning of the session, Tony Self handed out some pretty coloured squares of paper to each of us. Intriguing! The coloured paper was soon explained. Suchi started by telling us a story about origami. Of course, this set me wondering what this origami had to do with DITA! Good start.
Suchi said that she found it really amusing that she was here talking about DITA. About a year ago, she was totally baffled about DITA. Then she attended a course given by Tony Self. Now she’s here to give a beginner’s view of DITA.
She led us through the steps to make an origami pelican, following the step-by-step instructions in her slide show. I’m hopeless at things like origami, but nevertheless I managed to follow the steps (with help from my neighbour) and make something resembling a bird.
Next, Suchi showed us some text about origami: an explanation of the theory of origami, an investigation of the maths behind origami, and other theoretical scripts about origami. She explained how different texts have different purposes, and not all are step by step guides, and not all are useful to a beginner.
DITA introductory material
What did Suchi’s origami demonstration have to do with DITA? She showed us some introductory material to DITA, pointing out how the texts were full of words and terms that a beginner would not understand.
So Suchi has written her own definition of DITA, specifically for beginners:
DITA is a standard for technical documents that’s designed to be used with XML. It comes with some free publishing tools.
We already know DITA
As technical writers, we already know much about DITA. Suchi showed us how a number of the concerns DITA addresses, and many of the terms used, have been part of standard technical writing for years. Examples are content re-use, topic-based authoring and content models.
DITA has an elegant way of handling these standard technical writing concepts.
How to learn DITA
Before you start, you need only a very little:
- An understanding of XML elements and attributes — just know what they are.
- An idea of the three DITA topic types: concept, task and reference.
Then get a DITA editor, such as XMLMind or XMetal. Suchi usees and recommends XMLMind. You can download a free edition for personal use.
From that point on, the editor helps you to learn the quirks of DITA. Suchi gave us a quick demo of XMLMind, showing us how the editor enforces the DITA rules while you are writing your content.
At this point, you don’t need to know about the complex features of DITA like specialisation, customisation, inheritance, etc. You also don’t need to know about the DITA “topic” topic.
You also don’t need to know about XML rules, validation and well-formedness. The editor will take care of that. You can learn about it later, once you’ve got through the beginner stage.
Because DITA tags are semantic, it’s easy to guess what each element means judging by its name.
Start with a good example. Download and analyse some sample topics. Suchi gave us a link to the DITA OT user guide as a good set of sample topics.
She also recommends this tutorial: DITA for Solo Writers, the Lone-DITA guide.
The real wolves of DITA
DITA is not a wolf, says Suchi. :) On the other hand, the DITA OpenToolkit is horrible. Don’t use it!
Another wolf is ourselves. If you start with a closed mind, it’s hard to learn what DITA offers.
Once you’ve done some editing and created some content, you can start looking at publishing your DITA content. Here’s where you would install the DITA OpenToolkit, but don’t use it. Instead, install one of the other tools that use the toolkit:
- XMLMind DITA Converter
- Other publishing tools you already own
Thank you to Suchi for a calm, reassuring introduction to DITA. Suchi had the audience in the palm of her hand. Her speaking style is relaxed and charming. She told us about a one-day DITA workshop called “DITA in a Day”, that she has created. It sounds well worth attending!