What does Wiki have to do with DITA?

The Central Texas DUG presentations on Wikis and DITA, and Eric Arnstrong's excellent review of the benefits of structured formats and DITA compared to alternatives like a Wiki, raises the question of whether we are perhaps trying to force DITA into too many places.

Eric focused in on the reason structured formats are difficult to use -  they force you to learn the tagging structure (DITA has about 120 tags, DocBook 800, and XHTML only about 80).

We should resist temptations to add tags (except in specializations) and preserve DITA's reputation as a great starter set for structured writing.

I am interested in the use of a wiki as a knowledge base for DITA. The DITA.XML.org knowledge base was recently transformed into a Wiki format, using the wiki functions of the Drupal software used at XML.org. See http://dita.xml.org/wiki

Our staff and a few volunteers are putting in a lot of work on the wiki, but it is still a bit thin. The hope is that the community will contribute content. That's what wikis are supposed to be about. My own wiki experience is that someone has to prime the wiki pump with a lot of content. That's what I did with the CMS Wiki and the DITA Wiki at DITAWiki.org.  But it too has had little community input so far. 

I have criticized the simple notion that a wiki just fills up with content in an article in the current issue of EContent Magazine, attached below.  

The article mentions efforts to use the DITA Storm web-based browser as an interface to a true DITA structured wiki, something that Don Day has been boosting in TC and Editorial Board meetings.

___________________________

Wikiful Thinking 

For those wishful thinkers who dream of corporate “knowledge management,” few tools are more seductive than the enterprise wiki.

The dream goes like this: Just set up a wiki (really inexpensive because some tools are open source and free), and it will miraculously fill up with all the knowledge, explicit and tacit, that represents the institutional memory, the know-how, the core assets of any organization.

In the idyllic wiki Web 2.0 future, all your mission-critical information will be easily accessible with a quick keyword search. What’s wrong with this picture? We have plenty of evidence in its favor. Hasn’t Wikipedia shown us all the way?

When Larry Sanger convinced Jimmy Wales in January 2001 to try Ward Cunningham’s idea of the wiki as the quickest way to collect knowledge, it transformed Wales’ idea of a free online encyclopedia. In all of 2000, Wales’ original Nupedia had produced only 12 articles. Yet, as if by magic, within a month of inception, the new Wikipedia had 1,000 articles; 8 months later it passed 10,000. Today it has 5 million registered editors, with 8 million articles in more than 250 languages, and about 2,000 new articles are added every day.

Yet, as the cautionary warnings say, “Your mileage may vary.” If your corporate wiki is not as full as you would like, don’t blame the tool. Content and knowledge management have never been about tools and technology; they’re about people and processes. However, as CM tools go, the current crop of wikis is woefully weak. Wikipedia’s success has been in spite of the wiki tool used, not because of it. The magic was in the social network of individuals who wanted to make a free internet encyclopedia.

Wikis are weak because most do not employ standards-based technology and are clueless about today’s content management best practices like content reuse, modularity, structured writing, and information typing. Lack of standards means that every wiki uses a different markup language to create its special content like hyperlinks, bolded or other text styles, tables, etc. Just consider the number of wiki dialects and their wacky wiki names: DokuWiki, Kwiki, MediaWiki, MoinMoin, Oddmuse, PbWiki, PhpWiki, PmWiki, SlipSlap, TikiWiki, UseMod, WakkaWiki, and WikkaWiki.

This lack of standards-based development results in a lack of interoperability, poor metadata management, and little reusability within the wiki itself. 

Consider the basic Web 1.0. With an ordinary HTML webpage, the amazing “View Source” link allows you to copy and paste the webpage HTML content into another webpage. This is a primitive, but very easy, reuse of content. If you were to paste the HTML into another page, the new page would look the same.

With a wiki, View Source shows you not the wiki markup, but the HTML that was generated by the wiki from your wiki markup. If you copy content from a wiki, you cannot paste it into your wiki or another wiki to use it as a starter page. As a result, wikis have poor reuse of content. (SuLaine Yeo and Eric Armstrong point out that within some wikis there are good reuse methods, templates, copy and paste, and transclusions. But it is not the same as DITA reuse? And does the DITA.WML.org wiki do this? The DITA Wiki is based on MediaWiki, same as Wikipedia.)

The dominant method of wiki navigation is the search engine—both built-in and web-based. Wikipedia is now one of the 10 busiest sites on the web, and Google searches frequently have a Wikipedia entry on their first page of search results. The typical wiki entry point is a deep link, so it must be easy to find the way back to the wiki homepage. Wikis can use the latest categorization and tagging schemes and can generate RSS feeds to notify those following their growth of content blow-by-blow.

We hope to see still more standardization of wikis as they are increasingly built on structured XML in the future. The ideal wiki would just use XHTML and a WYSIWYG editor interface for unsophisticated content contributors. Underneath, it would have hidden structure to facilitate information retrieval. Brute-force full-text search is good, but it’s not good enough.

In the structured writing community, the new DITA XML standard has encouraged hope for a DITA-based wiki tool. The only such effort, DITA Storm from Log Perspective, was recently acquired by Inmedius, the XML CMS vendor strong in the S1000D structured documentation space.

Different markup methods and storage formats make for difficult content migration when (not if) you want to move your wiki full of mission-critical corporate information to an improved future tool. So while making the wiki dream come true isn’t actually contingent upon the tools, we must dare to dream of wiki tools that play by the standards so that the content is as flexible as the environment purports to be.

In particular, I am optimistic that structured authoring, at the simplest level, doesn't have to require training or be difficult to learn. A simple DITA topic is just simplified XHTML with a couple of extra fields (distinguishing short description from body, for example) - something that could be handled in a WYSIWYG editor with ease.

 

Michael Priestley

XML.org Focus Areas: BPEL | DITA | ebXML | IDtrust | OpenDocument | SAML | UBL | UDDI
OASIS sites: OASIS | Cover Pages | XML.org | AMQP | CGM Open | eGov | Emergency | IDtrust | LegalXML | Open CSA | OSLC | WS-I