Why the acronym tags?

One thing keeps bugging me about DITA... Why are a lot of tags acronyms and not natural language? Language is a code for people to learn (as we all know). So why put another code (the acronyms) on top of that? It only serves to complicate the accessibility of DITA. It doesn't seem very DITAish to overcomplicate things like that.

The corporate world suffers from the Acronym Disease, but I would think that professional communicators like us tech writers, would be clever enough to avoid this kind of exclusion and inaccessibility.

I hope that the newly formed DITA Adoption Committee will discuss this issue, as it is especially important for the newcomers to DITA. I know it's a big thing to change to replace the acronyms at this stage, but it will only become harder as more people adopt the standard. Unless there are really good arguments for having acronyms (that I'm not seeing), I strongly suggest that we all start thinking about a way to faze out the acronyms a replace them with natural language. How about making DITA 2.0 - DITA Natura?

I just came back from the DITA Europe conference and is planning a DITA pilot for a part of our documentation. I'm really looking forward to diving into DITA, and the conference reassured me that we can pull this off. I want to be able to 'sell' DITA as best as possible to my colleagues, but I have a hard time defending the acronyms. Please help me find a good way to explain it...('You'll get used to it' is not good enough.) 

Best regards and thanks for a great conference to ComTech and everyone else.

Søren Weimann

Hi Søren,

I myself thought about this issue again and again. And I come up with two suggestions for you without changing the standard :-)

a) Specialize

Be happy that neither para nor paragraph was used by the TC! You can use one of them to redefine what your company or department needs inside <p>. My talk at DITA Europe encouraged to specialize, and limiting the options to your needs is a very valid reason to specialize.

b) Get a decent editor

My XML editor allows "Insert Paragraph" for the DITA starters as well as selecting p from the tag list for the pros. For ordered and unordered lists there are toolbar icons like in Word. This helps both the html ignorant as well as the html addict to get started. After a very short while every one gets used to DITA - and hopefully finds a rewarding benefit for herself/himself. 

With this written you should think twice about my first advice and maybe choose a short tagname for specialization, too?! I use "q-" as prefix for all Qimonda elements like q-ol and q-ul. Short and simple.

-ghk

Gunnar H. Krause, Senior Manager TechDoc, Qimonda AG, Munich

We have some very short tag names that are derived from HTML, such as <p>, <ul>, <li>... Are those the ones you're thinking of? Typically when a tag already existed in HTML, we just reused it, rather than invent a new one - given that HTML is the most popular markup language around, and the semantic intent was the same. When we designed our own tags, we tended to be more descriptive, such as <draft-comment>. 

Michael Priestley

Yes, those are the tags I'm referring to. 

First of all I want say that I regard this to be minor flaw in a well functioning standard.

 However, I don't really see a good reason to borrow from HTML. First of all I doubt that a lot of the people who will be working with DITA tags have worked raw HTML. So familiarity will not help them. Second, why borrow when you can easily do something better. There are a 1:1 relationships between the tags and their natural language denotions.

I'm in a position to judge whether or not this is too late to change, but I think that it should be considered by the committee.

Regards,
Soren Weimann

1) lets people hand-migrate a lot of HTML content simply by copy and paste

2) lets existing HTML editors be more easily repurposed as DITA editors

3) makes transforms to HTML more straightforward, and documentation of expected behaviors easier (<p> remains <p>, <object> remains <object>, etc.)

These reasons may seem trivial, now that DITA is a successful standard with its own range of editors and toolkits. But it did make it easier to get started. And we wouldn't have a standard today if it hadn't been relatively easy to build those first editors and toolkits. By reusing tags we lowered the entry cost for DITA as a standard.

At this stage, it would be very difficult to rename those tags, since it would break all those existing DITA tools. That said, as was already suggested above, most editors already provide human-readable forms of the tags, and when all else fails there is specialization. 

Michael Priestley

XML.org Focus Areas: BPEL | DITA | ebXML | IDtrust | OpenDocument | SAML | UBL | UDDI
OASIS sites: OASIS | Cover Pages | XML.org | AMQP | CGM Open | eGov | Emergency | IDtrust | LegalXML | Open CSA | OSLC | WS-I