07.16.11
Posted in Uncategorized at 6:20 am by Administrator
The line between the DITA standard and the DITA Open Toolkit is often blurred in conversation. At least, conversations that I hear. It’s pretty simple, though; DITA is a standard for information markup; the DITAOT is a Java-based set of tools designed to generate output from DITA-based XML data.
The DITA schema itself is a highly complex beast compared to the Docbook standard. It’s designed to allow the extraction of highly evolved forms of online help by virtue of the relationships that the schema can contain. These relationships are nothing that cannot be duplicated in Docbook with development, but they exist in DITA’s stock form.
The DITAOT is a powerful bundle that I’ve come to appreciate more over the last few months, but the sheer number of technologies that have been brought to bear in the DITAOT makes for a bewildering troubleshooting experience. Levering multiple layers of XSL scripts via Ant scripts, masses of variables swapping back and forth, all interacting with a bunch of .jar files. I’ve got an issue with the toolkit dropping whitespace in index entries. If this was a Docbook problem, I’d be able to isolate and troubleshoot every component of the toolchain. With the DITAOT, the parts of the puzzle have been spread over a city block, and not all of them just be swapped out if there are problems. The .jar files, in particular, are problematic because they are the lowest quality components on the toolchain and are a single point of failure for the whole system. Got a problem with them? Learn Java.
Permalink
Posted in Uncategorized at 6:19 am by Administrator
One of the drums that I regularly beat when indoctrinating new users to an XML CMS is to stop thinking that layout and formatting matter so much; the content matters most, and the look of it is a detail. Authors who work in tools like Word tend to get lazy and start using formatting tricks to get around the necessity of clear language and clear thought. Writing clearly is difficult, and I’m firmly of the belief that most of the resistance to XML authoring comes from people discovering that they can no longer take the easy way out of writing their content. When one can’t run back to funky formatting to make up the shortcomings in one’s writing, one needs to actually sit down, think, plan, and write like an adult. This is what I mean when I say that appearance is a detail and content is king. And I believe it, I really do. However…
However, the look of a long document that has been produced by the publishing scripts I’ve created at PMC thrills me. It’s embarrassing, but true. A document that was produced in Word or Framemaker or other tools that allow users to introduce tweaks to formatting may make the individual page that was tweaked look a little better, but when you’re scanning a document hundreds or thousands of pages long, the reliable, mechanical, predictable layout and formatting of an XML-sourced document gives the document as a whole a solidity and air of professionalism that you can just never get otherwise. Everything in its place, everything flawlessly regular, every compromise a consistent compromise. It’s gorgeous.
So the truth is that I’m just a layout junkie like the rest of them; I’m just a junkie on a different scale.
What the heck; go big.
Permalink
« Previous Page « Previous Page Next entries »