[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita-techcomm] Revised proposal for separating Technical Content from the core specificaiton
Hi Bob,
I think this looks better.
I'm afraid I'll be missing the call today, so sending a couple notes in advance:
- For the grammar file section - I don't think we should really even mention RNG, DTD, or Schema. Whatever we do with those will match what the main spec does. Instead, I'd point out that Tech Comm grammar files will be part of this separate deliverable. We should also point out that it has the same dependency issue as the spec content -- how do we bundle the core grammar files, which are required to make the TC grammar files work?
- Overall usability -- I probably wouldn't lead with "it will be diminished". I think the most we can say now is that this is possible -- it might be diminished, but whether that happens and by how much will depend on the eventual delivery mechanism.
Regards, Robert D. Anderson | |
E-mail: robander@us.ibm.com Digital Services Group | |
11501 BURNET RD,, TX, 78758-3400, AUSTIN, USA | |
The technical content specializations will be moved to their own work product when DITA 2.0 is released
Date and version information
Completed
Champion
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
The Technical content specification would be contain the following sections:
Overview
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.
Attribute descriptions would:
Define any attributes that are unique to an element or that have an overloaded meaning that differs from that of its specialization ancestors
List the attribute groups that are used
Problem: information dependencies upon the core specification
The technical content specification depends upon the following information in the core specification:
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
The following would occur:
The rng/technicalContent and dtd/technicalContent grammar files would move to the technical content work product
The OASIS catalog declarations for those grammar files would move with the grammar files
There 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:
The technical content specification must:
Cover everything that is in sections 2.7 and 3.10 in the 1.3 specification.
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]