X Marks the Spot: Let’s Take Today’s XML Content-Creation Tools for a Spin

Page 2 of 5

Jun 13, 2006

June 2006 Issue

      Bookmark and Share

The Three Layers of Content Management
Separating presentation (layout, style, format) from content is a CMS cliché. This can be done quickly with cascading style sheets (CSS) and HTML (or better, XHTML). Separating off the presentation into style sheets is a lot harder than straight HTML, but the result is much more manageable and reusable content.

XML further extends the amount of separation so that three basic things result: 1) the XML document containing the pure content itself, 2) a DTD or XML Schema Document (XSD) with the allowable structural elements and their attributes to validate the XML document, and 3) XSL style sheets (possibly XSL_FO and XSLT transformations) to convert the core content document to multiple output channels with different presentations.

The three layers correspond to different types of markup. In the content core, the markup is semantic, with meaningful tags like name and price, the RDF properties that will drive the Semantic Web. In the structural layer, markup is syntactic, with tags like div and span. In the outer layer, markup is stylistic or presentational, with tags like font, b, and i.

The layers also correspond to different professional skill sets—designers on the outside, architects building the middle layer, and content authors in the core. XSD, XML, and XSL are three components like the red, green, and blue signals of component television. Separating CSS from XHTML is, like S-Video, good but not HDTV.

And finally, in an effort to make the objective of XML content-creation tools more readily understandable, here's a railroad metaphor: we can say the Developer Editor tools build the structure rail on one side (the content model) and the style rail on the other (the presentation model) that keep the author/editor on track with guided writing.

Author or Developer? Both
Since almost every major content-creation tool (e.g., Word) can now export documents in XML format, why do you need a dedicated XML Author Editor and XML Developer Editor? Because creating well-formed XML documents is not enough. Your organization needs XML documents that are structured properly. That means documents validated against your content model—the schemas and DTDs that describe allowable content elements and attributes. An XML Author tool will create valid content immediately, instead of starting from Word files, whose XML output must be painfully converted to valid XML. Many organizations create Word templates for authors, then parse the Word XML to match their schemas. XML Author Editors eliminate this time-wasting step.

Second, your XML will need to be re-purposed to feed ever more types of output channels as you exploit multiple opportunities to publish your content. The XML Developer Editor will let your application developers design and build the several XSLT transformations that will be needed behind the scenes to publish your content. So now that we've framed the whys and wherefores of XML tools, it's time to take some out for a spin.

Test Method
We downloaded trial versions of all 12 tools and installed them on a new dedicated test platform at CMS Labs. We read the online documentation (many PDFs we downloaded and printed out). Overall, existing online training was good, though video training from Altova, Stylus Studio, and SyncRO Soft really stood out. When companies offered us personal online training (with screen-sharing sessions), we accepted..

We joined online company forums where they were offered and read some posts to get a sense of the user communities. We also joined independent mailing lists of user groups. When we encountered problems, we first Googled the error message or situation, then we sent in questions to vendor support. We found the company is usually a user's last resource for help.

Once all the tools were installed, we created a test set of XML documents, XML schemas, and XSLT style sheets. We took them from CM Pros' Design Patterns for reporting Best Practices initiative and we simplified one of these to make a DITA XML test document.

We recommend you follow a similar methodology, working with test documents drawn from your own content. If you have no structured content, you have three options:

  1. You can get a consultant to structure your content (or learn yourself). This may be long and difficult, but in the end, a rewarding process.
  2. All the XML Developer Editor tools can extract structure from a collection of similar-instance documents. They infer a content model (allowable elements—you may need to fine-tune the order and frequency). They then give you a schema document you can use to create more documents structured to be consistent with your existing content.
  3. You can work within proposed industry-standard content models like the new DITA structures for topics, concepts, tasks, and references.

Page 2 of 5