Is that XML in your wiki?


Every so often, I get the question of “why would anybody want to store XML in a wiki?” Granted, this question is usually brought up by a competitor rather than by a customer. At first brush, XML just makes things more complicated, but this perception quickly dissipates as your collaboration turns into automation turns into workflows. In this post I share some insights into why MindTouch Deki is built the way it is.

Most wikis use wikitext as markup language. Wikitext is what made wikis popular: it’s fairly easy to learn by semi-technical people, it’s fast to edit, and it doesn’t require much of a user interface. One could say that a wiki without wikitext is not a wiki – since the origin of the term “wiki” is the Hawaiian word “fast.”

MindTouch Deki, on the other hand, uses XHTML–an XML format for content. XML is tedious to edit by hand, it’s verbose, and hence requires a user interface to be usable. It is also fairly complex to combine contributions from multiple authors and highlight changes between versions.

At first brush, one might wonder why choose XML over wikitext? The reality is that wikitext was a great start for the open collaboration revolution – and I do mean revolution, but more on that in another post. But wikitext has its problems. It’s not a standard. Different wiki vendors use different markups. Sometimes, a wiki even makes the markup selectable. That’s not good for promoting uniformity and training users. Wikitext makes simple operations simple and it makes advanced operations nearly impossible. In the end, we have to recognize why wikitext was invented. Wikitext allowed validation of the hypothesis that open collaboration works, without requiring lengthy user interface development. That hypothesis has been validated: open collaboration not only works, it works amazingly well! This was the goal and it was achieved. Usability was not a goal. Now, it’s time to look at what was sacrificed to get us there.

The first victim of wikitext was the WYSIWYG editor. Nobody wants to format content using markup, even wikitext markup. Once formatting becomes a concern, wikitext is starting to show it’s limitations. Regardless of how many resources are being poured into creating a wikitext-enabled WYSIWYG editor, such editor will always be second rate when compared to a HTML editor. Why? Because HTML is an industry standard with lots of competition to create the best HTML editing experience possible. It’s simple Darwinism. Modern browsers support HTML editing. Microsoft Word supports HTML editing. Countless other applications support HTML editing. Why discard all these great tools and start from scratch?  At the end of the day, you would need to replicate everything that HTML already does. That doesn’t sound right.

In contrast, relying on existing standards has many benefits. For example, MindTouch Deki now uses fckEditor for WYSIWYG editing–don’t let the name distract you from this otherwise fantastic editor. Before fckEditor, Deki used Xinha as editor. In the future, Deki may use something else, be it written in JavaScript, Flash, or even Silverlight. As long as the editor supports HTML, the option will be on the table. It also means companies which have built custom user interfaces for Deki, such as Shelfari, can select the editor that best fits their needs. Because HTML is a standard and Deki is built using XHTML, our users have more choices in how they want to interact with their content. And that’s a pretty good thing.

The second victim of wikitext is interoperability. Even if wikitext were a standard, it would still be confined to wikis. What about all the other applications out there? What format should they use to extract or update information in a wiki? Would everything need to become wikitext enabled? This approach doesn’t seem reasonable. With XHTML, you get the best of both worlds. First, you get all the benefits of versatile HTML editors, and second, you get all the powerful tools that have been created for XML. For example with XPath, you can locate and extract exactly the piece of information you want. And with XSLT, you can format this information in anyway you like. XML tools are found in all programming language and enterprise systems. Using XML gives a system a lingua franca that forms the foundation for interoperability. That’s why we made sure that the Deki API provides access to all functionality in XML, including the content of pages.

The last point is about the benefits of native support for XML – and JSON, another popular interoperability format. Once you design an application to store everything in XML and you give it scripting capabilities, you implicitly create something much, much larger. For example, the “other” applications I referred to in the previous paragraph are now simply scripted wiki pages: wiki pages that can read other wiki pages, locate and extract information, and then present this information in an augmented way. This capability is profoundly important: when pages can automate the synthesis and presentation of information, you get a great reporting tool. When these pages can be reused themselves as XML sources, you get a formidable business tool. This ability is what made spreadsheets the #1 business tool. With Deki, this capability is now unleashed unto networks of individuals rather than confined to their individual desks.

The ability to retrieve and process XML/JSON is an integral part of DekiScript, Deki’s built-in scripting language. DekiScript enables users to create composite pages using content from the wiki as well as from web-services. New web-services for business applications and online data emerge every day–ProgrammableWeb is a great resource to learn about them. Deki is designed to take advantage of these and put their power into the hands of your users. This kind of capability would not be possible if Deki had not been designed from the ground up to be XML-based. To get a sense of what is possible, visit our DekiScript forums. I’m amazed every day about what our community is building with it.

In short, the benefits of using XML as the de facto data format and making it core to the platform yields immediate rewards. This is part of our web-oriented architecture and I personally believe it is one of the strongest reasons why Deki fits so well with business applications and online communities. After all, no man is an island, and neither should your wiki.


  1. Since you use XML, would it be possible to import MathML from another software package? There is no wiki, that I know of, that allows MathML. MathML is the only 508 approved method of placing mathematics online, it is scalable, searchable, and accessible. Mathematicians are at a loss when it comes to sharing information online using a wiki, it would be great to have at least one wiki where they could collaborate online, since every software package mathematicians use can export equations using MathML.

  2. I believe adding MathML support would be a trivial matter and require simply adding a new content transform. This is pretty easy to do. I should also mention MindTouch Deki supports LaTex out-of-the-box.

    If you're a customer, the support team can help you with this request. Otherwise the community is quite active and should prove useful.

    I recommend posting this to the forums or asking MindTouch Developers in IRC.

  3. Adding support for MathML would be fairly straightforward since browsers already support it (i.e. no need to transform it). If you know someone interested in helping us get it right by testing it and providing feedback, please get in touch.

  4. For the past year and a half I have been working with a blind student, creating a 2-semester course that could be read by a screen-reader (either Window eyes or JAWS), during my research I found that only MathML and MathJS (Math Java Script) can be read by those screen readers. LaTex, while it has been around longer, and it's primary application was for mathematical journals, it cannot be read by those screen-readers. Since I found out about MathJS after I started production, I don't know much about it. But I do know that the four mathematics programs I'm familiar with, will export MathML.

    Here is what I can tell you I learned from my experience. Internet Explorer will not read MathML natively, nor will it open the webpage, but it will work just fine with a free plug-in from Design Science called MathPlayer. Firefox will read MathML either with a PC or a Mac. Safari cannot read MathML at all, and MathPlayer is only a windows product – however Safari will open up the webpage, even though it cannot display the mathematics correctly.

    I would be more than happy to discuss MathML with anyone at your company, as I have suggested this to many wiki companies and so far you are the only ones willing to give it some thought. [email protected]

  5. Curios to know if mindtouch has made any attempts to insert any type of math product into your wiki?

    • I don’t know. MathML should be a snap though. Nothing to it. As Steve writes above it’s as simple as adding a content transform. If you’re interested in this feature post to the forums or ping Steve with what you’re after.