[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] appropriateness of <dita> root element
Alan Houser wrote: > In deployments where topic-level content reuse was _not_ a driving > factor, I've seen organizations struggle to map legacy content to DITA > topic types, without a corresponding benefit. (Surely some benefit, but > not clearly justified by the required effort to do so). I've also seen > organizations compress migration time from years to months by mapping > legacy content to the generic DITA "topic" type in nested structures. A lot of the client work I've been doing lately has been with non-tech-doc clients and a lot of my design work has been to define generic topic types that simply allow controlled nesting of topics specifically to enable the convenient authoring of "narrative" documents where topic-level reuse is either not needed or not always needed. For example, I'm establishing a general design pattern of defining a topic specialization called "subsection" that is different from topic only in the topic type name--it is otherwise generic (modulo the domains integrated by the shell, of course). I then create specific top-level topic types that represent the roots of specific kinds of things (either entire publications or major publication components), which then allow subsection (and possibly other topic types as appropriate) to nest (and subsection allows itself to nest by default). This results in perfectly usable authoring environment that is essentially indistinguishable from what one would have designed from scratch or using DocBook as a base, but still provides all the DITA goodness the client needs, including the option of making subsections physically-distinct topics, for example. It's also important to remember that with DITA 1.1 and the 1.4.1 version of the Toolkit it's possible to re-use topics via maps regardless of their storage organization (because of the chunk= attribute). So, ignoring the behavior of some CMS systems, re-use and storage organization should be largely orthogonal concerns. But in any case, there are lots of use cases where authoring topics as nested is quite useful, if not a hard requirement. [But note that I would never suggest to a client that they use the <dita> shell directly when creating use-case-specific shells and topic specializations is so easy. I would only possibly suggests its use when you need to do conversion to DITA markup in advance of designing your specific shells and specializations.] Cheers, Eliot -- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 610.631.6770 www.reallysi.com www.rsuitecms.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]