If you’ve taken one of my DITA classes, you’ve heard me extol the power of DITA. One aspect of that power is semantic tagging. In DITA, a piece of content isn’t boldface or italics. It’s a command name. Or it’s a citation to another document. Or it’s the name of a screen (a wintitle, in DITA parlance).
That’s a big selling point for DITA, you probably heard me say. Each DITA element represents what a thing is (hence the term semantic) rather than how it looks. Just think: you can take a big document and generate a list of all the command names, or all the screen names. You can’t do that when you’re just tagging things as boldface and italics.
Turns out there are a couple of problems.
- First, I’ve never met anyone who wanted to generate a list of all the command names, or all the screen names. While it sounds good in theory, in practice it’s more like a solution in search of a problem.
- Second, it’s a lot to remember. When is a command parameter a parameter? When is it an option? (DITA has tags for both.) Writers working side by side, writing content for the same help system, might tag the same object in different ways.
Just now, in fact, as I wrote this article, I couldn’t remember the name of the tag for citations. Even though I’m accustomed to using it, I couldn’t retrieve <cite> from my brain. I had to look it up.
Enter Lightweight DITA.
Currently being developed as an OASIS standard, Lightweight DITA (LwDITA) sells itself in two ways:
- It’s simpler than traditional DITA, with many fewer elements and stricter content rules. In other words, it’s less powerful but much less complicated.
- It’s flexible, accommodating (so far) 3 major authoring formats: XML, HTML, and Markdown. (Traditional DITA is authored in XML; rendering the content in the other formats requires publishing software, or transforms.)
For the part of me who loves the power of DITA, who sings the praises of semantic tags to my students, LwDITA was hard to accept at first. Take away the semantic tags, and allow tags that just control the appearance of the content (bold, italics, underline, subscript, superscript), and you take away a lot of what makes DITA special and unique.
I had to get over that attitude.
A lot of DITA writers, I’ve come to admit, simply don’t bother with the multitude of semantic tags — and a lot of DITA writers don’t need to bother. Those who do bother often struggle to use them properly because there are so darn many of them.
LwDITA, wisely, doesn’t claim to be a replacement for full DITA. It’s not a be-all and end-all. According to the spec, it’s designed “for situations in which DITA…would be too complex or for communities that do not use XML as an authoring platform.”
And, for me, here’s the clincher: because LwDITA makes DITA useful and palatable to a larger set of content developers, I’m betting it will eventually increase the acceptance of DITA in our professional community. Writers will appreciate having a flavor of DITA they find approachable. Businesses will appreciate the economy and the flexibility. Everyone will appreciate the gentler learning curve.
Don’t get me wrong. I’m still a big fan of traditional DITA. It’s still the right solution in plenty of situations. But maybe not in every situation. For those other situations, we now have an alternative that still delivers the value inherent in structured authoring.
You have until March 12 if you want to comment on the current LwDITA specification. Here’s my comment: I like it. Its simplicity and flexibility won’t be ideal for every situation, but much of the time they’ll be just right.