[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] DITA 1.2 specification documents
Sounds right. I’d probably add exact document titles and URIs so
there’s no confusion in the “hub” document, and then reference the “hub” in
each of the separate documents (rather than restating the complete list each
time, although I don’t have any problem with redundancy – as long as it
references the “hub” as well J). Mary From: Ogden, Jeff
[mailto:jogden@ptc.com] Mary, The DITA 1.1 Architecture Specification includes the following
statement: The specification consists
of: · The DTDs and schemas that define
DITA markup for the base DITA document types, as well as catalog files. While
the DTDs and schemas should define the same DITA elements, the DTDs are
normative if there is ever any discrepancy. · The language reference that
provides explanations for each element in the base DITA document types · This document, which has
the following parts: – an introduction, which
provides background concepts and an overview of the architecture – the DITA markup
specification, which provides an overview of DITA’s base document types – the DITA processing
specification, which provides descriptions of common DITA processing
expectations – the DITA specialization
specification, which provides details of the mechanisms DITA provides for
defining and extending DITA document types. I expect that the DITA 1.2 specification documents will use the
same approach. Each document will include a statement similar to the one from
DITA 1.1 (but longer since there are more documents). Each DITA 1.2 document
will include the front matter required by OASIS much as was done for the DITA
1.1 Architecture and Language References specs. All of the DITA 1.2 components
(a PDF for each specification document, plus DTD and XSD modules, and catalog
files) will be collected and available for download in a single .zip archive
file. This should allow the entire DITA 1.2 specification to be publicly
reviewed and eventually approved with a single ballot much as was done for DITA
1.1 and DITA 1.0. Does this seem correct to you? -Jeff From: Mary McRae
[mailto:marypmcrae@gmail.com] On Behalf Of Mary McRae Hi Jeff et al, This list looks great – just remember that you’ll either
need to produce a single document called “DITA 1.2” that will then contain the
requisite front matter and listing of each of the separate components (think
intro section to a multi-volume set); or each of these will become a
separately-balloted stand-alone specification/standard. Obviously you can combine *some* of the pieces
into the main DITA 1.2 document and leave others to stand alone as appropriate
as well. I know I’ve brought it up before, but I just don’t want
to see the process delayed once you’re ready to go to public review J All the best, Mary From: Ogden, Jeff [mailto:jogden@ptc.com]
Here is the list of
planned DITA 1.2 specification documents as of the last time we talked about
this. a) DITA 1.2 Base
Architectural Specification (introduction, topic, map, and metadata markup,
processing including delayed resolution, specialization including constraints). b) DITA 1.2 Base
Language Reference (map, topic, metadata including delayed resolution, map
group domain). c) DITA 1.2 Utility
Domain Specializations Architecture and Language Reference (utilities,
highlighting, and hazard statement domains). d) DITA 1.2 xNAL Domain
Specializations Architecture and Language Reference. e) DITA 1.2 Technical
Content Architecture and Language Reference (concept, task, reference,
glossary). f) DITA 1.2 Software,
Programming, and User Interface Domains Specializations Architecture and
Language Reference. g) DITA 1.2 Book Architecture
and Language Reference (bookmap). h) DITA 1.2 Learning and
Training Content Architecture and Language Reference. i) DITA 1.2 Machine
Industry Architecture and Language Reference. j) DITA 1.2 Semantic
Linking, Controlled Values, and Taxonomies Architecture and Language Reference. k) DITA 1.2
Processing Guidelines and Examples (non-normative). Item
(e) might or might not be renamed. Item
(f) might or might not have some doctype shells added. I
would still like to create item (k), but suspect that we should drop it from
the DITA 1.2 work and do it later as a “best practice” or similar document that
is non-normative and outside of the DITA 1.2 Specification. Given
recent discussions it is possible that we may want to combine some of these
items, but exactly how isn’t clear to me at this point. -Jeff |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]