OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [dita] results from recent DITA 1.2 terminology discussions


Colleagues

 

First, thanks to all involved in preparing the terminology summary.

 

Is there a definition for vocabulary module? It is first mentioned in the definition for extension element.

 

Tony Self

 

 

 

From: Ogden, Jeff [mailto:jogden@ptc.com]
Sent: Tuesday, 17 November 2009 10:39 AM
To: dita
Subject: [dita] 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]