FYI: New Community Project: DITA For Publishers

[Eliot Kimber <ekimber@reallysi.com>]

Below is a copy of an announcement email I sent to the DITA Users mailing
list. I copy it here as a courtesy for TC members who do not also follow
dita-users.

As mentioned below, this project is in anticipation of my intent to
eventually start a Publishing subcommittee within the TC. Such a
subcommittee would be premature at the moment, both because the community of
DITA-using publishers is still pretty small and because I need to continue
to focus on helping to get DITA 1.2 done. Since DITA 1.2 is functionally
frozen, there's little point in doing official work on Publishing-specific
requirements before 1.2 is done. But at the same time, I'm doing project
work that has is producing some obvious generic bits that I don't want to
have to re-invent and that no Publisher should have to pay me to create for
them.

Also, as mentioned below, I intend to start coordinating this project's
activities with the Business Documents subcommittee as there is obvious
overlap and potential synergy there.

Cheers,

Eliot


Original mail:

With the backing of Really Strategies, I have started a new community
project: DITA For Publishers. The project is hosted on sourceforge at
http://dita4publishers.sourceforge.net.

The purpose of this project is to provide generic DITA specializations and
supporting processing and documentation optimized for the needs of
Publishers (books and magazines), as opposed to the needs of Technical
Documentation or Business Documents. At some point I expect to integrate
this activity with the DITA standard, probably through a Publishing
subcommittee of the DITA Technical Committee.

Note that this activity has some natural overlap with the Business Documents
subcommittee, especially around the need to support narrative documents and
provide generic components for more-or-less arbitrary publications. It is
definitely my intent to coordinate with the Business Documents subcommittee
in order to ensure that we are not duplicating effort. For example, the
generic "chapter" and "subsection" topic types I've contributed to this
project are probably directly applicable to business documents.

To get the project started I have posted in the source code repository
initial drafts of the following specializations:

Map types:

- Publication map (pubmap). Provides an alternative to the standard DITA
bookmap map specialization. The pubmap map type is designed to enable
representation of arbitrary book and serial publications. It imposes no
arbitrary constraints but provides for things you'd almost never have in
tech docs, such as topics representing individual pages. It also provides
publishing-specific metadata not available in bookmap, such as both 10- and
13-digit ISNBs and ISSNs, etc. [NOTE: what's there now is pretty rough but
it's a start. In particular, I want there to be a freely-available
alternative to bookmap, which is simply not applicable for non-techdoc
Publications.]

Topic types:

- article topic type. Specialization of <topic> for representing articles.
Intended to be used as the root topic of an article-level unit of authoring,
often authored as a single XML document with nested subtopics (e.g, sidebar
and subsection).

- chapter topic type. Specialization of <topic> for representing chapters
within books. Intended to be used as the root topic of a chapter-level unit
of authoring, often authored as a single XML document with nested subtopics
(e.g., sidebar and subsection).

- sidebar topic type. Specialization of <topic> that represents an
out-of-line unit of titled content.

- subsection topic type. Specialization of topic intended to represent
arbitrarily-nested subdivisions within articles, chapters, and sidebars.

Domain modules:

- Formatting domain. Provides elements that indicate arbitrary formatting
requests, e.g., breaks, tabs, as well as mathematical equations (through
MathMO) and, worse case, embedded desktop publishing data (e.g., InDesign
INX interchange XML).

Intended to enable reasonably accurate representation of arbitrary
formatting, either for legacy publications that must be captured as closely
as possible, or to enable publishing through layout tools like InDesign and
Quark. The embedding of INX markup is intended primarily as a fallback for
handling the typesetting of complex mathematical equations with InDesign.
Also provides a generic <art> element, which allows binding of images to a
descriptive title and classifying metadata. Intended primarily to allow CMS
systems to manage art objects as separate objects without requiring the use
of topics and conref.

- XML domain. Provides mention elements for identifying mentions of XML
constructs. Useful for documents that talk about XML, e.g., documentation
for DITA-based systems.

- Classification domain. Provides a generic <classification> element,
specialized from <data>, that serves as place to plug in specializations of
<data> that reflect specific classification taxonomies.

It will take me a little while to get a proper project Web site and
documentation in place, but if anyone is interested in being a formal
developer member, simply email me with your SourceForge ID and I'll add you
to the project.

There's obviously lots more of this nature that could be added, such as
integrating Dublin Core metadata into topic prologs, additional common
generic topic types for different types of publications, more map
specializations, more complete publication metadata, etc.

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>