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
www.innodata-isogen.com
