Hmm. I still don't believe that DITA-style specialization is worth the overhead it adds. Also, what can you do with DITA-style specialization that you can't do with an attribute (e.g. class="checklist") and help from your authoring tool (i.e. the presents "checklist" as if it were an element you can insert even though it really inserts )?

Yes, the overhead concerns me too. That's one of the essays to come.

The overhead that specialization adds translates into the slightly more overhead that a class adds to a document. True, there's the definition of the specialized object (whether it be a domain, element, or attribute) and the required processing to render the specialized object.

However, keeping in mind blind interchange, those costs are not born by the receiver of the content because the default processing for the more generalized object comes into play. The bottom line is that the overhead is paid by the organization that requires the more specific content model and no other organization (unless they require the same specificity).

It seems to me that DITA specialization is about more than just interchange, since it provides a somewhat more formal structure for customization. Where DocBook makes it easy to add new elements to the syntax, DITA goes one further by allowing that element to declare the basis of its semantics, as well. Your DITA-aware toolchain (editor, publishing system, possibly your CMS) already knows the basic behaviors to apply to the element, from which you can then customize.

I think this structure also does more for interchange with DITA than you give it credit for. If I customize DocBook, I might not be able to send my documents to anyone else to work with without my customizations, since they won't be "standard DocBook" anymore, unless my customizations are strictly limited to just reduced content models. If I specialize DITA, I can always very easily produce "standard DITA", at the worst, or send just my DTD specialization module, and any other DITA-aware system will be able to do basic processing.

So, you say, this is just the "blind" interchange scenario. However, DITA specialization encourages creation and sharing of different types of specializations, such as industry-specific tag sets, which can be further specialized by individual companies. So, there's a good chance that the other party with whom I want to share my content will be able to process my content at a level higher than just standard DITA, since they're likely to be using, or at least have access to, that same industry-specific specialization.

This is certainly more than "blind" interchange, and while it may not be "20/20", it is still a step in the right direction. In short, DITA provides an architecture that encourages carefully-planned, downward-compatible customization. The architecture also provides excellent support for multiple layers of customization, each building on the last, so that different groups can interoperate at the highest layer shared by both parties.

I don't think you were wrong the first time around. At the end of the specialization piece you wrote:

"If experience with DocBook is indicative, and I think it is, very few users are every going to make any customizations to the markup at all."

That has been my experience as well. Customizations are few and far between, pretty much regardless of the DTD or schema used. Of course, individual users might do them but organizations for the most part do not. As for specializations in DITA, I've regarded them as a fallback mechanism anyway, not something that's done regularly.

Then again, I could be wrong, too.

Having just worked with a fairly extensive DITA learning specialization specialization (in other words, customized learning content), I can say that the DITA architectural spec for fallback to topic elements is a real benefit. To be able to configure an XML editor to use this degree of customization in minutes using the customer's supplied plugin and catalog files along with DITA OT was fantastic. Since the XML applications are now bundling DITA OT and support for integrating specializations, it is easier than ever to immediately see the results of a topic map or build an output to show that the specialization is working properly.

So, you who have oodles of experience working with DocBook, how does this compare?

On the other hand, I pity the poor developer who created the additional DTDs, ents and mods, and made the plugin and catalog files that use them. This aspect of working with DITA seems hair-pulling to me and I look forward to the rapid development of tools that make it easy to generate specializations for DITA.

For both DITA and DocBook, I'd also like apps to create an very simple subset menu of the DTD (NOT a subset of the elements, just an easy configurable way to exclude sets of elements from an authoring environment) to reduce the cognitive load of finding the right elements in the DTD stack.

I question the statement "The only difference between DITA and DocBook is specialization, and specialization is why DITA is better." What about conref and keyref? Yes DocBook has XInclude, but conref validates and keyref enables indirect addressing. How can I accomplish those things in DocBook?