XML: How to get the benefits without the heartache, part 2

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.

Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world

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