Coordination With/Participation by DITA For Publishers

[Eliot Kimber <ekimber@reallysi.com>]

All,

As you should have seen in my mail to the DITA TC and/or dita-users, I've
started a new SourceForge project to capture DITA components specific to the
needs of Publishers.

Many of the things that Publishers need are also relevant to business
documents as defined by the this SC. Given that, it's important that
anything I and the DITA for Publishers project produces be coordinated with
the work of the Business Documents SC to ensure we're not duplicating effort
or failing to define common underpinnings where we need distinct
specializations.

To that end I have joined this SC as a member and will do my best to
participate and attend meetings and contribute constructively.

Certainly the requirement for aggregated editing is shared. To date I've
addressed it by defining shell topic types that allow literal nesting of
topics as required. This is easy for me, as an implementor, to do, but as
has been discussed in the past, whether this can be a general solution
remains to be seen. Certainly a general solution that did not require either
something like database or otherwise hacking of DTDs just so editors can
work would be nice.

For background: over the last two years I've done projects or pre-sales
analysis involving all of these types of documents:

- Standards and regulations (the FASB's Codified GAAP content).

- Reports produced by a U.S. Govt. federal agency, where the report content
is either largely generic or very specialized, such as meeting minutes
requiring detailed paragraph- and phrase-level specializations.

- Test preparation manuals that combine generic content, true conceptual
content, and assessments (for which I used the Learning and Training
module).

- Trade books (novels, non-fiction, etc.).

- Travel and nature guides.

- Magazines, including highly-designed magazines, journals, and daily
newsletters.

Out of these experiences I've come to a few conclusions:

1. The bookmap map type is simply too limited and too constraining to be
useful for publishers. In particular, it lacks essential metadata and,
because of how it was implemented, provides no good mechanism for extension,
and it imposes too many constraints on the structural content of the
publication and lacks some structures I would consider essential in any
publication map design, such as a wrapper around all body topicrefs.

2. Any narrative document can be usefully and productively represented using
nested topics. For this I've developed two simple topic types, "subsection"
and "sidebar", that, along with "chapter" and "article", provide the basic
pieces needed to represent generically almost any publication or major
publication component. With appropriately-configured shell DTDs, these allow
the representation of even entire publications as a single-file document
with a single root topic (as opposed to a <dita> document).

3. Forget about <section>. Is is a snare and delusion, except for the
limited case of reference-type content (that is, sections with invariant
titles and invariant ordering within the topic body). If it has a variable
title and isn't a figure or a table it *must* be a topic. Any other path
leads to madness.

Through the DITA for Publishers project on SourceForge I have been allowed
to release the above-mentioned topic types to the community and I likewise
offer them to this SC as at least a model for what I think would be the
appropriate sorts of topic types for business documents.

I have also started working on a "publication map" design for use in place
of bookmap. This is intended specifically for Publishers (for example, it
provides for things you see in trade books that would probably be
inappropriate in more controlled business documents) but it seems likely
that there is a common base from which a pubmap and a business document map
could both derive, since the line between a business document and
publication is often pretty blurry.

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>