Nesting topics

["Paul Prescod" <paul.prescod@blastradius.com>]

There is something big I don't understand about the nesting sections discussion. Those who are against nesting sections are FOR nesting topics, and say that that is because they are trying to promote a topic orientation. But I'm sure we all agree that topic orientation isn't about quantity of topics. It seems to me that there are important qualitative measures like "how reusable is this topic separate from its context." Encouraging subtopics is (in my opinion) encouragement to create topics that are _qualitatively_ not very reusable. If I were of the belief that strictness of topic-orientedness is important at all levels of DITA then I would actually argue that topics should be disallowed from nesting. But instead the most dedicated advocates of topic-orientation are promoting sub-topic structures. I would appreciate it if you would help me to understand your position better. I personally dislike nested topics both from the points of view of information architecture (make them standalone!), content management (make them separately tracked objects!) and simplicity (maps and nested topics present two different ways of establishing a hierarchy of topics).

Another part of this that I seem not to understand is the argument that making a section into a topic makes it "more reusable" -- "just in case someone wants to reuse it." I find this hard to understand for two reasons: 1. Making something reusable is typically a conscious choice involving content rewriting. 2. Every element with an ID is reusable in DITA through conref. Topics are only "more reusable" to the extent that that is how they are written and managed. In my (probably naïve) opinion, if a topic is meant to be reused indepdendently then it should be its own, context-independent file with its own metadata, managed independently on the CMS or file system. And if it is not meant to be reused independently then it should not be a topic.

It doesn't matter whether you are using a CMS or file system. The more advanced your tools, the less you need to depend on file nesting in order to see some context. The more primitive your tools, the more you need separate files to help you find your content and manage your locking.

===

By the way, it is hard to reconcile the following statement with DITA's topic nesting capability: "...topics have no internal hierarchical nesting; for internal organization, they rely on sections that define or directly support the topic."

http://www-128.ibm.com/developerworks/xml/library/x-dita1/

I suppose this is true if you define "internal" very carefully but my team found it a confusing statement.

===

And while I'm on the subject: can someone explain the reason that the type-specific doctypes[1] disallow nesting of other topic types[2], but generic "ditabase" topics have no such limitation[3]? Obviously the DITA team went to quite a bit of work to make them inconsistent but it isn't clear to me why that is.

[1] "PUBLIC "-//OASIS//DTD DITA Reference//EN" etc.
[2] <!ENTITY % reference-info-types "reference">
[3] <!ENTITY % info-types   "topic | concept | task | reference">

 Paul Prescod