i think you've got the main advantage of using DITA. its the conceptional approach (information based, specialization based)

having this in mind and applying this to docbook you see that docbook is the opposite of this. output based, generic based

in DITA you only get a small set of vocabulary and some example specialization from a software company (ibm). each company planning to use DITA have to focus on their particular, special requirments and enhancements on a limited set of basic concepts without loosing interoperability with other DITA users. in DocBook you have to focus on not needed requirments which is much harder to do in my point of view.

the specialization provided by DITA OT is very related to software domain of course thats why default task looks like it looks like ;-) but you have the choice to create your own task based on default topic....

in detail there are many more differences between DITA and DocBook and there are of course use-cases for both of them. but to be honest the DITA approach is much more scalable by design than DocBook ever was.

A way of handling hierarchical IDs, less hairy than creating your own media type and fragment id standard, would be to make the IDs hierarchical at the point of definition as well as the point of use. Using _, -, ., or · (MIDDLE DOT) as the hierarchy delimiter would make it straightforward to verify the correctness of the hierarchy using XSLT.

Oh, sure, there are lots of ways to manage IDs. Part of the pleasure of this exercise was working out how to implement some of the features of DITA. If DocBook wants to adopt some or any of these ideas in principle, then we can look at the technical solutions on their own merits.

In addition to conref, isn't DITA re-inventing architectural forms? I'll also have to bring up Information Mapping, the Unification Church of granular content architecture. (Sorry, I just read Andrew Orlowski pointing out that if Web 2.0 is people, it has a lot in common with Soylent Green, so I'm free associating.)

It was interesting to see how much DITA comes up in the schedule for XML 2005, so we'll all be talking about it there.

Bob

Yes, the system of fixed attributes in the DTD is, if not actually architectural forms, very much like architectural forms.

That's an impressive plunge into some of the core DITA principles, Norm. Also, that's a good demonstration of DocBook's well-designed customization mechanisms — that it's possible to create a hybrid with some DocBook features and some DITA features.

To fully embrace specialization and the topic paradigm in DocBook would take more effort (of course) than adding an attribute that's equivalent to the DITA class attribute and a tree structure that's equivalent to the DITA map. The DocBook committee would want to check each of the DocBook elements to make sure that the assumptions are still valid when topics are reused in many contexts. For instance, the committee would want to think hard about managing links outside of the topic content so embedded links don't become a constraint on reuse. The committee would want to look seriously at loosening up the content models to enable specialization. The committee would want to look at reorganizing the DocBook schemas as pluggable modules, possibly refactoring some of the existing elements (for instance, the inline and reference elements) as specializations. The DocBook transforms would have to be rewritten so the processing of base elements applies to specialized elements. In every change, of course, the committee would want to manage backward incompatibility.

The DocBook committee certainly has the ability and could take the time to do that work, but I'd ask whether adding topic orientation to DocBook really applies the limited resources of the DocBook (and for that matter DITA) committees to the best advantage of our communities.

Instead, would it be better to implement processing strategies that encourage interoperability between DocBook and DITA?

* Specializing the DITA elements with DocBook element names so people can create topics that look a lot like simplified DocBook sections and refsections, are valid DITA specializations, and are 100% interoperable between the two vocabularies (meaning that a roundtripping transform is possible for the simplified content).

* Supporting DocBook books that include content by reference from a DITA map. If we had a high-fidelity DITA-to-DocBook output transform, we could preprocess DITA topics to produce DocBook content and then process the result with DocBook tools.

* Supporting references from a DITA map to DocBook articles. If we had a high-fidelity DocBook-to-DITA output transform, we could preprocess the DocBook articles to produce DITA and then process the result with DITA tools.

That way, users could author DocBook-like topics, still take advantage of other DITA specializations, pull DocBook articles into DITA outputs, and pull DITA topics (including DocBook-like topics) into DocBook outputs. Better for everyone, no?

Even though it seems feasible to customize DocBook to cover most of DITA features, it seems to me that DocBook is not particularly suited for a topic-driven content. As indicated above, the "DocBook's legacy" (coming from TeX perhaps) makes it not a natural fit for a "topic driven" content.

I just flatly, unflinchingly, completely and entirely disagree. Given a <topic> element that lacks the traditional semantics of occurring in a sequential flow (as chapter and section have, for example), there's absolutely nothing that I can think of that makes DocBook less suitable.

In fact, DocBook already has such an element, <article>, but that doesn't seem to suit the topic-oriented proponents. Perhaps because it can't obviously be subclassed into specific types of article.

The idea of building non-linear structures with DocBook and pulling them together with an explicit map file has existed, in practice, since at least 2001 when the "Website" doctype was released.

I've been struggling with this question for a real implementation for some time. While I agree that DocBook can be made to behave like DITA, I really think there is a fundamental philosophical difference between these two ways of creating and thinking about technical content. To use some crude analogies, you can eat pasta with your fingers or go off roading in a sports car too. But these are not the best tools for the job.

The tag names in DocBook carry more than emotional weight; they carry meaning, and that meaning is very specifically tied to the ancient, venerable, honorable and glorious book. DITA is designed for the creation of modular topics, not as an overlay but as its core purpose. It is designed to move us away from the book as the primary entity through which technical knowledge is conceived, created and disseminated.

I was involved in a pilot in the late 90s where we invented something very similar to DITA, and have spoken to writers from other companies who did the same thing. People were independently inventing these things because DITA addresses a real and pressing need. And as we move increasingly into an online world where we digest information in screen-sized chunks, I believe the logic behind structuring information in a way that is not tied to the book and that intrinsically addresses the non-linearity of online navigation will become increasingly compelling.

All that said, for my real world implementation, I am leaning towards DocBook, simply because my company’s existing technical library is … books. So, in my view, the adoption of DITA over DocBook will be a slow process. But then, so was the introduction of utensils for eating.