Hi Melanie...
First off .. Russ is absolutely correct. I'm a big proponent of DITA, and have seen it used successfully in very small to very large organizations. But it is very important to fully weigh your needs against the pros/cons of any content model. I suppose that's why you started this thread in the first place .. but you should be aware of my bias here.
Yes .. DITA doesn't allow nested sections, and to some purists, use of the section element might not be considered to be a good practice in general. One of the big focuses of DITA is content reuse and modularity. In an ideal world you might consider using a nested topic instead of a section and use a map to define the relationship/hierarchy of how that "section" relates to the parent topic. Doing this allows you to easily reuse that section content in other contexts. If you have a large topic made up of many nested sections, you could create a map that represents that topic .. the "root" topicref in that map would be the main topic, and any "sections" would just be topicrefs that are children of the main topicref. A topicref to this map would then be inserted into the main map (or a "chapter map"). Since DITA allows unlimited nesting of maps you can use maps to define certain types of structures that relate to book-based constructs.
Using this technique, you might create multiple maps, that reuse the same content in different ways. One that's tailored for print output and another that's tailored for online use.
The DITA-specific features that would be a bit of work to implement on your own are the various content and module referencing features .. xrefs (easy to implement in other models), but conrefs (in particular conref ranges), topicrefs, and keyrefs would be some work. I'm also excited about using the new coderef feature, which allows you to reference non-DITA files like you would a text inset (this isn't working properly in FM10, but will be when DITA-FMx has been updated for DITA 1.2).
Mostly the tools you'll see that are DITA-specific are authoring and publishing tools .. but also you'll see file/topic management tools of various types. While most of these tools can also be configured to work with a custom model, they will probably have put more time into refining their DITA support so you'll see features that allow easy browsing and management of references (topicrefs, xrefs, conrefs, keyrefs, etc.) as well as other productivity enhancement features. Also, because DITA has become a very common XML model, you'll find that consultants and vendors will be more familiar and comfortable with that model. If you send your DITA topics out for localization, it's likely that there will be fewer questions and errors than if you send off content in a home-grown model.
If you're happy with your current tools and workflow, then many of these potential benefits may not carry much weight, but the thing that I like the most about DITA is that it frees your content from proprietary tools. That doesn't mean you won't still need to buy proprietary tools, but it's going to be easier to move to another tool when/if that time comes. Granted, just moving to XML starts to give you this benefit, but over the coming years there will be more and more cool tools coming along that support DITA.
One thing that might have been good to clarify up front .. when you say "getting started with structured FrameMaker" .. do you mean that you're looking at using "binary" structured FM files or XML? If you're staying with binary FM files, there's much less reason to worry about using DITA .. in fact, I'd recommend not using DITA as binary FM files. You can gain big consistency and efficiency benefits by using structured FM binary files, but the additional benefits come from moving to XML.
Cheers!
...scott
6
Replies
AdChoices