[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: DITA 1.2 packages
Here is some initial thinking about how we should package the DITA 1.2 specifications, DTDs, schemas, and related files.
We’d like to discuss this during an upcoming DITA TC call. And, as always, comments and suggestions by e-mail to the list or directly to me (jogden@ptc.com), Robert (robander@us.ibm.com), and Michael (mpriestlo@ca.ibm.com) are welcome.
The items below are numbered just to make it easier to refer to specific items in discussions and via e-mail.
General comments:
1) Core Package
a)
DITA 1.2 Core Architectural Specification
(introduction, topic, map, and b) DITA 1.2 Core Language Reference (map, topic, metadata, map group domain). c)
DITA 1.2 Utility Domain Specializations Architecture
and Language Reference (utilities, d) DITA 1.2 Processing Guidelines and Examples (non-normative).
e) Basic Topic document type shell (topic type, no domains). f) Topic type modules. g)
Topic domain specialization modules for the indexing,
utilities, h) Basic Map document type shell (only map type plus the map group domain). i) Map modules. j) Map Group domain specialization modules. k) Delayed Resolution domain specialization modules. l) xNAL domain specialization modules. m) Basic Ditabase document type shell (topic type, no domains). n) ditaval document type.
2) Technical Content Package
a) DITA 1.2
Technical Content Specializations Architecture and Language b) DITA 1.2
Software Specializations Architecture and Language
c) Topic
document type shell (topic plus core topic domains plus the d) Concept
document type shell (concept plus core topic domains plus e) Glossary
document type shell (glossentry plus core topic domains plus f)
Reference document type shell (reference plus core topic domains plus g) Task
document type shell (constrained task plus core topic domains plus the h) Concept, glossary, reference, and task specialization modules. i) Software, programming, and UI domain specialization modules. j) Map document type shell (map plus map group, and indexing domains). k) Technical
Content Ditabase doctype shell (topic, concept, glossentry,
3) Book Specializations Package
a) DITA 1.2 Book Specialization Architecture and Language Reference (bookmap).
b) Bookmap
document type shell (bookmap plus map group, indexing, c) Bookmap specialization modules.
4) Learning and Training Content Specializations Package
a) DITA 1.2 Learning and Training Content Specializations Architecture and Language Reference.
b) Doctype
shells for all of the Learning and Training topic specializations except
learningBase, c) Learning and Training topic and metadata domains. d) Learning and
Training map doctype shell (map plus the Learning Map and e) Learning and Training map domain specialization. f)
Learning and Training Ditabase doctype shell (all of the Learning and
Training topics,
5) Machine Industry Specializations Package
a) DITA 1.2 Machine Industry Specializations Architecture and Language Reference.
b) Machine
Industry Task doctype shell (task plus the core topic and c) Machine Industry domain specialization modules. d) Machine
Industry Ditabase doctype shell (topic, concept, reference, Machine Industry
Task,
6) Semantic Linking, Controlled Values, and Taxonomies
a)
DITA 1.2 Semantic Linking, Controlled Values, and
Taxonomies Specializations
b) Subject Schema Map document type shell. c) Subject Schema Map modules. d) Classification Map document type shell. e) Classification domain specialization modules.
7) Combined Package
a) All of the above in one combined package.
Questions:
I. Should the Learning and Training topics and ditabase doctype shells include the software, ui, and programming domains? John?
II. Do we want a Learning and Training map doctype shell that is based on bookmap? John?
III. Is it nuts to include so many variations of Ditabase doctype shells? Do we want a ditabase in each package? Should we leave this up to the sub-committees?
IV. Should we include the approved Best Practice documents as an informative part of the core package? Should we combine the existing best practice documents into a single document?
V. Which map document type shells should include the Delayed Resolution domain? Basic map? Technical Content Map? Bookmap? Leaning Map?
VI. We have a constrained task doctype shell as part of the Technical Content Package. Do we need to include an unconstrained task? If so, in which package? Or is the Machine Industry Task an unconstrained task that can serve this role?
VII. Notice that the Delayed Resolution domain is included in the core package, that it is not included in any doctype shells. Is this OK?
VIII. Notice that the xNAL domain is included in the core package, but it is only included in the Bookmap doctype shell.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]