forked from dita-ot/docs
-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathDITA-rm.xml
428 lines (418 loc) · 35.8 KB
/
DITA-rm.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
<?xml version='1.0' encoding='utf-8'?>
<!-- This file is part of the DITA Open Toolkit project hosted on
Sourceforge.net. See the accompanying license.txt file for
applicable licenses.-->
<!-- (c) Copyright IBM Corp. 2004, 2005 All Rights Reserved. -->
<!DOCTYPE topic PUBLIC "-//OASIS//DTD DITA Topic//EN" "topic.dtd">
<topic id="ditarmpublic" xml:lang="en-us">
<title> Introduction to the Darwin Information Typing Architecture</title>
<titlealts>
<searchtitle>Pathway to the future</searchtitle>
</titlealts>
<shortdesc>This document is a roadmap for the Darwin Information Typing Architecture: what it is and how it applies to technical documentation. It is also a product of the architecture, having been written entirely in XML and produced using the principles described here... </shortdesc>
<prolog>
<!--
<credits>Gretchen Hargis and Leigh Davidson for editing</credits>--> <author>Don R. Day</author>
<!--<author><name>Don R. Day</name> <affil>IBM Corporation</affil>
<address>11400 Burnet Rd.
Austin TX 78758</address>
<email>[email protected]</email><bio>Besides his main work as husband,
father, and cat lover, Don designs and supports publishing tools for IBM's
Information Development community and has represented IBM on the W3C XSL and
CSS Working Groups. He has B.A.s in English and Journalism and an M.A. in
Technical and Professional Communication from New Mexico State University.
</bio>
</author>--> <author>Michael Priestley</author>
<!--
<author><name>Michael Priestley</name><affil>IBM Corporation</affil>
<address>Toronto, Canada</address>
<email>[email protected]</email><bio>Michael Priestley is an
information developer for the IBM Toronto Software Development Laboratory. He
has written numerous papers on subjects such as hypertext navigation,
singlesourcing, and interfaces to dynamic documents. He is currently working on
XML and XSL for help and documentation management.</bio>
</author>--> <author>Dave A Schell</author>
<!--<author><name>Dave A. Schell</name><affil>IBM Corporation</affil>
<address>Raleigh, North Carolina</address>
<email>[email protected]</email><bio>Dave is IBM's chief strategist
and tools lead in support of its technical writing (User Technology)
community.</bio>
</author>
--> <critdates>
<created date="23 February 2001"/>
</critdates>
<metadata>
<keywords>
<keyword>Darwin Information Typing Architecture</keyword>
<keyword>DITA</keyword>
<keyword>XML</keyword>
<keyword>topic</keyword>
<keyword>information architecture</keyword>
<keyword>architectural forms</keyword>
<keyword>specialization</keyword>
<keyword>information type</keyword>
<keyword>document metadata</keyword>
<keyword>documentation</keyword>
<keyword> technical writing</keyword>
<keyword>user assistance</keyword>
<keyword>helps</keyword>
</keywords>
</metadata>
<!--points: usability, reusability, extensibility, and consistency--> </prolog>
<topic id="ditarmintro">
<title>Executive summary</title>
<body>
<p>The <keyword id="ditalogo">Darwin Information Typing Architecture</keyword> (DITA) is an XML-based, end-to-end architecture for authoring, producing, and delivering technical information. This architecture consists of a set of design principles for creating "information-typed" modules at a topic level and for using that content in delivery modes such as online help and product support portals on the Web.</p>
<p>At the heart of DITA (<keyword conref="#ditarmintro/ditalogo"/>), representing the generic building block of a topic-oriented information architecture, is an XML document type definition (DTD) called "the topic DTD." The extensible architecture, however, is the defining part of this design for technical information; the topic DTD, or any schema based on it, is just an instantiation of the design principles of the architecture.</p>
<section id="background">
<title>Background</title>
<p>This architecture and DTD were designed by a cross-company workgroup representing user assistance teams from across IBM. After an initial investigation in late 1999, the workgroup developed the architecture collaboratively during 2000 through postings to a database and weekly teleconferences. The architecture has been placed on IBM's developerWorks Web site as an alternative XML-based documentation system, designed to exploit XML as its encoding format. With the delivery of these signficant updates contains enhancements for consistency and flexibility, we consider the DITA design to be past its prototype stage.</p>
</section>
<section id="infoconcerns">
<title>Information interchange, tools management, and extensibility</title>
<p>IBM, with millions of pages of documentation for its products, has its own very complex SGML DTD, IBMIDDoc, which has supported this documentation since the early 1990s. The workgroup had to consider from the outset, "Why not just convert IBMIDDoc or use an existing XML DTD such as DocBook, or TEI, or XHTML?" The answer requires some reflection about the nature of technical information. </p>
<p>First, both SGML and XML are recognized as meta languages that allow communities of data owners to describe their information assets in ways that reflect how they develop, store, and process that information. Because knowledge representation is so strongly related to corporate cultures and community jargon, most attempts to define a <b>
<i>universal DTD</i>
</b> have ended up either unused or unfinished. The <b>
<i>ideal for information interchange</i>
</b> is to share the semantics and the transformational rules for this information with other data-owning communities.</p>
<p>Second, most companies rely on many delivery systems, or process their information in ways that differ widely from company to company. Therefore any attempt at a <b>
<i>universal tool set</i>
</b> also proves futile. The <b>
<i>ideal for tools management</i>
</b> is to base a processing architecture on standards, to leverage the contributed experience of many others, and to solve common problems in a broad community.</p>
<p>Third, most attempts to formalize a document description vocabulary (DTD or schema) have been done as information modelling exercises to capture the <b>
<i>current business practices</i>
</b> of data owners. This approach tends to encode <i>legacy</i> practices into the resulting DTDs or vocabularies. The <b>
<i>ideal for future extensibility</i>
</b> in DTDs for technical information (or any information that is continually exploited at the leading edge of technology) is to build the fewest presumptions about the "top-down" processing system into the design of the DTD.</p>
<p>In the beginning, the workgroup tried to understand the role of XML in this leading edge of information technology. As the work progressed, the team became aware that any DTD design effort would have to account for a plurality of vocabularies, a tools-agnostic processing paradigm, and a legacy-free view of information structures. Many current DTDs incorporate ways to deal with some of these issues, but the breadth of the issues lead to more than just a DTD. To support many products, brands, companies, styles, and delivery methods, the entire authoring-to-delivery process had to be considered. What resulted was a range of recommendations that required us to represent our design, not just as a DTD, but as an information architecture.</p>
</section>
<section id="mainfeaturesofditaarch">
<title>Main features of the DITA architecture</title>
<p>As the "Architecture" part of DITA's name suggests, DITA has unifying features that serve to organize and integrate information:</p>
<ul>
<li><i>Topic orientation.</i> The highest standard structure in DITA is the topic. Any higher structure than a topic is usually part of the processing context for a topic, such as a print-organizing structure or the helpset-like navigation for a set of topics. Also, topics have no internal hierarchical nesting; for internal organization, they rely on sections that define or directly support the topic.</li>
<li><i>Reuse.</i> A principal goal for DITA has been to reduce the practice of copying content from one place to another as a way of reusing content. Reuse within DITA occurs on two levels:<ul>
<li><i>Topic reuse.</i> Because of the non-nesting structure of topics, a topic can be reused in any topic-like context. Information designers know that when they reuse a topic in a new information model, the architecture will process it consistently in its new context.</li>
<li><i>Content reuse.</i> The SGML method of declaring reusable external entities is available for XML users, but this has several practical limitations in XML. DITA instead leans toward a different SGML reuse technique and provides each element with a conref attribute that can point to any other equivalent element in the same or any other topic. This referencing mechanism starts with a base element, thus assuring that a fail-safe structure is always part of the calling topic (the topic that contains the element with the conref attribute). The new content is always functionally equivalent to the element that it replaces.</li>
</ul></li>
<li><i>Specialization.</i> The class mechanism in CSS indicates a common formatting semantic for any element that has a matching class value. In the same way, any DITA element can be extended into a new element whose identifier gets added to the class attribute through its DTD. Therefore, a new element is always associated to its base, or to any element in its specialization sequence.<ul>
<li><i>Topic specialization.</i> Applied to topic structures, specialization is a natural way to extend the generic topic into new information types (or infotypes), which in turn can be extended into more specific instantiations of information structures. For example, a recipe, a material safety data sheet, and an encyclopedia article are all potential derivations from a common reference topic.</li>
<li><i>Domain specialization.</i> Using the same specialization principle, the element vocabulary within a generic topic (or set of infotyped topics) can be extended by introducing elements that reflect a particular information domain served by those topics. For example, a keyword can be extended as a unit of weight in a recipe, as a part name in a hardware reference or as a variable in a programming reference. A specialized domain, such as programming phrases, can be introduced by substitution anywhere that the root elements are allowed. This makes the entire vocabulary available throughout all the infotyped topics used within a discipline. Also, a domain can be replaced within existing infotyped topics, in effect hiding the jargon of one discipline from writers dealing with the content of another. Yet both sets of topics can be appropriate for the same user roles of performing tasks or getting reference information.</li>
</ul></li>
<li><i>Property-based processing.</i> The DITA model provides metadata and attributes that can be used to associate or filter the content of DITA topics with applications such as content management systems, search engines, processing filters, and so on.<ul>
<li><i>Extensive metadata to make topics easier to find.</i> The DITA model for metadata supports the standard categories for the Dublin Core Metadata Initiative. In addition, the DITA metadata enables many different content management approaches to be applied to its content.</li>
<li><i>Universal properties.</i> Most elements in the topic DTD contain a set of universal attributes that enable the elements to be used as selectors, filters, content referencing infrastructure, and multi-language support. In addition, some elements, whose attributes can serve a range of specialized roles, have been analyzed to make sure that their enumerated values provide a rich basis for specialization (which usually constrains values and never adds to them).</li>
</ul></li>
<li><i>Taking advantage of existing tags and tools.</i> Rather than being a radical departure from the familiar, DITA builds on well-accepted sets of tags and can be used with standard XML tools.<ul>
<li><i>Leveraging popular language subsets.</i> The core elements in DITA's topic DTD borrow from HTML and XHTML, using familiar element names like p, ol, ul, dl within an HTML-like topic structure. In fact, DITA topics can be written, like HTML, for rendering directly in a browser. In more ambitious designs, DITA topics can be written, like SGML, to be normalized through processing into a deliverable, say XHTML or a well-formed XML format targeted for a particular browser's ability to handle XML. Also, DITA makes use of the popular OASIS (formerly CALS) table model.</li>
<li><i>Leveraging popular and well-supported tools.</i> The XML processing model is widely supported by a number of vendors. The class-based extension mechanism in DITA translates well to the design features of the XSLT and CSS stylesheet languages defined by the World Wide Web Consortium and supported in many transformation tools, editors and browsers. DITA topics can be processed by a spectrum of tools ranging from shareware to custom tailored products, on almost any operating platform.</li>
</ul></li>
</ul>
</section>
<section id="basictopic">
<title>Topic as the basic architectural unit</title>
<p>The various information architectures for online deliverables all tend to focus on the idea of topics as the main design point for such information. A topic is a unit of information that describes a single task, concept, or reference item. The information category (concept, task, or reference) is its information type (or infotype). A new information type can be introduced by <b>specialization</b> from the structures in the base topic DTD. Typed topics are easily managed within content management systems as reusable, stand-alone units of information. For example, selected topics can be gathered, arranged, and processed within a <b>delivery context</b> to provide a variety of deliverables. These deliverables might be groups of recently updated topics for review, helpsets for building into a user assistance application, or even chapters or sections in a booklet that are printed from user-selected search results or "shopping lists."</p>
</section>
<section id="benefitsofditaarch">
<title>Benefits of the DITA architecture</title>
<p>Through topic granularity and topic type specialization, DITA brings the following benefits of the object-oriented model to information sets: </p>
<ul>
<li><i>Encapsulation.</i> The designer of the topic type only needs to address a specific, manageable problem domain. The author only needs to learn the elements that are specific to the topic type. The implementer of the processing for the topic type only needs to process elements that are special.</li>
<li><i>Polymorphism.</i> Special topic types can be treated as more generic topic types for common processing.</li>
<li><i>Message passing.</i> The class attribute preserves at all times the derivation hierarchy of an element. At any time, a topic may be generalized back to any earlier form, and if the class attributes are preserved, these topics may be re-specialized. One use of this capability would be to allow two separate disciplines to merge data at an earlier common part of the specialization hierarchy, after which they can be transformed into one, the other, or a brand new domain and set of infotyped topics.</li>
</ul>
<p>DITA can be considered object-oriented in that:</p>
<ul>
<li>Data and processors are separated from their environment and can be chunked to provide behaviors similar to object-orientation (such as override transforms that modify or redefine earlier behaviors).</li>
<li>Classification of elements through a sequence of derivations that are progressively more specific, possibly more constrained, and always rigidly tied to a consistent processing or rendering model.</li>
<li>Inheritance of behaviors, to the extent that new elements either fall through to behaviors for ancestors in their derivation hierarchy, or can be mapped to modified processors that extend previous behaviors.</li>
</ul>
<p>With discipline and ingenuity, some of the benefits of topic information sets can be provided through a book DTD. In particular, techniques for chunking can generate topics out of a book DTD. In DITA, the converse approach is possible: a book can be assembled from a set of DITA topics. In both cases, however, the adaptation is secondary to the primary purpose of the DTD. That is, if you are primarily authoring books, it makes the most sense to use a DTD that is designed for books. If you are primarily authoring topics, it makes sense to use a DTD that is designed for topics and can scale to large, processable collections of topics. </p>
</section>
</body>
</topic>
<topic id="ditarmoverview">
<title>DITA overview</title>
<body>
<p>The Darwin Information Typing Architecture defines a set of relationships between the document parts, processors, and communities of users of the information.</p>
<p>The Darwin Information Typing Architecture has the following layers that relate to specific design points expressed in its core DTD, <i>topic</i>.</p>
<fig>
<title>Layers in the Darwin Information Typing Architecture</title>
</fig>
<table>
<tgroup cols="3">
<colspec colnum="1" colname="col1" colwidth="*"/>
<colspec colnum="2" colname="col2" colwidth="*"/>
<colspec colnum="3" colname="col3" colwidth="*"/>
<thead>
<row>
<entry namest="col1" nameend="col3" align="center">Delivery contexts</entry>
</row>
</thead>
<tbody>
<row>
<entry colname="col1" align="center">helpset</entry>
<entry colname="col2" align="center">aggregate printing</entry>
<entry colname="col3" align="center">Web site; information portal</entry>
</row>
</tbody>
</tgroup>
</table>
<table>
<tgroup cols="4">
<colspec colnum="1" colname="col1" colwidth="*"/>
<colspec colnum="2" colname="col2" colwidth="*"/>
<colspec colnum="3" colname="col3" colwidth="*"/>
<colspec colnum="4" colname="col4" colwidth="*"/>
<thead>
<row>
<entry namest="col1" nameend="col4" align="center">Typed topic structures</entry>
</row>
</thead>
<tbody>
<row>
<entry colname="col1" align="center">topic</entry>
<entry colname="col2" align="center">concept</entry>
<entry colname="col3" align="center">task</entry>
<entry colname="col4" align="center">reference</entry>
</row>
</tbody>
</tgroup>
</table>
<table>
<tgroup cols="4">
<colspec colnum="1" colname="col1" colwidth="*"/>
<colspec colnum="2" colname="col2" colwidth="*"/>
<colspec colnum="3" colname="col3" colwidth="*"/>
<colspec colnum="4" colname="col4" colwidth="*"/>
<thead>
<row>
<entry namest="col1" nameend="col4" align="center">Specialized vocabularies (domains) across information types</entry>
</row>
</thead>
<tbody>
<row>
<entry colname="col1">Typed topic:</entry>
<entry colname="col2" align="center">concept</entry>
<entry colname="col3" align="center">task</entry>
<entry colname="col4" align="center">reference</entry>
</row>
<row>
<entry colname="col1">Included domains:</entry>
<entry namest="col2" nameend="col4" align="center">
<lines>highlighting
software
programming
user interface</lines>
</entry>
</row>
</tbody>
</tgroup>
</table>
<table>
<tgroup cols="3">
<colspec colnum="1" colname="col1" colwidth="2.79*"/>
<colspec colnum="2" colname="col2" colwidth="1.00*"/>
<colspec colnum="3" colname="col3" colwidth="1.90*"/>
<thead>
<row>
<entry namest="col1" nameend="col3" align="center">Common structures</entry>
</row>
</thead>
<tbody>
<row>
<entry colname="col1" align="center">metadata</entry>
<entry namest="col2" nameend="col3" align="center">OASIS (CALS) table</entry>
</row>
</tbody>
</tgroup>
</table>
<p>A typed topic, whether concept, task, or reference, is a stand-alone unit of ready-to-be-published information. Above it are any processing applications that may be driven by a superset DTD; below it are the two types of content models that form the basis of all specialized DTDs within the architecture. We will look at each of these layers in more detail.</p>
</body>
</topic>
<topic id="roadmapcontexts">
<title>DITA delivery contexts</title>
<body>
<p>This domain represents the processing layer for topical information. Topics can be processed singly or within a delivery context that relates multiple topics to a defined deliverable. Delivery contexts also include document management systems, authoring units, packages for translation, and more.</p>
<table>
<tgroup cols="3">
<colspec colnum="1" colname="col1" colwidth="*"/>
<colspec colnum="2" colname="col2" colwidth="*"/>
<colspec colnum="3" colname="col3" colwidth="*"/>
<thead>
<row>
<entry namest="col1" nameend="col3" align="center">delivery contexts</entry>
</row>
</thead>
<tbody>
<row>
<entry colname="col1" align="center">helpset</entry>
<entry colname="col2" align="center">aggregate printing</entry>
<entry colname="col3" align="center">Web site; information portal</entry>
</row>
</tbody>
</tgroup>
</table>
</body>
</topic>
<topic id="ditatypedtopics">
<title>DITA typed topic specializations (infotyped topics)</title>
<body>
<p>The typed topics represent the fundamental structuring layer for DITA topic-oriented content. The basis of the architecture is the <i>topic</i> structure, from which the <i>concept</i>, <i>task</i>, and <i>reference</i> structures are specialized. Extensibility to other typed topics is possible by further specialization.</p>
<table>
<tgroup cols="4">
<colspec colnum="1" colname="col1" colwidth="*"/>
<colspec colnum="2" colname="col2" colwidth="*"/>
<colspec colnum="3" colname="col3" colwidth="*"/>
<colspec colnum="4" colname="col4" colwidth="*"/>
<thead>
<row>
<entry namest="col1" nameend="col4" align="center">typed topic structures</entry>
</row>
</thead>
<tbody>
<row>
<entry colname="col1" align="center">topic</entry>
<entry colname="col2" align="center">concept</entry>
<entry colname="col3" align="center">task</entry>
<entry colname="col4" align="center">reference</entry>
</row>
</tbody>
</tgroup>
</table>
<p>The four information types (topic, concept, task, and reference) represent the primary content categories used in the technical documentation community. Moreover, specialized, information types, based on the original four, can be defined as required. </p>
<p>As a notable feature of this architecture, communities can define or extend additional information types that represent their own data. Examples of such content include product support information, programming message descriptions, and GUI definitions. Besides the ability to type topics and define specific content models therein, DITA also provides the ability to extend tag vocabularies that pertain to a domain. Domain specialization takes the place of what had been called "shared structures" in DITA's original design.</p>
</body>
</topic>
<topic id="domainsintro">
<title>DITA vocabulary specialization (domains)</title>
<body>
<p>Commonly, when a set of infotyped topics are used within a domain of knowledge, such as computer software or hardware, a common vocabulary is shared across the infotyped topics. However, the same infotyped topic can be used across domains that have different vocabularies and semantics. For example, a hardware reference topic might refer to diagnostic codes while a software reference topic might refer to error message numbers, with neither domain necessarily needing to expose the other domain's unique vocabulary to its own writers. </p>
<p>Using the same technique as specialization for topics, DITA allows the definition of domains of special vocabulary that can be shared among infotyped topics. Domains can even be elided entirely, to produce typed topics that have only the core elements<fn>In the original design of DITA, all of the shared vocabulary had been made global to all information types by being defined in the topic DTD, which had two undesirable effects: <ul>
<li>new vocabulary could not be added without increasing the size of the core DTD</li>
<li>certain domain-specific vocabulary could not be prohibited for DTDs specialized for a different domain.</li>
</ul></fn>. The vocabulary of a domain can take the form of phrases, special paragraphs, and lists--basically anything allowed within a section, the smallest organizing part of a topic.</p>
<table>
<tgroup cols="4">
<colspec colnum="1" colname="col1" colwidth="*"/>
<colspec colnum="2" colname="col2" colwidth="*"/>
<colspec colnum="3" colname="col3" colwidth="*"/>
<colspec colnum="4" colname="col4" colwidth="*"/>
<thead>
<row>
<entry namest="col1" nameend="col4" align="center">specialized vocabularies (domains) across information types</entry>
</row>
</thead>
<tbody>
<row>
<entry colname="col1">
<b>Typed topic:</b>
</entry>
<entry colname="col2" align="center">concept</entry>
<entry colname="col3" align="center">task</entry>
<entry colname="col4" align="center">reference</entry>
</row>
<row>
<entry colname="col1">
<b>Included domains:</b>
</entry>
<entry namest="col2" nameend="col4" align="center">
<lines>highlighting
software
programming
user interface</lines>
</entry>
</row>
</tbody>
</tgroup>
</table>
<p>The basic domains defined as examples for DITA include:</p>
<simpletable keycol="1">
<sthead>
<stentry>Domain</stentry>
<stentry>Elements</stentry>
</sthead>
<strow>
<stentry>highlighting</stentry>
<stentry>b, u, i, tt, sup, sub</stentry>
</strow>
<strow>
<stentry>software</stentry>
<stentry>msgph, msgblock, msgnum, cmdname, varname, filepath, userinput, systemoutput </stentry>
</strow>
<strow>
<stentry>programming</stentry>
<stentry>codeph, codeblock, option, var, parmname, synph, oper, delim, sep, apiname, parml, plentry, pt, pd, syntaxdiagram, synblk, groupseq, groupchoice, groupcomp, fragment, fragref, synnote, synnoteref, repsep, kwd </stentry>
</strow>
<strow>
<stentry>user interface</stentry>
<stentry>uicontrol, wintitle, menucascade, shortcut</stentry>
</strow>
</simpletable>
<p>By following the rules for specializing a new domain of content, you can extend, replace, or remove these domains. Moreover, content specialization enables you to name and extend <i>any</i> content element in the scope of DITA infotyped topics for a more semantically significant role in a new domain.</p>
<p>To enable specialized vocabulary, you declare a parameter entity equivalent for every element used in a DTD (such as topic or one of its specializations), and then use the parameter entities instead of literal element tokens within the content models of that DTD. Later, after entity substitution, because an element's parameter entity is redefined to include both the original element and the domain elements derived from that element, anywhere the original element is allowed, the other derived domain elements are also allowed. In effect, a domain-agnostic topic can be easily extended for different domains by simply changing the scope of entity set inclusions in a front-end DTD "shell" that formalizes the vocabulary extensions within that typed topic or family of typed topics</p>
</body>
</topic>
<topic id="ditacommon">
<title>DITA common structures</title>
<body>
<p>One of the design points of DITA has been to exploit the reuse of common substructures within the world of XML. Accordingly, the topic DTD incorporates the OASIS table model (known originally as the CALS table model). It also has a defined set of metadata that might be shared directly with the metadata models of quite different DTDs or schemas.</p>
<table>
<tgroup cols="3">
<colspec colnum="1" colname="col1" colwidth="2.79*"/>
<colspec colnum="2" colname="col2" colwidth="1.00*"/>
<colspec colnum="3" colname="col3" colwidth="1.90*"/>
<thead>
<row>
<entry namest="col1" nameend="col3" align="center">common structures</entry>
</row>
</thead>
<tbody>
<row>
<entry colname="col1" align="center">metadata</entry>
<entry namest="col2" nameend="col3" align="center">OASIS (CALS) table</entry>
</row>
</tbody>
</tgroup>
</table>
<p>The metadata structure defines document control information for individual topics, higher-level processing DTDs, or HTML documents that are associated to the metadata as side files or as database records.</p>
<p> The table structure provides presentational semantics for body-level content. The OASIS/CALS table display model is supported in many popular XML editors.</p>
</body>
</topic>
<topic id="ditashared">
<title>Elements designed for specialization</title>
<body>
<p>DITA provides a rich base for specialization because of the general design of elements used in its archetype-like topic DTD.</p>
<p>For example, a section in the base topic DTD can contain both text and element data. However, a section can be specialized to eliminate PCDATA, yielding an element-only content model similar to the body level of most DTDs. Specialized another way, a section can eliminate most block-like elements and thus be characterized as a description for definitions, field labels, parts, and so forth.</p>
<p>In DITA, an effort has been made to select element names that are popular or that are common with HTML. Some semantic names have been borrowed from industry DTDs that support large SGML libraries, such as IBMIDDoc and DocBook.</p>
<p>The attribute lists within the topic DTD reflect this design philosophy. For example, one of the "universal attributes" (they appear on most elements) is <codeph>importance</codeph>, which defines values for weightings or appraisals that are often used as properties in specialized elements. This attribute shows up in several elements of the task topic specialization with only two allowed values out of the original set, "optional' and "required." In other domains, the elements are more appropriately ranked as "high" or "low," again values that are provided at the topic level.</p>
</body>
</topic>
<topic id="roadmapspeclz">
<title>The values of specialization</title>
<body>
<p>A company that has specific information needs can define specialized topic types. For example, a product group might identify three main types of reference topic: messages, utilities, and APIs. By creating a specialized topic type for each type of content, the product architect can be assured that each type of topic has the appropriate content. In addition, the specialized topics make XML-aware search more useful because users can make fine-grained distinctions. For example, a user could search for "xyz" only in messages or only in APIs, as well as search for "xyz" across reference topics in general.</p>
<p>There are rules for how to specialize safely: each new information type must map to an existing one and must be more restrictive in the content that it allows. With such specialization, new information types can use generic processing streams for translation, print, and Web publishing. Although a product group can override or extend these processes, they get the full range of existing processes by default without any extra work or maintenance. </p>
<p>A corporation can have a series of DTDs that represent a consistent set of information descriptions, each of which emphasizes the value of specialization for those new information types.</p>
<section>
<title>Role of content communities in the Darwin Information Typing Architecture</title>
<p>The technical documentation community that designed this architecture defined the basic architecture and shared resources. The content owned by specified communities (within or outside of the defining community) can reuse processors, styles, and other features already defined. But, those communities are responsible for their unique business processes based on the data that they manage. They can manage data by creating a further specialization from one of the base types.</p>
<p>The following figure represents how communities, as "content owners at the topic level," can specialize their content based on the core architecture.</p>
<fig>
<title>Relationship of specialized communities to the base architecture</title>
<image href="image/venn1.gif" height="343" width="388"/>
</fig>
<p>In this figure, the overlap represents the common architecture and tools shared between content-owning communities that use this information architecture. New communities that define typed documents according to the architecture can then use the same tools at the outset, and refine their content-specific tools as needed.</p>
</section>
<section>
<title>Notices</title>
<lq>
<p>© Copyright International Business Machines Corp., 2002, 2003. All rights reserved.</p>
<p>The information provided in this document has not been submitted to any formal IBM test and is distributed "AS IS," without warranty of any kind, either express or implied. The use of this information or the implementation of any of these techniques described in this document is the reader's responsibility and depends on the reader's ability to evaluate and integrate them into their operating environment. Readers attempting to adapt these techniques to their own environments do so at their own risk. </p>
</lq>
</section>
</body>
</topic>
</topic>