Today, interoperability is easy with XML. Just make up a data structure to suit your requirements and get it to your target system via HTTP (Hyper Text Transfer Protocol) or any available method of sending plain text. Suddenly, everything talks to everything.

To understand why XML is particularly important to Domino, you need to delve deep into the history of Lotus Notes. Way back when I started using Lotus Notes in the early 1990's, Notes was one of the most closed systems around. There was almost no way of getting data out of it or getting it to talk to anything else in any sort of interactive way. Sure you could export and import views to spreadsheet format or use the COL import format (yuk), but these were highly limited.

You also had the option of using the C API, but this can hardly be classed as "easy" or "convenient." In time, Notes got a slow and unstable SQL (Structured Query Language) driver, eventually Lotus Domino was released, and NotesPump came along. However, it was clunky, expensive, and complex. These developments improved things, but Lotus Notes still wasn't particularly good at communicating with the outside world.

The need for a generic Content Management System arises
Fast forward to early 1998 when I was running an Internet software development company. We were building a lot of Web sites, and clients were becoming more and more sophisticated in their requirements. Everyone wanted text mode and graphics mode. Everyone wanted full text search. Everyone wanted to be able to maintain Web site content in-house, without knowledge of HTML. The list of requirements went on and on. In short, everyone wanted the same things.

I decided that instead of custom building this functionality over and over again for each Web site, I'd design the most powerful, generic site-building system that I could imagine and re-use this for building sites. This doesn't sounds too amazing in the cold, hard, post dot-com daylight of 2002, but in early 1998, such a strategy wasn't so common.

Many of my clients were Lotus Domino based, so naturally this was the target platform for my Content Management System. The software design process commenced, and I spent a great deal of time working out the ideal architecture for the system.

Early on in designing the software architecture, I decided that it was just too messy and difficult to include the content management administration functionality and the content display functionality in the same Lotus Domino database. Any which way I came at the problem, I found that trying to get content display and content management into the same Domino database made it so complex that it collapsed under its own weight. I had to separate the content management and administration from the content display. If I could separate the content administration from the content display, then I could effectively reduce the complexity of the entire system. Finding a clean solution had me stumped, and I had to think outside the square.