Re: [dita] Containers for steps and other elements!?

["W. Eliot Kimber" <ekimber@innodata-isogen.com>]

France Baril wrote:

> Hi, as my project evolve I seem to get into very specific issues.
> 
> I'm not sure we're at this level of details yet, but here it is...
> 
> I have mutliple tasks that use many of the same steps. Somehow, it would
> be very useful to be able to reuse not an element, but a group of
> elements. I'm thinking of containers for elements. 

One of my critiques of the DITA element structures as currently defined 
is that they generally fail to provide for containment options that I 
consider to be both standard practice for technical documentation and 
essential for both productive authoring and easier styling (based on the 
general observation that more containment makes implementing style rules 
easier because you have more opportunities to do things).

For example, I've just started working on a project for a client that 
started out using DITA as an underlying base for a completely 
specialized modular technical documentation system. However, it quickly 
became clear that the DITA topic structures were simply too restrictive 
in terms of where containers are allowed in order to make DITA directly 
usable as the underlying architecture. Therefore, we are forced to have 
a system that is "informed by DITA" but that cannot be strictly 
conforming to the DITA topic structures.

This is partly a side effect of the rule of complete specialization 
(every type in the concrete DTD must be specialized from a type in the 
general module) and partly a reflection of the fact that DITA 1.3 
doesn't allow for containers in a number of places where they would 
often be expected.

I have not brought this up before now because in the OASIS DITA 1.0 
effort it is almost certainly not reasonable or practical to do the 
level of content model refinement that would be required to insert 
optional containers everywhere they are needed.

So I am just observing a fact about DITA as it is defined today and not 
in any way suggesting that we try to address this in OASIS DITA 1.0.

This is also one reason why I think it's very important to separate out 
the specialization mechanism from the DITA element types: even when you 
can't use the DITA topic types directly you can still get immense value 
from both the specialization mechanism and the basic modularity 
functionality and practices demonstrated by the DITA element types. And 
when, like this client, you have no particular interchange requirement, 
there is no real cost to *not* having strict conformance to the DITA 
types because most of the value is in the shape of the DITA design, not 
the details of element types.

As a rule, I would expect anybody trying to retrofit an existing 
non-trivial technical documentation document type to DITA to run into 
this same issue.

Cheers,

E.
-- 
W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(512) 372-8122

eliot@innodata-isogen.com
www.innodata-isogen.com