Re: [dita] Groups - The Case for Aggregated Editing (The Case forAggregated Editing.doc) uploaded

[Eliot Kimber <ekimber@reallysi.com>]

In discussing this issue I think I've come to the realization that the
problem is not with any lack in the DITA specification or the DITA
mechanics.

The problem is simply this:

1. The use of DITA in the way envisioned by the Business Documents SC (and
by my Publishing clients) requires different configurations of nestable
topics than is provided by any of the out-of-the-box shells. This represents
a fundamentally different use pattern than that of most tech doc groups, who
focus on modularity and re-use. Nevertheless it is a perfectly valid DITA
use pattern and one that represents the quite possibly the largest potential
use pattern, given that the volume of business documents and Publishing-type
documents is orders of magnitude greater than the volume of technical
documents will ever be.

2. The syntactic mechanics of defining new configurations, while *as easy as
it could possibly be* in the context of DTD and XSD schema syntax, is still
beyond the reasonable capabilities of anyone who isn't an XML and DITA
specialist (or at least willing and able to work through my Specialization
Tutorial, which is still essentially everyone).

3. In the absence of a way to *easily* create local shells and, possibly,
local custom configurations, the use of DITA in any form for this
non-modular use pattern except via ditabase is simply unrealistic to expect
for any user community that is not at least large enough to have either a
dedicated tools person or budget to hire a consultant.

Note that the *practical* need to have local shells, even if they are merely
unmodified copies of the TC-provided shells, is simply a fact that stems
from the way XML works: if you change the configuration of a topic type's
shell it's a new shell and has to have a new name and that name is part of
the content of *every topic* of that type. This is coupled with the fact
that *you will want to change your configuration sooner or later*, if only
to remove those things you don't need from the default configuration.

My assertion that best practice is to create local shells as the *first act*
of production use of DITA is simply the logical implication of the fact
given above: Eat the cost as early as possible in order to avoid much
greater cost later. It's like changing the default password on your home
router (or DOT road signs).

But for Business Documents in particular, there is a larger problem: simple
copies of the base shells won't work because the default shells only allow
same-topic-type nesting. Using ditabase is at best unsatisfying because it
allows *all topic types* to nest.

Clearly Business Document creators need default shells (and specialized
topic types) that represent a reasonable balance between constraint and
flexibility but in any case allow a reasonable combination of topic types to
nest (e.g., reference and task topics within concept topics along with
probably some sort of generic "subsection" topic that avoids the whole
concept/task/reference distinction but is still a bit more constrained than
<topic>).

In addition, even if the Business Documents SC provides such shells, savy
(but not necessarily technical) users will quickly realize the value in
further customization or specialization but will then get frustrated when
they realize it requires a degree of minute technical knowledge they don't
want to have (and don't think they need to have with other tools, like
Word).

At this point, an otherwise enthusiastic adopter becomes frustrated and
disenchanted and decides Word is good enough.

Given that analysis and reality (and I do think that the problem as stated
in the subject document and as I've restated here is a real problem that
needs to be taken seriously), then I think that the solution is relatively
simple:

Provide a tool or tools that hide the syntactic and mechanical complexity of
creating new shells with new configurations.

Such a tool should be completely possible for the very reason that the DITA
standard explicitly constrains the syntactic mechanisms for creating and
structuring shells.

It is a 100% mechanical process that could be 100% automated such that a
user, any user, can be given a UI that presents a set of available topic
types and provides a visual mechanism for organizing them into a tree of
allowed types, prompts for appropriate shell names and identifiers, and so
on. (Such a UI could also produce map specializations that reflect the same
constraints but in terms of specialized topicref elements.)

Given such a tool implemented well, then it should not be any more difficult
to define a local shell with the configuration you want than it is to create
a new Word template.

And through the magic of DITA, all such topics would still be completely
interchangeable because DITA doesn't actually care about DTDs, only topic
types and modules.

The question then becomes: who will implement this tool?

Without such a tool, the only options become:

- Use the out-of-the-box shells, accepting the attendant problems of
overgenerality and the need for future change to local shells. Even Business
Document SC-provided shells will only be partially satisfying.

- Limit the use of DITA to groups that can afford to create and manage their
local configurations.

Cheers,

Eliot

----
Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
email:  ekimber@reallysi.com <mailto:ekimber@reallysi.com>
office: 610.631.6770 | cell: 512.554.9368
2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403
www.reallysi.com <http://www.reallysi.com>  | http://blog.reallysi.com
<http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com>