Chunking vs. nesting

At the blog I’d rather be writing there is some concern about navigability when the content set has too many small files. The solution discussed is to use @chunk="to-content", but that’s not the only option.

Although it’s common practice to have one topic per file, it’s not required. If you are not going to be reusing topics in multiple contexts you might prefer to have multiple topics in the same file.

For example:

<!DOCTYPE dita PUBLIC "-//OASIS//DTD DITA Composite//EN" "ditabase.dtd">
<dita>
  <concept id="concept_bm1_q4m_yj">
    <title>About widgets</title>
    <conbody>
      <p>Widgets are very useful.</p>
    </conbody>
    <task id="task_bm1_q4m_yj">
      <title>Create a widget</title>
      <taskbody>
        <steps> ... </steps>
      </taskbody>
    </task>
    <task id="task_bm1_q4m_yk">
      <title>Drag a widget in place</title>
      <taskbody>
        <steps> ... </steps>
      </taskbody>
    </task>
  </concept>
</dita>

The question about relying primarily on TOC is an interesting one discussed by Jonatan Lundin here and Mark Baker here.

5 thoughts on “Chunking vs. nesting

  1. Not all implementations of DITA use files. In the company that employs me, we are migrating into a CMS that uses no files — each topic is an element in a database. To find a topic or a map to check out, you use a powerful search utility.

  2. Glad to see someone talking about this!

    We have found that there are really huge benefits to de-coupling topics from each other by keeping them separate and having a strong linking strategy that only uses inline links when necessary (Taking note from Mark Bakers: every page is page one approach”. The ability to work in parallel, and apply QA (especially in an Agile environment) depends a lot on this. It also opens up some unique capabilities when inside a CMS with native XML support.

    However, higher granularity also means the need for more content management capabilities. Having strong search, and navigation by both folders, publication structure, and metadata is pretty crucial. We’re a CCMS vendor though so we can eat our own dog food in that regard 😉

    Cheers,

    Casey

  3. For cases where there’s no need to reorder, remove, or add subtopics on a page (so the modularity is at the whole page level and not the topic level) it could definitely make sense to nest topics in this way. At least it could give writers a bit more context when they’re editing. Casey, not sure whether I misunderstood what you said, but the EPPO approach is actually geared to page-level modularity, and it may be worth noting that Mark Baker recommends *more* inline links, rather than fewer, though via a soft-linking approach.

    We do keep our DITA topics in separate CMS objects, because we frequently need to re-order, remove, or add subtopics according to particular cases. As Casey notes, it also enables more fine-grained management in the CMS. And there are benefits for translation as well — if you haven’t changed one subtopic on a page, you don’t have to send that content to translators.

    Another thing worth noting: if you consistently chunk topics at the same level in the hierarchy, as we do, you can actually set up your transforms to chunk at that level automatically, rather than requiring writers to add @chunk=”to-content” manually. This could equally work with different values for the chunk attribute, for example if you decided to nest topics for editing purposes but break them out into individual child links in an output destined for small screens.

  4. Within a group of subtopics, is it possible to stop chunking at a particular topic and begin to show the next subtopic as an individual subtopic. I mean, if P1 is a parent topic with N1, N2, N3 as nested topics, can I chunk N1 and N2 and show N3 as individual topic in TOC(still nested within P1)? My N3 further has N3a, N3b, N3c.

  5. I discussed something like this on the DITA users yahoo list. The consensus was that, for some situations, hub topics are a good idea.

    I’m new to DITA but have worked with structured authoring before (principally using AuthorIT in a highly structured manner). In many cases I think that the concentration on Task topics misses the point; tasks are not the same as methods. A task is a job or function someone needs to perform. There may be more than one method for accomplishing the task.

    If you structure your DITA so that methods are all one to a file, there needs to be some way of grouping them together. This could be by chunking, it could be by using a hub task topic.

    I favour hub task topics, as these can be hubs for conceptual information as well as task methods.

Leave a Reply to Joe Pairman Cancel reply

Your email address will not be published. Required fields are marked *


*