[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: results from recent DITA 1.2 terminology discussions
An
ad hoc group met by conference call this past Thursday to talk about the terminology
that we should be using in the DITA 1.2 specification. There was a good
deal of follow-up by e-mail after the call as well. On the call where Eliot, Bruce,
Michael, Robert, Joann, Stan, and me. Gershon and Kris participated or were
copied on the follow-up e-mail conversation. We
came to several conclusions that are summarized below. There is some continuing
discussion via e-mail to pin down the wording on one or two definitions. We
think that all of this is largely editorial guidance for the writers. And
while comments are certainly welcome, we don’t think there is a need for
formal review or approval by the DITA TC beyond what will take place as part of
the next review of the draft specification. Other
members of the ad hoc terminology group should feel free to add their own
comments or corrections. Summary
of the terminology discussions: 1.
We
will use the term “DITA document type” in place of “Concrete
document type” in the terminology section and throughout the DITA 1.2
spec. 2.
We
will use the term “DITA Document Type Shell” for both DTD based and
XSD based shells. 3.
We
do not need and should not use the terms “Shell DTD”,
““Head schema”, “Shell XSD”, or “Local
shell”. 4.
In
cases where we need to talk specifically about DTDs or XSDs we can use the
phrases “DTD based DITA Document type shell”, or “XSD based
DITA document type shell”. We won’t include those phrases in the
terminology section of the DITA 1.2 spec. 5.
The
following terms will be removed from the terminology list, but can be used
elsewhere in the DITA 1.2 specification: a. Attribute type b. Attribute instance c. Document type module d. Element type e. Element instance f. Information Architect g. Integration 6.
There
is some continuing discussion about the exact wording for some of the
definitions. The current versions are included below. In several cases where
details, notes, and asides have been removed from the definitions, the details
will be included in other sections of the specification. Definitions not
listed below are unchanged, although the writers are free to update the
definitions as part of their ongoing work. DITA
document An
XML document that conforms to the requirements of this specification. A DITA
document must have as its root element either <map> or a specialization
of <map>, <topic> or a specialization of topic, or <dita>.
The <dita> element cannot be specialized itself, but allows documents
with multiple sibling topics. With
the following information included elsewhere in the DITA 1.2 specification
rather that as part of the definition: All DITA documents include the
@DITAArchVersion attribute in the namespace http://dita.oasis-open.org/architecture/2005/
on their root elements. Typically, the @DITAArchVersion attribute is declared
with a default attribute value in the DTD or schema rather than directly in the
document instance. The @DITAArchVersion attribute should not be modified by
authors. DITA
document type A unique set of structural, domain, and
constraint modules that taken together provide the XML element and attribute
declarations that define the structure of DITA documents. DITA document types
are normally implemented using DITA document type shells. DITA
document type shell A set of DTD or XSD declarations that
implement a DITA document type using the rules and design patterns
included in the DITA specification. A DITA document type shell includes and
configures one or more structural modules, zero or more domain
modules, and zero or more constraint modules. With the exception of
the optional declarations for the <dita> element and its attributes, DITA
document type shells do not declare any element or attributes types
directly. Extension
element Within a vocabulary module, an element
type that can be extended, replaced, or constrained for use in a DITA
document type Topic
module A structural module that defines a
single top-level topic type Restricted
content model For a DITA element type, a content
model that has been restricted from that element type's base content model
by the removal of optional elements, by the requiring of optional elements, by
ordering unordered elements, or by limiting the repeatability of repeatable
(but optional) elements. Content models may be restricted through the use of constraint
modules or through specialization. Generalization
(not
yet settled) Alternative #1 A process by which a specialized element
is transformed into one of its less specialized ancestor element types or a specialized
attribute is transformed into a less specialized ancestor attribute. Alternative #2 A process by which a specialized element
is transformed into one of its less specialized ancestor element types or a specialized
attribute is transformed into a less specialized ancestor attribute. The
original specialization hierarchy information may be preserved using the @class
attribute allowing the original specialized form to be recreated from the
generalized instance. Alternative #3 (this is the definition from
the September 21st draft of the DITA 1.2 spec.): A process by which a specialized element
is transformed into one of its less specialized ancestor element types or a specialized
attribute is transformed into a less specialized ancestor attribute and
where the original specialization hierarchy information is preserved such that
the original specialized form can be recreated from the generalized instance. The
main unsettled question here is if the term “generalization” REQUIRES
or simply ALLOWS the class hierarchy to be preserved. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]