[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Containers for steps and other elements!?
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]