This is the second part of a two-part article about XML. The first part talked about ways to benefit from XML without taking on too much heartache in the sphere of application configuration files, machine-oriented data exchange, that sort of thing. In this part, I concentrate on using XML effectively in document-centric application areas.

From bitter experience, I have learned that the only way to approach document-centric XML applications is from the content creation and modification side of the application functionality spectrum. There is little point in having a wonderful back-end system for content management and exploitation if there is no author-friendly way of creating and modifying that content.

Back on pre-history, before XML existed, my SGML chums and I used to champion what was called the rainbow DTD. Back in those days, most WYSIWYG word processors had either completely opaque, binary file formats or nasty composition-oriented markup that was difficult to parse. The idea behind the rainbow DTD was to standardize on a low level, presentation-oriented SGML format that all word processor and DTP packages could target, thereby making so called "up-translation" to SGML possible.

Time has moved on. The world now has a number of candidate DTDs that fit at least some of the original goals of the rainbow DTD. The most common currently is (X)HTML which has emerged as a sort of intermediating data format between all sorts of applications. More recently, ODT and OOXML both fit nicely into rainbow DTD territory in many respects.

However, as time has moved on, so has thinking about how best to create author/edit systems for XML-based applications. There was a time when the standard mantra involved creating a custom schema and then configuring an author/edit tool to target that custom schema. Some folks still champion doing it that way but there is no denying the impact it has on users who are very comfortable with WYSIWYG word processors.

Much of my work involves doing whatever is necessary to make the author/edit systems comfortable to use. How can I do that while still having all the benefits of custom XML schemas on the back-end?

The trick is to realize that styled XML coming out of an (X)HTML editor, an ODT editor or an OOXML editor, can all be used as input to an XML up-translation tool chain. A significant amount of structural inference can be performed using nothing more complex than paragraph and character styles. Purists may baulk at it but I find it very effective.

In short:

• Leverage word processor tools that your users already have
• Up-translate on the server side, apply schemas or business rules via Schematron and report structure problems back to users
• Remember that the users are the most important part of any document-centric XML application. If you need to do more work on the server side because users are lax with structuring content then so be it. Better to do that in a "soft" way than lose the battle to get domain experts to use classic XML-aware editing tools. (There are some exceptions to this but not many in my experience.)

This approach is gathering steam now that most mainstream WP/DTP packages have support for importing/exporting XML-based variants of their native file formats. In a growing number of cases, the native file format is in fact XML-based.

Strongly related to this is the growth of micro-formats/RDFa which show the benefits of hiding structure information inside existing author/edit friendly formats such as HTML.

I have seen a number of compelling value propositions for XML-based document/content management systems wither on the vine because of failures to deal with the fact that the author/edit side must be familiar and intuitive to users. No amount of beautiful server-side value will save you if your authors are not happy. Think long and hard before you decide to force them to down their familiar word processors and don classic "XML-aware" authoring tools.

Part 1

ITworld.com

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine