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.
The reception for the App Catalog has been overwhelmingly positive and it is time to officially announce it. Take a moment and see it for yourself. You can browse by category (e.g. communication, authentication, documents) or by type (e.g. app, template, script), and if you are overwhelmed by the selection–there are already over 100 entries–then try out the App Catalog searchbox.
As some of you know, I will be speaking at 
Recently, 
Yesterday, Google announced the general availability of 
