Re: [dita] containment (was: Containers for steps and other elements!?)

[Erik Hennum <ehennum@us.ibm.com>]

Hi, Eliot and Committee Members:

As part of the bookmark for discussing the containment issue after DITA 1.0, I'd like to include the persective in

http://www.oasis-open.org/archives/dita/200408/msg00098.html

In particular, the points about the important benefits

* Of a topic architecture for enabling reuse of content through granular designs (keeping internal topic structure relatively flat, keeping topics relatively small, and using topic nesting for containment).

* Of a shared base not only for content interchange but for shared designs and tooling.

That's not to disagree that the specialization architecture should be usable in problem spaces where content can't be modeled as a topic architecture. I'd encourage comment on this first pass at distinguishing the specialization architecture from the topic type architecture:

http://www.oasis-open.org/archives/dita/200408/msg00097.html

I would suggest that the design question of whether the content could be modeled with a topic architecture should come before the practical constraints that limit adoption of a topic architecture (for instance, the inability to move off an existing vocabulary). It's important to recognize compromises for what they are.

While advocating that DITA retain topic architecture in its core mandate, I'd agree that one of the really interesting questions to look at after DITA 1.0 will be the ways in which specialization can be enhanced to give the designer more flexibility while retaining the core benefits of reuse and shared designs and tooling.


Hoping that's interesting,


Erik Hennum
ehennum@us.ibm.com


"W. Eliot Kimber" <ekimber@innodata-isogen.com> wrote on 09/23/2004 01:27:55 PM:

> 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