Implementing XML in a Recession

With the economic hard times, a lot of proposed projects that would allow companies to leverage the real advantages of XML are being shelved until economic conditions improve.  Obviously, in my position, I would love to see more companies pushing to using XML throughout the enterprise. We’ve all heard of the advantages of XML: reuse, repurposing, distributed authoring, personalized content, and so on. These are underlying returns on investment for implementing an XML solution.  The old business axiom goes, “you have to spend money to make money.”  A corollary to that might suggest that getting the advantages of XML must mean spending lots of money.

However, here’s the reality: implementing an Enterprise-wide XML strategy doesn’t have to break the bank. In fact, with numerous XML standards that are ready to use out of the box, like DITA and DocBook for publishing and XBRL for business, the cost of entry is reduced dramatically compared to a customized grammar. 

And while no standard is always a 100 percent perfect match for any organization’s business needs, at least one is likely to support at least 80 percent.  We often consult our clients to use a standard directly out of the box (or with very little customization) until they have a good “feel” of how well it works in their environment before digging into the real customization work.  Given that funding for XML projects is likely to be reduced, this is the perfect opportunity to begin integrating one of these standards into your environment, try it on for size while the economy is slow, and when the economy improves, then consider how to customize your XML content to fit your environment.

Any XML architecture must encompass the ability to create content and to deliver it, even one on a budget.  Here again, most XML authoring tools available on the market have built-in support for many of these standards, with little to no effort, you can use these authoring environments out of the box and get up to speed. 

On the delivery side, these same standards, and in many cases the authoring tools have prebuilt rendering implementations that can be tweaked to deliver high-quality content, with all of the benefits that XML offers.  In this case, you might want to spend a little more to hire an expert in XSLT.  But it doesn’t have to break the bank to make it look good.

The bottom line: A recessionary economy is a golden opportunity to introduce XML into the enterprise. In the short term, keep it simple, leverage other people’s work and industry best practices and leave your options open for when you can afford to do more.  Over time when funding returns, then you can consider adding more “bells and whistles” that will allow you to more closely align your XML strategy with your business process.

I Don't Care How the Sausage Is Made

There's a common notion that you don't want to know how sausage is made if you like eating them. In fact, there's a butcher (reminiscent of days gone by) down the street from where I live who makes all kinds of sausage from "old family recipes". What I read into this sort of thing is the butcher is saying, "Don't ask, I'm not telling." To which my reply would be, "I won't, because it tastes good."

In much the same fashion as I don't want to know what goes into the sausage, many writers I've had the experience of working with or consulting for really don't want to know or care about angle brackets, tags, attributes, containment, content models, namespaces, DTDs, schemas or processing instructions. In other words, "Let me write, and get out of my way!"

Part of this sturm und drang over markup languages is partly the unintended consequences of sophisticated desktop publishing tools that enable virtually anyone to create publication-ready content. The problem is that structure and semantics takes a back seat to formatting and presentation. And for the last 15-plus years, DTP applications have been the main tool in the writing tool chest. It didn't matter that the underlying format was proprietary - it just worked.

But the price of "freedom" with using these tools resulted in additional overhead to ensure that "publication-ready" content conformed to internal company standards for style and format.So here comes XML, with its promise of unlocking content from format and proprietary binary formats read only by proprietary applications. Structure and semantics now matter. In so many ways, this is a great thing. Consistency can be enforced by the underlying schema - no rogue "Heading 1" styles followed by a "Heading 3" or funky new format styles that deviate from the corporate template. Better yet, no more tedious hours reformatting content from other sources like OEM content, or being limited to "one-off" copies from originals.

The rub is that the tools needed to write XML put more onus on the writer to understand the content model. Even if these tools hide or abstract the content model, there is still a significant change management issue to train users that structured content authoring is signficantly different than what they might be used to. In exchange for "creative freedom," back-end publishing systems now have a reliable content to work with. But the problem is that some folks creating the content feel like they've gotten the short end of the stick. For those that do feel short shrifted, it feels like they're right in the middle of the sausage factory.

The real challenge is to develop tools that make XML content creation simple. Users don't want to know a hyperlink or image is marked up, they simply want to identify the URL and link text. Similarly, some users don't care if the content model is using a CALS or OASIS Exchange or HTML table model, they want to insert rows and cells. In many respects, this seems to suggest that the current markup complexity is getting in the way.

Many of the tools do have WYSIWYG-ish views into the content. Yet, as Eric Armstrong pointed out, even these tools fall short and tend to confuse users when they want to insert a particular element or structure not allowed in the context of the current cursor location.In many regards, this is too much overhead for the average user. They want to have a tool that allows them to insert paragraphs, lists, tables, images and section headings. One suggestion might have a higher level abstraction layer that all tools can easily support, and build the more complex XML markup under the covers.

One possible approach might be to use HTML-like WYSIWYG editors that support basic content structures. Under the covers, it can convert the HTML into more complex structures required by grammars like DocBook and DITA. In fact, the Interoperability Framework Scott Hudson and I have worked on uses this same approach.

While this type of approach takes away some control over very specific semantics, it reduces the complexity and clutter that more structured models introduce. That doesn't preclude editing tools to be smarter about how they enable more specific semantics. Much in the same way many HTML editors display a popup dialog for users to specify the URL and text for a hyperlink, tools can provide users with other dialogs for specifying (more like classifying) an abstract span element to indicate more detailed meaning.

This is not to suggest that "non-narrative" content, like data structures or configurations that are are used by many modern applications will want to use this approach. However, publication level markup can take advantage of this type of approach to simplify how users create content, and honor their request to remain unaware of how the sausage is made and will be happier to create content in a model they do understand.