Docbook and DITA

Eliot has responded to another bloggers input, subject docbook and DITA as a solution to an XML-based document-centric application. I respect Eliots experience, just wanted to question some of the statements he's made about docbook. In the same way that Richard Hamilton declares his standpoint, perhaps Eliot should too? AFAIK he's been hacking DITA seriously workwise for some time. Equally, due to my lack of use of DITA, I'm wholly Docbook biassed.

Both writers seem to hack on the DITA 'specialization' (customization) quite a bit. I believe this is a way that DITA has of using new markup, yet stating that my element x:element is really a DITA y:element. I think this is a way of reducing the styling work and putting the element some place in the schema structure. If my beliefs are right, then the higher level objective is adding elements to the schema and styling for the output media you need. Using relax NG, docbook makes adding (and removing) elements from the schema quite easy. XSLT customization makes styling new elements equally easy, though the caveat is that the author must understand those two technologies. How much do I need to understand about DITA to do the same? I think Eliot does this for a living, so perhaps his view is that the specialist does this for others to use? I don't know.

Richards comments about Buzz made me chuckle. He definately has a point. However, the buzz clearly favors DITA. I'd agree, also that Buzz sells technology, since managers and bean counters seem to buy and select more tech than geeks.

One item that impacts authors and seems not to be accounted for is the element count. This does seem to favour DITA, since it really is daunting to be faced with a choice of a hundred names that mean little (without guesswork) when all you want is a para. DITAs smaller element set should provide a real world advantage.

Eliot makes a point:

Because DITA offers a number of very important features that DocBook does not, in particular specialization, modularity, and external links (relationship tables), and because DITA can be configured to work as well for non-modular documents as DocBook can, and because DITA lowers the cost of developing new element types as low as it could possibly be, I've come to the conclusion that DITA is the best answer for any XML-based document-centric application I've seen.

which I find odd. How important is specialization in the scheme of things? In smaller projects possibly. In larger ones probably quite insignificant. I must confess I don't understand the external links bit. I understand DITA majors on linking blobs of XML info via various means. Doesn't this just leave more room for error?

With any DocBook application, if you define new element types, there is no defined way to map those back to existing types and DocBook processors are not designed to handle new types by processing them in terms of some base type. That means that if you define new element types in a DocBook context you must update all processors that need to act with those documents even if all they need to do is nothing with those elements.

Agreed there is no defined way to map these back to existing elements. Why would I want to? Only if I went out looking for DITA functionality? Also I only need to style new elements for the media I use. If the 'new' element is going back to docbook main schema then the docbook team seem to make an excellent job of integration. The ease with which XSLT, using import, enables me to style non-processed elements (after the main stylesheets warn me that they aren't styled) makes this almost trivial.

Summary

I'd still back up and say it's horses for courses. I'm more at home with docbook. Probably Eliot is more at home with DITA. The choice is more properly decided on the users background, ease with XML processing and the way in which the content is to be used.

IMHO