Cool Stuff: What's New, What's Cool

I've been playing with the XDocs CMS system. I'm pretty impressed. It definitely gets 4 ice cubes for cool. Maybe even 5. (I'll update this post from time to time as my experience grows.)

Strengths

I was initially attracted to XDocs because of several highly desirable characteristics:

• Very inexpensive: At $5k for a single-cpu license for 3 writers or less, and $10k for 4 or more, it's a hell of a deal. Really terrific price point. And you can have as many reviewers as your server can handle.
  
  
• DITA-ready: There's nothing special you have to do to support DITA. Just install it. It understands how to process maps and produce output. It's built on the Open Toolkit, in fact. That saves them from having to write all that code from scratch.
  
  
• No Configuration: There is nothing in the way of configuration. You open the box. You install it. It just runs. That's it. Oh. Of course, you'll want to declare your metadata. And you'll need to set up your publication processes, but there's not much that you wouldn't be doing anyway.
  
  
• XML Object Datastore: The makers of XDocs sold an XML database (XStream) for seven years before they decided to build a CMS on top of it. So the XML processing, folders, and path addressing aren't warty add-ons to a relational database--hierarchal containment is built into the database engine from the ground up. And given what I know of relational databases, this one just has to be easier to administer.
  
  
• Central Database/Local Files: This was one brilliant implementation choice. The CMS stores XML files in a central repository. But when you start XDocs Explorer, a parallel structure is created in your local file system--same folders and everything. But it's efficient, too. It only copies files when you check them out for editing. After that, it keeps the file around, caching it on your local disk. So you don't have to recopy it if no else has edited it. More importantly, since you have files on your disk, you can edit them using any tools at your disposal.
  
  
• File Locking: When you checkout a file, the copy in the database is locked so no one else edits it. At the same time, the copy on your system is made writable. (If someone goes off on a long vacation, an admin can unlock it.)
  
  
• Java APIs: I like having the files around because it gives me an opportunity to write scripts and processing utilities to massage them. But to do that, I need to interact with the CMS to check out files and check them back in again. XDocs gives me client APIs I can use for that purpose. With JRuby's powerful language features and its ability to invoke Java APIs, I see fun, productive days ahead.
   
• Multiple Views and Access Paths: You can set up a server that lets someone look at the website generated from the data in the CMS, or you can export the contents to files to a website for your normal web server to handle. You can poke into the CMS over the web, and launch an editor that way, or you can fire up their XDocs Explorer client.
  
  
• Sophisticated DITA Export: As nice as it is to use the Open Toolkit for processing, that utility has a major flaw--it attempts to replicate the input file structure at the output location. In setting characterized by reuse, that restriction is inevitably a mistake. (If I have Solaris and Windows conditional text in a topic, I'm going to want to put the generated versions in different directories!) XDocs solves that problem with an export system. To make that system work, they wrote an XML-based pattern processing language, so you can say "put all images in a subdirectory under the topic" or "put all images in some central directory"--and then adjust the links so they work, wherever they wind up. Positively brilliant.
  
  
• Built on Standards: They create very little that's new, if they can possibly help it. So they store publication-variables in a .ditaval file, and they use the Open Toolkit to process DITA topics (but do the work necessary to make it viable in a production setting). When something new is needed, they're pretty brilliant about it. But it's the path of last resort.

Weaknesses

• Editor Integration. You can use any editor to edit your files, but it's nice if you can access the CMS from the editor's menus. XMetaL is the only editor that is fully integrated that way. When XDocs begins to take off, other editors will no doubt follow suit.
  
  
• Link Management. The link management story is still in progress. At the moment, it's not up to DreamWeaver's standards. But they're working on it. And in every other respect, it's like DreamWeaver on DITA steroids.
  
  
• Documentation: This is the big one. Fortunately, the folks at BlueStream are very willing to share their
  time, because it's nearly impossible to figure out how to do anything
  from the existing documents. Some major features like the export pipelines are virtually document-free. That situation is fairly understandable for a small group that does has focused on creating excellent technology, and which does a lot of consulting work. But it's a weakness that could spell the difference between XDocs as the "ubiquitous, no-brainer choice that took over the world", or XDocs as the "really nice system that deserved to do better".
  

Installation

Ok. That was harder than it should have been. It's a 60-minute process that took a day and half due to the meager, sometimes inaccurate documentation. Most of that time was spent hunting for answers and making phone calls.

But still: a day and half is pretty darn good when you compare it to the big systems where you have spend months planning the installation and weeks configuring the system. XDocs is fully set up, right out of the box. So it was a really simple process. It just needs to be documented better.

Other Notes

• Importing topics was a  breeze.
  I already had a bunch of topic files. The next step was to import into the CMS. That was a breeze. Make a folder in the XDocs Explorer window, right click on it, choose "Import Topics", and browse to the directory or files you want. It could not be any easier.
  
  
• Backups are easy
  Unattended backups can be scheduled, and they can be run manually.
  
  
• Export pipelines are awesome.
  The publication pipelines are pretty darn cool, and very flexible. They built an XML-based pattern-specification system so you can tell the system where to put files based on file type and input path. Then they created pre-configured "pipeline templates" that invoke some number of XSL transforms (one, two, three, four, etc.). So you grab the template with the number of transforms you need and fill in the blanks to tell it which transforms to do. There are many pre-built transforms, or you can add your own.
  
  There a couple of limitations,  though. One is that the system only works for XSL transforms, so you can't invoke an arbitrary program or use the cool Ruby-based, XSL-like processor that Martin Fowler wrote about on his website. But since few people will want to do such things, that's not a big limitation.
  
  The bigger limitation is the lack of documentation. I can tell it's a powerful system, but even after they showed me around for a couple of hours, I feel like I'll be hard pressed to do any sort of customization on my own. That suggests we'll need to hire their folks as consultants and look over their shoulder until we get the hang of it. It's not the worst of all possible worlds, but sure changes the price/value equation.
  
  
• Custom Production Scripts are done with Groovy
  How cool is that? When I looked at Groovy a couple of years ago, it really wasn't ready. But I've been hearing good things recently. And an interpreted language like that is an excellent choice for production scripts. (That's one of the things I like about XDocs. They seem to have made the most astute possible choice of technologies at every turn.)
  

Futures

As of this writing, several things are still out in the future, but stuff is in the works: 

• Link Management
  That work is in progress. It may not be 100% there right away, but it's happening.
  
  
• Work Flow
  I'm not a big fan of work flow systems, in general. It takes a lot of time to set them up, and they're too rigid to be useful in practice. There are "blue chip" operations out there that need them. But I'm a big fan or "red chip", agile operations. Still, some people like this kind of stuff. And who knows, I may find a use for it. So it's worth mentioning that it's in progress.
  
  
• Documentation?
  I sincerely hope that a lot of effort goes into the documentation. I plan to keep documenting what I discover, and keep feeding it back for future use. If they take off and become the biggest thing since sliced peaches, I'm going to look positively brilliant for making an early recommendation. But if the documentation act doesn't come together, I could wind up looking pretty foolish. So I really, really hope that everything comes together for the best.
  

Bottom Line

There are no guarantees in life. Sometimes, you have to take a risk. But there ways to mitigate that risk. Minimizing price is one way. That reduces your dollar risk, but if a downstream conversion became necessary, that could be pretty costly. For me, though, I have generally found it worth the risk to invest in a good design.

The notion of a "good" design is understandably a very personal thing, but to me it comes down to this:

It fits into my design thinking.

That's what keeps me committed to DITA, after all--I see ways to use the technology to solve a myriad of problems. The XDocs CMS is like that. I keep seeing ways to use the export pipelines, local file storage, and Java APIs to solve the problems we have before us. When I begin to see lots of ways to use it, I know it's an option worth pursuing.

Resources

• Bluestream: Makers of XDocs
  http://www.bluestream.com/