FYI:
I couldn’t help myself. In a fit of inspiration, I had to respond directly to yappadingding on DITA topic architecture, stealing some content from my previous posting to this list.
I will ask for forgiveness later, but I am sanctified by the rightness of my views. J
From: Troy Klukewich
Sent: Monday, August 27, 2012 5:34 PM
To: yappadingding@hotmail.com
Subject: Response to topic architecture article
Re:
http://focusonreaders.blogspot.ca/2012/07/case-study-dita-topic-architecture.html
I hate to say it, but I have long suspected that many implementers of DITA don't know what they're doing when it comes to information architectures and output shaping. Myself, I've yet to work on a DITA project that did not output multiple topic types in single HTML file. Why not? <dita> wrappers and dita maps with chunking are obvious mechanisms.
Yet, I have to agree with your post in that I've also seen some truly bizarre "architectures" using DITA. DITA is like a kitchen knife. You can use a chef's knife to create a culinary masterpiece or you can use to commit murder. Unfortunately, murder is easier.
I guess I'm a DITAnista because I'm not seeing a limitation with the tools here at all (as you generally make note of DITAnistas in your post), but a problem with how implementations choose to use them (or not use them).
There is no technical reason that prevents combinations of topic types output to a single file. For HTML output, you can do this via a <dita> element as a wrapper for topic types within a single file or via the dita map pulling content from separate files (which I prefer as it is easy to reuse the individual topic bits later).
From OASIS: The <dita> element lets you create any sequence of concept, task, and reference topics, and the ditabase document type lets you nest these topic types inside each other. The <dita> element has no particular output implications; it simply allows you to create multiple topics of different types at the same level in a single document.
There is also a chunking mechanism in DITA maps that controls output chunking of multiple topic types to single output file.
I would push back on the Information Architects in your company if they are not taking advantage of features in DITA that are readily available and make sense to use for controlling output requirements for users. If you have a use case for combining topic types, I'd demonstrate the user requirement and insist that the implementation support it. The architecture already does.
On all topic-based projects that I’ve worked on for several years now, information developers have provided feedback and helped evolve the system. I sometimes think that new information architects using DITA for the first time (or perhaps developer personnel with limited insight into packaging requirements), do not realize all that the system can do. They need guidance from topic visionaries with an understanding of user requirements.
From your post, it sounds like we need more information out there generally about shaping output as distinct from topic authoring in small chunks. The small chunks do not need to dictate the output requirements. Yet, if the output requirements are not clear, I agree that the path of least resistance tends to support outputting a zillion little chunks in a zillion little files.
Troy
Troy Klukewich | Manager
Information Development | Payroll Localizations
Oracle Fusion HCM | +1 310-343-7688