draft outlining the 'specialization guidance' proposal

[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.