[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Revised proposal for separating Technical Content from the core specificaiton
DITA 2.0 proposed feature #nn—Technical content work product
The technical content specializations will be moved to their own work product when DITA 2.0 is released
Date and version information
- Completed
- Champion
- Bob Thomas
- Previous versions
- Discussion
Original requirement or use case
Use case: Adding a new information type
Suppose that the DITA TC approves the addition of a new technical content information type for the semantic representation of process information during a time when there is no compelling reason to enhance DITA 2.0. The process information type could be added to the technical content work product without waiting for an update to the core DITA specification. This would allow the DITA to be more responsive to the needs of the technical content community.
Use case: Adding a new element domain
Suppose that the DITA TC approves the addition of a new element domain that models the semantics of documenting web application programming. The same benefits present in the new information type use case also apply here.
Proposed solution: Technical content specification
OverviewThe Technical content specification would be contain the following sections:
Architectural specification. The starting point for this would come from the DITA 1.3 specification, section 2.7 Technical content specialization.
Language specification. The starting point for this would come from the DITA 1.3 specification, section 3.10 Technical content elements.The technical content work product would not include content models. Readers would need to examine the RNG grammar files which are normative.
Define any attributes that are unique to an element or that have an overloaded meaning that differs from that of its specialization ancestorsAttribute descriptions would:
List the attribute groups that are usedProblem: information dependencies upon the core specification
The technical content specification depends upon the following information in the core specification:
These dependencies present a challenge when technical content is delivered as a separate work product, particularly with regard to attribute definitions.
Attributes on the
<step>
element.The following attributes are available on this element: Universal attribute group (with a narrowed definition of
@importance
, given below) and@outputclass
. …Dealing with attribute definitions
Here are some approaches for dealing with references to attribute definitions:
- Cross-publication linking
Implement some sort of cross-publication linking scheme from the technical content document pointing to the appropriate places in the core specification.
- Unlinked references
Mention attribute groups and specific attributes without linking. The reader would be responsible for chasing down the information in the core specification.
- Appendix that contains dependencies
Create an appendix that reuses content from the core specification (section 3.11) to provide link targets for attribute definitions. Links from section 3.11 into the rest of the core specification would have to either be pruned or deactivated.
Proposed solution: Technical content grammar files
The rng/technicalContent and dtd/technicalContent grammar files would move to the technical content work productThe following would occur:
The OASIS catalog declarations for those grammar files would move with the grammar filesThere are no plans to migrate schema/technicalContent or schema-url/technicalContent. Those files would simply be removed from the DITA 2.0 grammar files structure.
Benefits
Moving the technical content specializations into a separate work product has the following benefits:
Technical requirements
Cover everything that is in sections 2.7 and 3.10 in the 1.3 specification.The technical content specification must:
Include all relevant changes introduced by the DITA 2.0 core specification.
Include all DITA 2.0 enhancements from the Technical Communications subcommittee that have been approved by the DITA TC.The DITA Technical Communications subcommittee would be responsible for maintaining and revision the technical content work product given that all changes would be subject to approval by the DITA TC.
Backwards compatibility
There are no backward compatibility issues associated with this proposal.
Costs
Implementing this feature would have the following consequences:
- Processing impact
None.
- Overall usability
Usability would be somewhat diminished because the technical content specification would have to be used in conjunction with the core specification to understand the complete context within which the technical content work product could be used.
- Vendors of tools
Tools that include grammar files would need to include an package
- DITA community-at-large
Information architects would need to be aware that technical content has moved into its own work product.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]