OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[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.]


Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 610.631.6770

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]