[
Lists Home |
Date Index |
Thread Index
]
So far, I've got a draft for one out of four main subjects for the DITA community wiki specialization area. It reflects feedback from Eric Sirois and JoAnn. Here's a sample for all.
Best wishes,
Bruce
============
Positioning:
The "application of specialization" area needs to discuss primarily the specializations themselves. The influence of those specializations on their users and organizations would be discussed elsewhere, such as the separate areas for best practices and case studies within the DITA community wiki.
The Knowledge area would presumably be the place where the technical details on DITA specialization are provided. It's possible that some of this info should appear there. I tried to keep it as non-technical as possible.
Pending issues:
- Finish three more answers from top-level outline.
- Discuss the internal structure of an information type and how that relates to the internal structure of an element, probably in the Knowledge area.
- This will need a vocabulary cleansing at some point, based on the terms we agreed to in the architectural specification.
============
Initial text for an intro page for the specialization area within the DITA community wiki.
Four main subjects:
- what is specialization (see below)
- what purposes are there for specialization (TBD)
- how does the structure of this area reflect those purposes (TBD)
- how does one add a specialization, or contribute to one (TBD)
===============
What is specialization?
Specialization is an operation that defines new information types and new elements in a disciplined manner. To become a responsible specializer, it is important to develop a very clear understanding of the relationship between information types and elements.
(Segue to a new topic, for the following text.)
The Darwin Information Typing Architecture (DITA) standard provides a variety of XML elements that can be used to mark up information for publication or further processing.
Each element is designed to convey a certain type of information. The information that is conveyed may be contained in the name of the element, the attributes of the element, the content of the element, or some combination of these.
The ability of elements to characterize information has a supporting abstraction: an information type that is implemented by the element. Each information type is defined by a structural or semantic criterion. The information type is the collection of all information that is appropriately described by that criterion.
When we have a particular type of information to convey, we use the corresponding element to mark up that information. An individual instance of an element, with its content, conveys a unit of information that meets the criterion of the information type.
For example, the information type "task" is supported by the DITA element <task>. The <task> element enables users to convey task information. Or, more formally, the markup that is defined for <task> is designed to enable users to convey information that meets the criteria for the information type "task". The criteria for the DITA information type "task" are defined by the DITA architecture, the DITA language reference, and by community norms.
(Return to main topic.)
Specialization is the ability to re-use an existing information type with variations that are clearly derived from the original design. The specialized version of the information type has characteristics that limit the range of applications that it can be used for, but make it better-suited for use within that limited range than the original.
The Darwin Information Typing Architecture (DITA) standard provides systematic support for specialization of information types, in support of an overarching architectural approach: to permit good designs for information to be reused wherever they are applicable.
To implement this idea at the language level, the DITA specialization mechanism makes it possible to define a new element that is a restriction of an existing element. The new element has a different name. It may have fewer attributes, fewer values for particular attributes, a more constrained grammar for the permitted content, or some combination of these.
ES - 'subset' instead of 'less variety' (BE: now "a more constrained
grammar" ... do we check using structural pattern matching?)
The default processing for a specialized element is the same as the processing for the element that it is based on, by a simple fall-back mechanism. If specialized processing is defined that is triggered by particular properties of the specialized element, then that specialized processing overrides the default processing.
The customary way to define a specialization is to provide a specialization module. This is a collection of declarations of new elements. The declarations specify what existing element each new element is based on, and what restrictions are added.
The specialization area of the DITA community wiki provides a place for specializers to post and discuss new specializations. It provides a place for users of specializations to remark upon and inquire about the application of published specializations. As new ideas are proposed by users and specializers, they can be reflected in updates within this area. However, you are asked to keep in mind that implications for the base DITA language and architecture should be brought to the attention of the DITA Technical Committee, and cannot be adjudicated here.
ES - Is there an area in the focus area where users can post
specializations, like APIRef, that are not part of spec but folks can
use
and evolve? I don't recall that being mentioned at the last meeting,
but
it's something that the dita-users group provides at Yahoo. If so It
should probably be a subsection of the specialization section.
BE - yes, I'm assuming that posting specializations and indicating their
purpose and relationships with other specializations is a main purpose
of the
"application of specialization" area.
What are the purposes of specialization?
TBD
How does the structure of this area reflect those purposes?
TBD
How does one add a specialization, or contribute to one?
TBD
===============
Article pointed to by Paul Prescod (2005 Nov 14, 7am):
<http://www-128.ibm.com/developerworks/xml/library/x-dita2/>
Extracted text:
The Darwin Information Typing Architecture is less about document types
than information types. A document is considered to be made up of a
number
of topics, each with its own information type. A topic is, simply, a
chunk
of information consisting of a heading and some text, optionally divided
into sections. The information type describes the content of the topic:
for
example, the type of a given topic might be "concept" or "task."
DITA has three types of topic: a generic topic, or information-typed
concept, task, and reference topics. Concept, task, and reference topics
can all be considered specializations of topic:
Additional information types can be added to the architecture as
specializations of any of these three basic types, or as a peer
specialization directly off of topic -- and any of these additional
specializations can, in turn, be specialized:
Each new information type is defined as an extension of an existing
information type: The specializing type inherits, without duplication,
any
common structures; and the specializing type provides a mapping between
its
new elements and the general type's existing elements. Each information
type is defined in its own DTD module, which defines only the new
elements
for that type. A document that consists of exactly one information type
(for example, a task document in a help web) has a document type defined
by
all the modules in the information type's specialization hierarchy (for
example, task.mod and topic.mod). A document type with multiple
information
types (for example, a book consisting of concepts, tasks, and reference
topics) includes the modules for each of the information types used, as
well as the modules for their ancestors (concept.mod, task.mod,
reference.mod, plus their ancestor topic.mod).
Because information type declarations are separated into modules, you
can
define new information types without affecting ancestor types. This
separation gives you the following benefits:
Reduces maintenance costs: Each authoring group maintains only the
elements
that it uniquely requires
Increases compatibility: The core information types can be centrally
maintained, and changes to the core types are reflected in all
specializing
types
Distributes control: Reusability is controlled by the reuser, instead of
by
the author; adding a new type does not affect the maintenance of the
core
type, and does not affect other users of different types
Any information-typed topic belongs to multiple types. For example, an
API
description is, in more general terms, a reference topic.
Information Architect, Information Products and Training (IP&T)
Lucent Technologies, 67 Whippany Road Room 1A-158, Whippany, NJ, 07981
+1 973 739 1235, esrig@lucent.com
|
