OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita-busdocs message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]