dita-busdocs message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: draft outlining the 'specialization guidance' proposal
- From: "Bruce Nevin (bnevin)" <bnevin@cisco.com>
- To: <dita-busdocs@lists.oasis-open.org>
- Date: Wed, 19 May 2010 11:44:23 -0500
[I realized that we haven't put the suggestion into
words. I just threw this together in an hour or so as a rough first cut. Please
hack away at it.]
A Framework for
Extending DITA to Business Documents
The
problem
The use cases with
which DITA was originally conceived and designed were based predominantly upon
technical documentation and user assistance content. DITA is being considered
and adopted much more widely, and the types of content to which it is being
applied are not always a happy fit for <concept>, <task>, and
<reference>, the three specializations of <topic> which are part of
the DITA standard out of the box.
One class of problems
arises because from the author's point of view XML elements and attributes
function as user interface labels. If one of the base types can be made to work,
and the problem is only that many elements and attributes are extraneous,
useless for the given business document type, then methods exist for restricting
what is visible to the user--aside from domain specialization or (in DITA 1.2)
constraints, authoring tools commonly can be configured to hide unwanted
elements. If an element or attribute is inaptly named for the new purpose or
context, a domain specialization is in order. For structural/semantic changes,
however, structural specialization is necessary.
All this is well
understood. Less well recognized are potential consequences for DITA in the long
term if such specializations are carried out independently without any
overarching framework of guidance from the DITA Technical Committee (TC) and the
DITA Adoption Technical Committee (ATC). In particular, if all types that cannot
be specialized properly from one of the base types (<concept>,
<task>, and <reference>) are specialized from <topic>, then
they can only generalize to <topic> for interoperation and content
sharing. Subsets of these new topic types that have important structural and
semantic characteristics in common will not be distinguished, and this will be a
further loss of the potential efficacy and usability of DITA. Worse, as DITA
becomes more widely considered for adoption, this phenomenon of divergent,
independent specializations will contribute to the already too prevalent
perception that the standard is complex and unwieldy.
The proposed
solution
The Business
Documents Subcommittee of the DITA TC (BusDocs) has identified and analyzed a
range of topic types commonly employed in business enterprises and in
government. We have identified subsets of semantically and structurally related
topic types. For each such subset, we have proposed a common ancestor type from
which each member of the subset is specialized. These ancestor types, which are
all specialized from <topic>, are intended only for specialization, they
are not intended to be instantiated with content. We refer to it as an abstract
layer intermediate between <topic> and the various topic types actually
employed by users (which they may of course further specialize if
necessary).
[Illustration or illustrations]
We had some
trepidation about proposing this solution to the DITA TC for the 1.3 or 2.0
release for two reasons: firstly, because it calls for a significant
re-architecting of the standard; and secondly, because the need and demand for
this in the user community and the wider world considering DITA is rather urgent
but the process of revising the specification is necessarily deliberate, if not
glacial, in its utmost haste.
We realized then that
this proposal could be taken up by the DITA ATC as a framework to guide those
who are specializing DITA for BusDocs. It is not unusual for consultants and
adopters to document and share specializations of the base topic types. The DITA
ATC could document the abstract types (specializations of <topic>) and the
proposed basic set of BusDocs specializations in a form that consultants and
adopters could replicate. These would not be part of the standard unless and
until the DITA TC moved to incorporate them in some future release.
A disadvantage is
that the existing base topic types would be 'orphaned' from this scheme. The
recommended specializations from the abstract layer include three simplified
topic types with the same core semantics as the three base topic types. These
new specializations are for BusDocs whereas the base topic types are primarily
for technical documentation and user assistance.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]