XML-Editors vs. HotDocs for Document Automation: It’s All About the Output
The predecessor to HotDocs was a technology called CAPS (Computer Automated Practice Systems), which was a comprehensive standalone solution that enabled the development of powerful, process-driven document automation (document assembly) systems, capable of managing every aspect of a law office’s practice. Because it was our own environment, we could build whatever features into it that we wanted, a fact that enabled us to make CAPS very powerful.
The Downside—Word Processor Integration
The downside of CAPS—aside from the fact that it was DOS-based—was that it was a standalone application. That’s right, a classic case of an application’s strength also being its weakness. In the case of CAPS—at its core, a document automation system—its weakness was that it didn’t work well with the reigning heavyweight word processor of the day: WordPerfect. In fact, to make CAPS work at all with WordPerfect documents, we had to build a WordPerfect clone inside of CAPS. Of course, the clone was a mere shadow of the real McCoy.
A system author would import a WordPerfect document, in the process converting it to a CAPS document. Of course, many important characteristics of the WordPerfect document that were not supported by CAPS would be lost forever, such as auto-numbering, styles, tables of contents, and footnotes/endnotes. Output from the CAPS system could be converted back into WordPerfect, but, again, only features supported in CAPS would be present in the resulting WordPerfect document.
The Paradigm Shift—Live in the Word Processor
Today, this process sounds completely dysfunctional, but it actually worked pretty well, primarily because we were dealing with DOS. Proportional-spaced fonts weren’t yet an issue. Pagination was a simple matter. Graphical elements hadn’t yet come on the horizon. But they were about to.
That’s why the nifty new HotDocs, the company’s first foray into the Windows world, would require a complete paradigm shift. The idea of replicating Microsoft Word—even early versions of Word—seemed crazy for a small company. Windows-based word processors were complex. Feature sets replicated like field mice. There would be no way for us to keep up, and any lack of functionality would be obvious, the proverbial sore thumb sticking out.
The fact is, in the Windows environment, with its thousands of font faces, multi-column formats, graphical components, and sophisticated pagination features, the word processor would be king—home-base for all of an enterprise’s documents. And we were lucky enough to recognize that. There was only one solution: abandon the power and flexibility of our own environment and move our tool set into the word processor environment.
Today, that’s the secret to HotDocs’ success. We allow you to design and build templates right inside the word processor, a HotDocs ribbon serving as the gateway into the power and flexibility of HotDocs feature sets overlain on Word/WordPerfect feature sets. In other words, if you can do it in Word/WordPerfect, you can do it in HotDocs.
A Blast from the Past
So why am I telling you this? Because today, many of our competitors work like CAPS, rather than like HotDocs, except that the environment that they’ve chosen is generally XML-based. Just as CAPS had its strengths, so also does the native XML approach offers some benefits, not the least of which is output formats—XML can be converted to just about any format you want. But just as CAPS had a fatal flaw, so also does the XML approach. In fact, it’s the same fatal flaw that CAPS had:Importing a sophisticated Windows-based word processing document into an XML editor will result in the loss of complex word processing features.
Still, there’s a market for the XML approach. If you’re looking to automate, say, emails for mass distribution, the XML crowd is generally good at that sort of thing. If you want to generate thousands of customized letters based on existing database records and the look/feel of the output can be simplistic without causing problems, XML might be the answer.
HotDocs May Be the Answer
But if you’re an enterprise that produces a lot of documents (maybe a bank, insurance company, law firm, or government agency) and you care how they look—pagination, headers/footers, font faces, etc., HotDocs may be the answer.