Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
1. Definitions.
"License" shall mean the terms and conditions for use, reproduction,
and distribution as defined by Sections 1 through 9 of this document.
"Licensor" shall mean the copyright owner or entity authorized by
the copyright owner that is granting the License.
"Legal Entity" shall mean the union of the acting entity and all
other entities that control, are controlled by, or are under common
control with that entity. For the purposes of this definition,
"control" means (i) the power, direct or indirect, to cause the
direction or management of such entity, whether by contract or
otherwise, or (ii) ownership of fifty percent (50%) or more of the
outstanding shares, or (iii) beneficial ownership of such entity.
"You" (or "Your") shall mean an individual or Legal Entity
exercising permissions granted by this License.
"Source" form shall mean the preferred form for making modifications,
including but not limited to software source code, documentation
source, and configuration files.
"Object" form shall mean any form resulting from mechanical
transformation or translation of a Source form, including but
not limited to compiled object code, generated documentation,
and conversions to other media types.
"Work" shall mean the work of authorship, whether in Source or
Object form, made available under the License, as indicated by a
copyright notice that is included in or attached to the work
(an example is provided in the Appendix below).
"Derivative Works" shall mean any work, whether in Source or Object
form, that is based on (or derived from) the Work and for which the
editorial revisions, annotations, elaborations, or other modifications
represent, as a whole, an original work of authorship. For the purposes
of this License, Derivative Works shall not include works that remain
separable from, or merely link (or bind by name) to the interfaces of,
the Work and Derivative Works thereof.
"Contribution" shall mean any work of authorship, including
the original version of the Work and any modifications or additions
to that Work or Derivative Works thereof, that is intentionally
submitted to Licensor for inclusion in the Work by the copyright owner
or by an individual or Legal Entity authorized to submit on behalf of
the copyright owner. For the purposes of this definition, "submitted"
means any form of electronic, verbal, or written communication sent
to the Licensor or its representatives, including but not limited to
communication on electronic mailing lists, source code control systems,
and issue tracking systems that are managed by, or on behalf of, the
Licensor for the purpose of discussing and improving the Work, but
excluding communication that is conspicuously marked or otherwise
designated in writing by the copyright owner as "Not a Contribution."
"Contributor" shall mean Licensor and any individual or Legal Entity
on behalf of whom a Contribution has been received by Licensor and
subsequently incorporated within the Work.
2. Grant of Copyright License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
copyright license to reproduce, prepare Derivative Works of,
publicly display, publicly perform, sublicense, and distribute the
Work and such Derivative Works in Source or Object form.
3. Grant of Patent License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
(except as stated in this section) patent license to make, have made,
use, offer to sell, sell, import, and otherwise transfer the Work,
where such license applies only to those patent claims licensable
by such Contributor that are necessarily infringed by their
Contribution(s) alone or by combination of their Contribution(s)
with the Work to which such Contribution(s) was submitted. If You
institute patent litigation against any entity (including a
cross-claim or counterclaim in a lawsuit) alleging that the Work
or a Contribution incorporated within the Work constitutes direct
or contributory patent infringement, then any patent licenses
granted to You under this License for that Work shall terminate
as of the date such litigation is filed.
4. Redistribution. You may reproduce and distribute copies of the
Work or Derivative Works thereof in any medium, with or without
modifications, and in Source or Object form, provided that You
meet the following conditions:
(a) You must give any other recipients of the Work or
Derivative Works a copy of this License; and
(b) You must cause any modified files to carry prominent notices
stating that You changed the files; and
(c) You must retain, in the Source form of any Derivative Works
that You distribute, all copyright, patent, trademark, and
attribution notices from the Source form of the Work,
excluding those notices that do not pertain to any part of
the Derivative Works; and
(d) If the Work includes a "NOTICE" text file as part of its
distribution, then any Derivative Works that You distribute must
include a readable copy of the attribution notices contained
within such NOTICE file, excluding those notices that do not
pertain to any part of the Derivative Works, in at least one
of the following places: within a NOTICE text file distributed
as part of the Derivative Works; within the Source form or
documentation, if provided along with the Derivative Works; or,
within a display generated by the Derivative Works, if and
wherever such third-party notices normally appear. The contents
of the NOTICE file are for informational purposes only and
do not modify the License. You may add Your own attribution
notices within Derivative Works that You distribute, alongside
or as an addendum to the NOTICE text from the Work, provided
that such additional attribution notices cannot be construed
as modifying the License.
You may add Your own copyright statement to Your modifications and
may provide additional or different license terms and conditions
for use, reproduction, or distribution of Your modifications, or
for any such Derivative Works as a whole, provided Your use,
reproduction, and distribution of the Work otherwise complies with
the conditions stated in this License.
5. Submission of Contributions. Unless You explicitly state otherwise,
any Contribution intentionally submitted for inclusion in the Work
by You to the Licensor shall be under the terms and conditions of
this License, without any additional terms or conditions.
Notwithstanding the above, nothing herein shall supersede or modify
the terms of any separate license agreement you may have executed
with Licensor regarding such Contributions.
6. Trademarks. This License does not grant permission to use the trade
names, trademarks, service marks, or product names of the Licensor,
except as required for reasonable and customary use in describing the
origin of the Work and reproducing the content of the NOTICE file.
7. Disclaimer of Warranty. Unless required by applicable law or
agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied, including, without limitation, any warranties or conditions
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
PARTICULAR PURPOSE. You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any
risks associated with Your exercise of permissions under this License.
8. Limitation of Liability. In no event and under no legal theory,
whether in tort (including negligence), contract, or otherwise,
unless required by applicable law (such as deliberate and grossly
negligent acts) or agreed to in writing, shall any Contributor be
liable to You for damages, including any direct, indirect, special,
incidental, or consequential damages of any character arising as a
result of this License or out of the use or inability to use the
Work (including but not limited to damages for loss of goodwill,
work stoppage, computer failure or malfunction, or any and all
other commercial damages or losses), even if such Contributor
has been advised of the possibility of such damages.
9. Accepting Warranty or Additional Liability. While redistributing
the Work or Derivative Works thereof, You may choose to offer,
and charge a fee for, acceptance of support, warranty, indemnity,
or other liability obligations and/or rights consistent with this
License. However, in accepting such obligations, You may act only
on Your own behalf and on Your sole responsibility, not on behalf
of any other Contributor, and only if You agree to indemnify,
defend, and hold each Contributor harmless for any liability
incurred by, or claims asserted against, such Contributor by reason
of your accepting any such warranty or additional liability.
END OF TERMS AND CONDITIONS
APPENDIX: How to apply the Apache License to your work.
To apply the Apache License to your work, attach the following
boilerplate notice, with the fields enclosed by brackets "[]"
replaced with your own identifying information. (Don't include
the brackets!) The text should be enclosed in the appropriate
comment syntax for the file format. We also recommend that a
file or class name and description of purpose be included on the
same "printed page" as the copyright notice for easier
identification within third-party archives.
Copyright [yyyy] [name of copyright owner]
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
dita-ot-1.5.3/CommonPublicLicense-v10.html 0000664 0000000 0000000 00000036034 11671002146 0020251 0 ustar 00root root 0000000 0000000
Common Public License - v 1.0
Common Public License - v 1.0
THE ACCOMPANYING PROGRAM IS PROVIDED UNDER
THE TERMS OF THIS COMMON PUBLIC LICENSE ("AGREEMENT"). ANY USE, REPRODUCTION OR
DISTRIBUTION OF THE PROGRAM CONSTITUTES RECIPIENT'S ACCEPTANCE OF THIS
AGREEMENT.
1. DEFINITIONS
"Contribution" means:
a) in the case of the initial Contributor, the initial code
and documentation distributed under this Agreement, and b) in
the case of each subsequent Contributor:
i) changes to the Program, and
ii) additions to the Program;
where such changes and/or additions to the Program originate
from and are distributed by that particular Contributor. A
Contribution 'originates' from a Contributor if it was added to the Program by
such Contributor itself or anyone acting on such Contributor's behalf.
Contributions do not include additions to the Program
which: (i) are separate modules of software distributed in conjunction with
the Program under their own license agreement, and (ii) are not derivative
works of the Program.
"Contributor" means any person or entity that distributes the
Program.
"Licensed Patents " mean patent claims licensable by a
Contributor which are necessarily infringed by the use or sale of its
Contribution alone or when combined with the Program.
"Program" means the Contributions
distributed in accordance with this Agreement.
"Recipient" means anyone who receives the Program under this
Agreement, including all Contributors.
2. GRANT OF RIGHTS
a) Subject to the
terms of this Agreement, each Contributor hereby grants
Recipient a non-exclusive, worldwide, royalty-free copyright license
to reproduce, prepare
derivative works of, publicly display, publicly perform, distribute and
sublicense the Contribution of such Contributor, if any, and such derivative
works, in source code and object code form.
b) Subject to the terms of this
Agreement, each Contributor hereby grants Recipient a
non-exclusive, worldwide, royalty-free patent license under Licensed Patents to make, use, sell,
offer to sell, import and otherwise transfer the Contribution of such
Contributor, if any, in source code and object code form. This patent license
shall apply to the combination of the Contribution and the Program if, at the
time the Contribution is added by the Contributor, such addition of the
Contribution causes such combination to be covered by the Licensed Patents.
The patent license shall not apply to any other combinations which include the
Contribution. No hardware per se is licensed hereunder.
c) Recipient understands that although each Contributor
grants the licenses to its Contributions set forth herein, no assurances are
provided by any Contributor that the Program does not infringe the patent or
other intellectual property rights of any other entity. Each Contributor
disclaims any liability to Recipient for claims brought by any other entity
based on infringement of intellectual property rights or otherwise. As a
condition to exercising the rights and licenses granted hereunder, each
Recipient hereby assumes sole responsibility to secure any other intellectual
property rights needed, if any. For example, if a third party patent license
is required to allow Recipient to distribute the Program, it is Recipient's
responsibility to acquire that license before distributing the
Program.
d) Each Contributor represents that to its knowledge it has
sufficient copyright rights in its Contribution, if any, to grant the
copyright license set forth in this Agreement.
3. REQUIREMENTS
A Contributor may choose to distribute the Program in
object code form under its own license agreement, provided that:
a) it complies with the terms and conditions of this
Agreement; and
b) its license agreement:
i) effectively disclaims on behalf of all
Contributors all warranties and conditions, express and implied, including
warranties or conditions of title and non-infringement, and implied warranties
or conditions of merchantability and fitness for a particular purpose;
ii) effectively excludes on behalf of all Contributors all
liability for damages, including direct, indirect, special, incidental and
consequential damages, such as lost profits;
iii) states that any provisions which
differ from this Agreement are offered by that Contributor alone and not by
any other party; and
iv) states that source code for the Program is available from
such Contributor, and informs licensees how to obtain it in a reasonable
manner on or through a medium customarily used for software
exchange.
When the Program is made available in source code form:
a) it must be made available under this Agreement; and
b) a copy of this Agreement must be included with each copy
of the Program.
Contributors
may not remove or alter any copyright notices contained within the Program.
Each Contributor must identify itself as the originator of its
Contribution, if any, in a manner that reasonably allows subsequent Recipients
to identify the originator of the Contribution.
4. COMMERCIAL DISTRIBUTION
Commercial distributors of software may accept certain
responsibilities with respect to end users, business partners and the like.
While this license is intended to facilitate the commercial use of the Program,
the Contributor who includes the Program in a commercial product offering should
do so in a manner which does not create potential liability for other
Contributors. Therefore, if a Contributor includes the Program in a commercial
product offering, such Contributor ("Commercial Contributor") hereby agrees to
defend and indemnify every other Contributor ("Indemnified Contributor") against
any losses, damages and costs (collectively "Losses") arising from claims,
lawsuits and other legal actions brought by a third party against the
Indemnified Contributor to the extent caused by the acts or omissions of such
Commercial Contributor in connection with its distribution of the Program in a
commercial product offering. The obligations in this section do not apply to any
claims or Losses relating to any actual or alleged intellectual property
infringement. In order to qualify, an Indemnified Contributor must: a) promptly
notify the Commercial Contributor in writing of such claim, and b) allow the
Commercial Contributor to control, and cooperate with the Commercial Contributor
in, the defense and any related settlement negotiations. The Indemnified
Contributor may participate in any such claim at its own expense.
For example, a Contributor might include the Program in a
commercial product offering, Product X. That Contributor is then a Commercial
Contributor. If that Commercial Contributor then makes performance claims, or
offers warranties related to Product X, those performance claims and warranties
are such Commercial Contributor's responsibility alone. Under this section, the
Commercial Contributor would have to defend claims against the other
Contributors related to those performance claims and warranties, and if a court
requires any other Contributor to pay any damages as a result, the Commercial
Contributor must pay those damages.
5. NO WARRANTY
EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, THE PROGRAM IS
PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,
EITHER EXPRESS OR IMPLIED INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OR
CONDITIONS OF TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. Each Recipient is solely responsible for
determining the appropriateness of using and distributing the Program and assumes all risks associated with its
exercise of rights under this Agreement, including but not
limited to the risks and costs of program errors, compliance with applicable
laws, damage to or loss of data, programs or equipment, and
unavailability or interruption of operations.
6. DISCLAIMER OF LIABILITY
EXCEPT AS EXPRESSLY SET FORTH IN THIS
AGREEMENT, NEITHER RECIPIENT NOR ANY CONTRIBUTORS SHALL HAVE ANY LIABILITY FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
OUT OF THE USE OR DISTRIBUTION OF THE PROGRAM OR THE EXERCISE OF ANY RIGHTS
GRANTED HEREUNDER, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
7. GENERAL
If any provision of this Agreement is
invalid or unenforceable under applicable law, it shall not affect the validity
or enforceability of the remainder of the terms of this Agreement, and without
further action by the parties hereto, such provision shall be reformed to the
minimum extent necessary to make such provision valid and enforceable.
If Recipient institutes patent litigation against a Contributor
with respect to a patent applicable to software (including a cross-claim or
counterclaim in a lawsuit), then any patent licenses granted by that Contributor
to such Recipient under this Agreement shall terminate as of the date such
litigation is filed. In addition, if Recipient institutes patent litigation
against any entity (including a cross-claim or counterclaim in a lawsuit)
alleging that the Program itself (excluding combinations of the Program with
other software or hardware) infringes such Recipient's patent(s), then such
Recipient's rights granted under Section 2(b) shall terminate as of the date
such litigation is filed.
All Recipient's rights under this Agreement shall terminate if
it fails to comply with any of the material terms or conditions of this
Agreement and does not cure such failure in a reasonable period of time after
becoming aware of such noncompliance. If all Recipient's rights under this
Agreement terminate, Recipient agrees to cease use and distribution of the
Program as soon as reasonably practicable. However, Recipient's obligations
under this Agreement and any licenses granted by Recipient relating to the
Program shall continue and survive.
Everyone is permitted to copy and distribute
copies of this Agreement, but in order to avoid inconsistency the Agreement is
copyrighted and may only be modified in the following manner. The Agreement
Steward reserves the right to publish new versions
(including revisions) of this Agreement from time to time.
No one other than the Agreement Steward has the right to modify this Agreement.
IBM is the initial Agreement Steward. IBM may assign the responsibility to serve
as the Agreement Steward to a suitable separate entity. Each
new version of the Agreement will be given a distinguishing version number. The
Program (including Contributions) may always be distributed subject to the
version of the Agreement under which it was received. In addition, after a new
version of the Agreement is published, Contributor may elect to distribute the
Program (including its Contributions) under the new version.
Except as expressly stated in Sections 2(a) and 2(b) above,
Recipient receives no rights or licenses to the intellectual property of any
Contributor under this Agreement, whether expressly, by
implication, estoppel or otherwise. All
rights in the Program not expressly granted under this Agreement are
reserved.
This Agreement is governed by the laws of the State of New York
and the intellectual property laws of the United States of America. No party to
this Agreement will bring a legal action under this Agreement more than one year
after the cause of action arose. Each party waives its rights to a jury trial in
any resulting litigation.
Evaluating the DITA Open Toolkit (Full Easy Install)
The most common scenario for first users of the DITA Open
Toolkit is to evaluate how it functions. Previous versions of the
Toolkit required a number of preliminary installation steps for components
necessary both to run the base function and to show off additional
output capabilities. With DITA-OT 1.4.2, three versions of the Toolkit
are now available: the minimal package (updates core function only),
standard package (minimal plus docs and demos), and a "full easy
install package" that basically installs everything you need
to enable quick and easy evaluation of the Toolkit. This topic deals
with installing and using the full easy install package for the first
time.
Note: This topic explains how to use the Full Easy Install on Windows;
the three versions are also available on all other supported platforms.
For a description of all packages available, see What
packages are available for the DITA Open Toolkit at dita.xml.org.
Unzip or extract the "full_easy_install" zip file to
a convenient directory, such as your c: drive's root directory.
The package will create a directory such as C:\DITA-OT-1.5.1\ that
contains not only the usual Toolkit materials but also all the run-time
components needed to run the Toolkit in a basic evaluation mode.
Browse over to this new directory and double-click on the "startcmd.bat"
file in that directory. A new "command shell" window will
open up, with the environment variables already set to enable the
Toolkit to run within that shell.
At the command prompt (usually c:\DITA-OT1.5.1\ for this version),
type "ant samples.web -f build_demo.xml". After a series
of processing messages, there should be a new \out directory in the
DITA-OT1.5.1\ directory that contains a folder with the resulting
HTML output in it. Congratulations on creating your first example
of DITA output!
Now try the full set of transforms from a single command: "ant
all -f build_demo.xml". This command will process every DITA
example in the Toolkit into each of the supported output types for
the Toolkit. After a much longer flurry of messages, the \out directory
should have a number of folders in it, each with several deliverables
produced by the Toolkit demos. If you happen to have the Microsoft
HTMLHelp Workshop or the JavaHelp toolset installed for other work
you have done with User Assistance, you might even get ready-to use
CHM and JavaHelp output files. By comparing the outputs with the various
source materials in the distribution, you can get an idea about how
the processing works. That explanation is best found in the DITA Open
Toolkit User Guide and at the DITA-OT
Focus Area at http://dita.xml.org .
Demo targets
Here are the individual demo
targets that you can try while evaluating the DITA Open Toolkit. Note
that most are subcomponents of larger operations--you can use any
of these individually.
all Build all output
clean Delete all output
clean.demo Remove the demo output
clean.demo.book Remove the book demo output
clean.demo.elementref Remove the Element Reference demo output
clean.demo.enote Remove the eNote demo output
clean.demo.faq Remove the FAQ demo output
clean.demo.langref-dita1.1 Remove the DITA 1.1 Language Reference demo output
clean.demo.langref-dita1.1.compilehelp Remove the 1.1 Language Reference as CHM output
clean.doc Remove the documentation output
clean.doc.articles Delete the articles directory in doc.
clean.doc.langref-dita1.1 Delete the 1.1 langref directory in doc.
clean.docbook Remove the docbook output
clean.samples Remove the sample output
clean.samples.eclipse Remove the sample Eclipse output
clean.samples.htmlhelp Remove the sample HTMLHelp output
clean.samples.javahelp Remove the sample JavaHelp output
clean.samples.pdf Remove the sample PDF output
clean.samples.web Remove the sample web output
demo Build the demos
demo.book Build the book demo
demo.elementref Build the element reference demo
demo.enote Build the eNote demo
demo.faq Build the FAQ demo
demo.langref-dita1.1.pdf Build the DITA 1.1 Language Reference book as a demo
demo.langref-dita1.1.compilehelp Build the 1.1 Language Reference as HTML Help
doc Build the documentation
doc.articles.chm Build the articles of dita as document.
doc.articles.pdf Build the articles of dita as document.
doc.articles.web Build the articles of dita as document.
doc.langref-dita1.1.chm Build the DITA 1.1 Language Specification document.
doc.langref-dita1.1.pdf Build the DITA 1.1 Language Specification document.
doc.langref-dita1.1.web Build the DITA 1.1 Language Specification document.
docbook Transform the samples to DocBook
prompt Prompt to build anything
samples Build the sample output
samples.eclipse Build the samples for Eclipse
samples.htmlhelp Build the samples for HTMLHelp
samples.javahelp Build the samples for JavaHelp
samples.pdf Build the samples as PDF
samples.troff Build the samples as troff
samples.web Build the samples for the web
If
you do not specify a target for build_demo.xml,
the default target is prompt.
You can also
try your hand at modifying some of the sample scripts in the ant directory.
These represent the kind of driver files that you would create for
your own projects. You can easily adapt these to process your own
test DITA files, for example. Call the other ant samples after this
example:
(This
is basically the same as running ant samples.web -f build_demo.xml,
but intended for you to modify.)
You will find the output for
this exercise in the samples/ant_sample/ directory
itself. You can add parameters to the sample_xhtml.xml file
to change where your outputs end up, and also to modify the build
process in other ways. See the documentation for Ant parameters to
learn more about processing options.
This demonstration provides a proof-of-concept implementation of the DITA bookmap proposal. The proposal adds book output to DITA using a specialized DITA map known as a bookmap. The bookmap organizes the DITA topics with the correct nesting and sequence for the book. In addition, the bookmap assigns roles such as preface, chapter, and appendix to top-level topics within the book.
Note: This demonstration has the following limitations:
For XSL-FO formatting and thus PDF generation, only the basics have been implemented. Through specialization, the DITA XHTML-based outputs for DITA map are also available for bookmap.
The design for the book info component of the proposal has been fleshed out based on antecedents in DocBook and IBMIDDoc (see the comments in the bookinfo.mod file). Most of the elements in bookinfo aren't processed.
This demonstration provides a proof-of-concept implementation of the DITA bookmap proposal. The proposal adds book output to DITA using a specialized DITA map known as a bookmap. The bookmap organizes the DITA topics with the correct nesting and sequence for the book. In addition, the bookmap assigns roles such as preface, chapter, and appendix to top-level topics within the book.
For more detailed information about the proposal, see the detailed posting on the DITA forum at news://news.software.ibm.com:119/c11fd3$85qq$2@news.boulder.ibm.com.
This demonstration has the following limitations:
For XSL-FO formatting and thus PDF generation, only the basics have been implemented. Through specialization, the DITA XHTML-based outputs for DITA map are also available for bookmap.
The design for the book info component of the proposal has been fleshed out based on antecedents in DocBook and IBMIDDoc (see the comments in the bookinfo.mod file). Most of the elements in bookinfo aren't processed.
The book list component of the proposal hasn't been implemented yet. Possible designs for a glossary list have been discussed extensively on the DITA forum (resulting in the proposal posted as news://news.software.ibm.com:119/blfg38$5k0q$1@news.boulder.ibm.com).
The book style component of the proposal is much more experimental than the bookmap and bookinfo components. Processing for this component is limited.
dita-ot-1.5.3/demo/book/bookmap.dtd 0000664 0000000 0000000 00000000762 11671002146 0017067 0 ustar 00root root 0000000 0000000
%map-type;
%bookmap-type;
dita-ot-1.5.3/demo/book/bookmap.mod 0000664 0000000 0000000 00000023665 11671002146 0017102 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/book/bookmap.xsd 0000664 0000000 0000000 00000001620 11671002146 0017104 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/book/bookmap2docbk.xsl 0000664 0000000 0000000 00000003622 11671002146 0020205 0 ustar 00root root 0000000 0000000
<xsl:value-of select="@title"/>
dita-ot-1.5.3/demo/book/bookmap_grp.xsd 0000664 0000000 0000000 00000004655 11671002146 0017767 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/book/bookmap_mod.xsd 0000664 0000000 0000000 00000031177 11671002146 0017755 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/book/bookstyle.dtd 0000664 0000000 0000000 00000004142 11671002146 0017446 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/book/catalog.xml 0000664 0000000 0000000 00000001214 11671002146 0017067 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/book/closeprograms.xml 0000664 0000000 0000000 00000002023 11671002146 0020334 0 ustar 00root root 0000000 0000000
Close all of your programsYou need to shut down everything else before installing major programsClose programsweb serverdatabaseIf you are on a Windows system, click the X in the corner of each
program.If you are on a Linux system, type kill -9 [PID] for each of your
programs. You might want to save your data first.If you are on a Macintosh, you will have to ask someone else. I
have a wonderful little iPod, but that is the limit of my experience with
Apple products.
dita-ot-1.5.3/demo/book/configuredatabase.xml 0000664 0000000 0000000 00000001733 11671002146 0021131 0 ustar 00root root 0000000 0000000
Configuring a DatabaseFollow these instructions to properly configure your database.configuredatabaseIn this instance, the technical writer knows
nothing about his subject.Read the product documentation. It will tell you what options are
available.Read further in the product documentation. It will tell you how
to change these options.Make sure you store the product documentation in an easy-to-find
location when you are done.
dita-ot-1.5.3/demo/book/configurestorage.xml 0000664 0000000 0000000 00000002225 11671002146 0021026 0 ustar 00root root 0000000 0000000
Configuring hard storage devicesMost hard disks do not need any configuring. If they do, the instructions
are relatively simple.hard driveconfigureFirst check the documentation that came with your storage device.
If the device requires configuring, follow the steps below.If your system recognizes the device, it may be able to configure
it without help. If so, do not try and stop it.Otherwise, your drive should come with software. Use this software
to format and partition your drive.Once your drive is configured, restart the system. Just for fun.
But be sure to remove any vendor software from your system before doing so.
dita-ot-1.5.3/demo/book/configurewebserver.xml 0000664 0000000 0000000 00000002120 11671002146 0021360 0 ustar 00root root 0000000 0000000
Configuring your Web ServerConfiguring your Web Server can be as complex or as simple as you
want it to be.web serverconfigureIn this instance, the technical writer knows
nothing about his subject.Turn on the web serverGo to the Options menuFollow that to "Web Server Preferences"Make sure all of the right buttons are checked, or else you will
never get it to workGo to your site library and check out a book; any book, even about
COBOL, is likely to be more helpful than I am.
dita-ot-1.5.3/demo/book/configuring.xml 0000664 0000000 0000000 00000001126 11671002146 0017771 0 ustar 00root root 0000000 0000000
ConfiguringYou configure components to set up or refine your solution.
You don't have to get the best configuration the first time.
Instead, you might start with a simple configuration and then refine
it gradually as needed.
dita-ot-1.5.3/demo/book/databasetrouble.xml 0000664 0000000 0000000 00000001765 11671002146 0020631 0 ustar 00root root 0000000 0000000
Troubleshooting a databaseDatabases rarely have problems, but this may be helpful if you
find some.troubleshootingdatabaseIf performance is slow, try removing several thousand records.If none of your commands work, make sure they are SQL commands
and not SEQUEL commands.If you cannot get anything to work at all, try uninstalling and
reinstalling.For more detailed troubleshooting help, see the online documentation
shipped with your database.
dita-ot-1.5.3/demo/book/drivetrouble.xml 0000664 0000000 0000000 00000002737 11671002146 0020176 0 ustar 00root root 0000000 0000000
Troubleshooting your hard diskFollow these steps to try and fix any problems with your hard drive.troubleshootinghard driveRun scandisk on the drive. This may solve all of your problems.Try defragmenting the drive. This could help with retrieval times.If the drive is still slow, try deleting old or useless information.If the drive cannot access anything, there are some expensive tools
at Best Buy that my help you save some of your information. But, you're probably
out of luck.If the drive makes funny clicking noises, back everything up as
soon as possible.You probably have some important data stored
in bad sectors. This is going to be painful to fix. Make sure you have a copy
of your Operating System CDs.If all else fails, you can always try calling technical support.
However, this can be very expensive, unless you call within 13 hours of your
purchase.
dita-ot-1.5.3/demo/book/insertdrive.xml 0000664 0000000 0000000 00000001721 11671002146 0020016 0 ustar 00root root 0000000 0000000
Attach the drive to the systemThe drive needs to be attached to power cables and other cables
inside the computer.hard driveYou must be grounded before doing this.Find an empty bay for your drive.Remove the drive from its electrostatic bag.Screw the drive in to the frame.Attach the multi-colored power cord to the drive.Attach the cable that connects your hard drive to the motherboard.
dita-ot-1.5.3/demo/book/installdb.xml 0000664 0000000 0000000 00000001105 11671002146 0017430 0 ustar 00root root 0000000 0000000
Installing your own DatabaseInstalling a Database may sound tricky, but it is quite simple
if you follow our instructions.Overviewdatabaseinstall
dita-ot-1.5.3/demo/book/installing.xml 0000664 0000000 0000000 00000001420 11671002146 0017620 0 ustar 00root root 0000000 0000000
InstallingYou install components to make them available for your
solution.
Usually, you can install the components once and then forget about the
details of this task.
Before installing the components, you should make a plan
for what you need to accomplish and the components
that will support these goals.
After installing the components, you will probably want to perform
some preliminary configuration.
dita-ot-1.5.3/demo/book/installstorage.xml 0000664 0000000 0000000 00000001226 11671002146 0020513 0 ustar 00root root 0000000 0000000
Installing hard drives or other storageA simple guide to installing hard drives.Overviewhard driveinstallFirst purchase a hard drive at your local electronics store or from
a qualified representative.
dita-ot-1.5.3/demo/book/installwebserver.xml 0000664 0000000 0000000 00000001122 11671002146 0021046 0 ustar 00root root 0000000 0000000
Installing your own Web ServerInstalling a Web Server may sound tricky, but it is quite simple
if you follow our instructions.Overviewweb serverinstall
dita-ot-1.5.3/demo/book/maintaindatabase.xml 0000664 0000000 0000000 00000001457 11671002146 0020753 0 ustar 00root root 0000000 0000000
Maintaining a databaseMaintaining a database does not take much work.databasemaintainIf the database crashes, restart it.If the database is slow, tell people not to put so much in it.Try to limit the number of records in your database. Too many records
leads to confusion.
dita-ot-1.5.3/demo/book/maintaining.xml 0000664 0000000 0000000 00000001100 11671002146 0017745 0 ustar 00root root 0000000 0000000
MaintainingYou maintain your solution to ensure that all components
are operating at maximum efficiency.
Maintenance is a task that you perform along with configuration to
get the most from your solution.
dita-ot-1.5.3/demo/book/maintainserver.xml 0000664 0000000 0000000 00000001566 11671002146 0020516 0 ustar 00root root 0000000 0000000
Maintaining a Web ServerMaintaining a web server is really quite easy.Web ServermaintainIf the web server crashes, restart it.Limit the number of connections to your server.This
will make it run faster.Make sure you do not put confidential material on your server.It should be kept in a separate folder named "Private."
dita-ot-1.5.3/demo/book/maintainstorage.xml 0000664 0000000 0000000 00000002567 11671002146 0020656 0 ustar 00root root 0000000 0000000
Maintaining your hard driveHere are a few tips for maintaining your hard drive.hard drivemaintainThere is really not much to do to maintain a hard drive. However,
if you want to keep it running for the next 10 years or so, you should follow
these suggestions.If your drive has a low-power mode, make sure this comes on when
your drive is sitting idle.It will not get worn out as quickly
if it is not needlessly spinning.Every once in a while, shake your computer.This will
cause the bits to fall more comfortably in to place.Run Scandisk on the drive at least once a day.This
way you will ensure that problems with the drive are found quickly. If you
share the drive with others, it will also ensure that they are less likely
to use it, because it will be so busy all of the time.
dita-ot-1.5.3/demo/book/plugin.xml 0000664 0000000 0000000 00000000604 11671002146 0016755 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/book/replacecover.xml 0000664 0000000 0000000 00000001447 11671002146 0020137 0 ustar 00root root 0000000 0000000
Replace the cover of your system.The cover needs to be put back on to reduce problems from dust.hard driveComputer
coverRetrieve the computer's cover from its safe place. Put it back
on.Retrieve the screws from the safe place. Put them back in.Put away your screwdriver before you lose it.
dita-ot-1.5.3/demo/book/restart.xml 0000664 0000000 0000000 00000001752 11671002146 0017150 0 ustar 00root root 0000000 0000000
Restart your systemThis is standard procedure after installing any new software.Restartingweb serverdatabaseIf you are on a Windows system, go to the start menu.Go to Start -> Shut Down...Select "Restart" and hit OK.If you are on a Linux system, contact your system administrator
for assistance. You may not need to restart.If you are on a Macintosh, go to Special -> Restart.
dita-ot-1.5.3/demo/book/runsetup.xml 0000664 0000000 0000000 00000002122 11671002146 0017341 0 ustar 00root root 0000000 0000000
Run Setup.exeAs with any major program, you will need to run setup in order
to install it.Setupweb serverdatabaseSetup.exe can be found in the root directory of the CD-ROM with your
software.Insert the CD-ROM.Navigate to it from a typescript, DOS, or other command window.Type setup.exe and hit enter.Follow all of the prompts that appear.It is suggested that you follow all of the
defaults, but you may select an alternate directory for the install.
dita-ot-1.5.3/demo/book/task_appendix.xml 0000664 0000000 0000000 00000001023 11671002146 0020305 0 ustar 00root root 0000000 0000000
AppendixThis appendix describes things that you rarely need
to know.
You can consult this section when you need detailed informatin
about a specific component.
dita-ot-1.5.3/demo/book/task_bkinfo.xml 0000664 0000000 0000000 00000001701 11671002146 0017750 0 ustar 00root root 0000000 0000000
Product Tasks -- NOTE: See comment at the
top of taskbook.ditamapTasks and what they can doA brief summary of all operational knowledge
including the evolution of human culture.20032004IBM Corporation
New Orchard Road
Armonk, New York 10504
914-499-1900
dita-ot-1.5.3/demo/book/task_preface.xml 0000664 0000000 0000000 00000001606 11671002146 0020111 0 ustar 00root root 0000000 0000000
PrefaceThis book explains each tasks separately. You can jump in
anywhere, get the information you need, and complete your work. THIS SAMPLE USES THE DEPRECATED DEMO VERSION OF
BOOKMAP. There is now a standard version of
bookmap with several important differences.
As soon as you are able, you should switch to the
official bookmap. A sample is located at
samples/taskbook.ditamap
You can use this book to master tasks if you wish or just keep it
handy as a resource so you can focus on other issues.
dita-ot-1.5.3/demo/book/taskbook.ditamap 0000664 0000000 0000000 00000004240 11671002146 0020113 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/book/troubleshooting.xml 0000664 0000000 0000000 00000001211 11671002146 0020701 0 ustar 00root root 0000000 0000000
TroubleshootingThe troubleshooting tasks explain how to diagnose the cause
of and recover from problems.
To fix a problem, you often have to configure or maintain a
component.
The troubleshooting tasks help you determine what to work on to get
back to normal operations.
dita-ot-1.5.3/demo/book/unscrewcover.xml 0000664 0000000 0000000 00000001544 11671002146 0020210 0 ustar 00root root 0000000 0000000
Remove the cover of your systemThis is a simple task requiring a screwdriver.hard driveComputer
coverFirst be sure you are grounded.Perform the operation in a well ventilated room.Unscrew the screws that hold the cover to your system.Store them in a safe place.Remove the cover and place it in a safe place as well.
dita-ot-1.5.3/demo/book/webtrouble.xml 0000664 0000000 0000000 00000002017 11671002146 0017631 0 ustar 00root root 0000000 0000000
Troublshooting Web Server problemsThere are several things to try if your Web Server is not functioning
properly.troubleshootingweb serverIf others cannot connect to your server, try turning off their
firewalls.If your server is running slowly, try limiting it to 2 or 3 connections.If your server keeps creating pop-up ads when people access it,
please turn them off and things will run faster.If these directions are not helpful, please contact your
service representative.
dita-ot-1.5.3/demo/dita11/ 0000775 0000000 0000000 00000000000 11671002146 0015066 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/dita11/catalog.xml 0000664 0000000 0000000 00000017174 11671002146 0017234 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/dtd/ 0000775 0000000 0000000 00000000000 11671002146 0015641 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/dita11/dtd/bookmap.dtd 0000664 0000000 0000000 00000014141 11671002146 0017767 0 ustar 00root root 0000000 0000000
%mapgroup-d-dec;
%indexing-d-dec;
%xnaldomain-d-dec;
%map-type;
%bookmap-type;
%mapgroup-d-def;
%indexing-d-def;
%xnaldomain-d-def;
dita-ot-1.5.3/demo/dita11/dtd/bookmap.mod 0000664 0000000 0000000 00000106410 11671002146 0017774 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/dtd/commonElements.ent 0000664 0000000 0000000 00000020546 11671002146 0021345 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/dtd/commonElements.mod 0000664 0000000 0000000 00000115564 11671002146 0021343 0 ustar 00root root 0000000 0000000
%commonDefns;
%tableXML;
dita-ot-1.5.3/demo/dita11/dtd/concept.dtd 0000664 0000000 0000000 00000020353 11671002146 0017774 0 ustar 00root root 0000000 0000000
%ui-d-dec;
%hi-d-dec;
%pr-d-dec;
%sw-d-dec;
%ut-d-dec;
%indexing-d-dec;
%topic-type;
%concept-typemod;
%ui-d-def;
%hi-d-def;
%pr-d-def;
%sw-d-def;
%ut-d-def;
%indexing-d-def;
dita-ot-1.5.3/demo/dita11/dtd/concept.mod 0000664 0000000 0000000 00000014123 11671002146 0017776 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/dtd/ditabase.dtd 0000664 0000000 0000000 00000023725 11671002146 0020123 0 ustar 00root root 0000000 0000000
%ui-d-dec;
%hi-d-dec;
%pr-d-dec;
%sw-d-dec;
%ut-d-dec;
%indexing-d-dec;
%topic-type;
%concept-typemod;
%task-typemod;
%reference-typemod;
%glossary-typemod;
%ui-d-def;
%hi-d-def;
%pr-d-def;
%sw-d-def;
%ut-d-def;
%indexing-d-def;
dita-ot-1.5.3/demo/dita11/dtd/glossary.dtd 0000664 0000000 0000000 00000020421 11671002146 0020200 0 ustar 00root root 0000000 0000000
%ui-d-dec;
%hi-d-dec;
%pr-d-dec;
%sw-d-dec;
%ut-d-dec;
%indexing-d-dec;
%topic-type;
%concept-typemod;
%glossary-typemod;
%ui-d-def;
%hi-d-def;
%pr-d-def;
%sw-d-def;
%ut-d-def;
%indexing-d-def;
dita-ot-1.5.3/demo/dita11/dtd/glossary.mod 0000664 0000000 0000000 00000014073 11671002146 0020212 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/dtd/highlightDomain.ent 0000664 0000000 0000000 00000005207 11671002146 0021454 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/dtd/highlightDomain.mod 0000664 0000000 0000000 00000014474 11671002146 0021453 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/dtd/indexingDomain.ent 0000664 0000000 0000000 00000005335 11671002146 0021314 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/dtd/indexingDomain.mod 0000664 0000000 0000000 00000010671 11671002146 0021304 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/dtd/map.dtd 0000664 0000000 0000000 00000013654 11671002146 0017124 0 ustar 00root root 0000000 0000000
%mapgroup-d-dec;
%indexing-d-dec;
%map-type;
%mapgroup-d-def;
%indexing-d-def;
dita-ot-1.5.3/demo/dita11/dtd/map.mod 0000664 0000000 0000000 00000041062 11671002146 0017122 0 ustar 00root root 0000000 0000000
%commonElements;
%metaXML;
dita-ot-1.5.3/demo/dita11/dtd/mapGroup.ent 0000664 0000000 0000000 00000005602 11671002146 0020146 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/dtd/mapGroup.mod 0000664 0000000 0000000 00000010574 11671002146 0020143 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/dtd/metaDecl.mod 0000664 0000000 0000000 00000034352 11671002146 0020067 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/dtd/programmingDomain.ent 0000664 0000000 0000000 00000006246 11671002146 0022033 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/dtd/programmingDomain.mod 0000664 0000000 0000000 00000047342 11671002146 0022026 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/dtd/reference.dtd 0000664 0000000 0000000 00000020302 11671002146 0020271 0 ustar 00root root 0000000 0000000
%ui-d-dec;
%hi-d-dec;
%pr-d-dec;
%sw-d-dec;
%ut-d-dec;
%indexing-d-dec;
%topic-type;
%reference-typemod;
%ui-d-def;
%hi-d-def;
%pr-d-def;
%sw-d-def;
%ut-d-def;
%indexing-d-def;
dita-ot-1.5.3/demo/dita11/dtd/reference.mod 0000664 0000000 0000000 00000030434 11671002146 0020304 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/dtd/softwareDomain.ent 0000664 0000000 0000000 00000006070 11671002146 0021336 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/dtd/softwareDomain.mod 0000664 0000000 0000000 00000016401 11671002146 0021326 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/dtd/task.dtd 0000664 0000000 0000000 00000020160 11671002146 0017277 0 ustar 00root root 0000000 0000000
%ui-d-dec;
%hi-d-dec;
%pr-d-dec;
%sw-d-dec;
%ut-d-dec;
%indexing-d-dec;
%topic-type;
%task-typemod;
%ui-d-def;
%hi-d-def;
%pr-d-def;
%sw-d-def;
%ut-d-def;
%indexing-d-def;
dita-ot-1.5.3/demo/dita11/dtd/task.mod 0000664 0000000 0000000 00000050162 11671002146 0017310 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/dtd/tblDecl.mod 0000664 0000000 0000000 00000037761 11671002146 0017731 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/dtd/topic.dtd 0000664 0000000 0000000 00000017646 11671002146 0017472 0 ustar 00root root 0000000 0000000
%ui-d-dec;
%hi-d-dec;
%pr-d-dec;
%sw-d-dec;
%ut-d-dec;
%indexing-d-dec;
%topic-type;
%ui-d-def;
%hi-d-def;
%pr-d-def;
%sw-d-def;
%ut-d-def;
%indexing-d-def;
dita-ot-1.5.3/demo/dita11/dtd/topic.mod 0000664 0000000 0000000 00000050554 11671002146 0017471 0 ustar 00root root 0000000 0000000
%topicDefns;
%commonElements;
%metaXML;
dita-ot-1.5.3/demo/dita11/dtd/topicDefn.ent 0000664 0000000 0000000 00000010507 11671002146 0020267 0 ustar 00root root 0000000 0000000
%commonDefns;
dita-ot-1.5.3/demo/dita11/dtd/uiDomain.ent 0000664 0000000 0000000 00000006033 11671002146 0020120 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/dtd/uiDomain.mod 0000664 0000000 0000000 00000013735 11671002146 0020120 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/dtd/utilitiesDomain.ent 0000664 0000000 0000000 00000005765 11671002146 0021531 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/dtd/utilitiesDomain.mod 0000664 0000000 0000000 00000014154 11671002146 0021512 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/dtd/xnalDomain.ent 0000664 0000000 0000000 00000005073 11671002146 0020450 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/dtd/xnalDomain.mod 0000664 0000000 0000000 00000035576 11671002146 0020454 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/plugin.xml 0000664 0000000 0000000 00000000442 11671002146 0017106 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/schema/ 0000775 0000000 0000000 00000000000 11671002146 0016326 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/dita11/schema/bookmap.xsd 0000664 0000000 0000000 00000011226 11671002146 0020500 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/schema/bookmapGrp.xsd 0000664 0000000 0000000 00000024021 11671002146 0021146 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/schema/bookmapMod.xsd 0000664 0000000 0000000 00000211677 11671002146 0021154 0 ustar 00root root 0000000 0000000
The <bookmap> element is a map file used to organize DITA content
into a traditional book format. The <bookmeta> element contains information about the book that
is not considered book content, such as copyright information, author information,
and any classifications. The <frontmatter> element contains the material that precedes
the main body of a document. It may include items such as an abstract, a preface,
and various types of book lists such as a <toc>, <tablelist>, or <figurelist>. The <backmatter> element contains the material that follows
the main body of a document and any appendixes. It may include items such
as a colophon, legal notices, and various types of book lists such as a glossary
or an index. The <publisherinformation> contains information about what group
or person published the book, where it was published, and certain details
about its publication history. Other publication history information is found
in the <bookchangehistory> element. The <person> element contains information about the name of
a person. Note that unlike the <personname> element, the <person> element
is not restricted to describing the names of authors. The <organization> element contains the name of an organization.
Note that unlike <organizationname>, the <organization> element is not
restricted to usage within <authorinformation>; it does not have to contain
the name of an authoring organization.The <bookchangehistory> element contains information about the
history of the book's creation and publishing lifecycle, who wrote, reviewed,
edited, and tested the book, and when these events took place. The <bookid> element contains the publisher's identification
information for the book, such as part number, edition number and ISBN number. The <summary> element contains a text summary associated with
a book event (such as <approved> or <reviewed>) or with the list of
copyrights for the book.The <printlocation> element indicates the location where the
book was printed. Customarily, the content is restricted to the name of the
country. The <published> element contains information about the person
or organization publishing the book, the dates when it was started and completed,
and any special restrictions associated with it. The <publishtype> element indicates whether the book is generally
available or is restricted in some way. The value attribute
indicates the restrictions.The <revisionid> element indicates the revision number or revision
ID of the book. The processing implementation determines how the level is
displayed. Common methods include using a dash, for example "-01". or a period,
such as ".01". The <started> element indicates a start date for some type of
book event, such as a review, editing, or testing. The <completed> element indicates a completion date for some
type of book event, such as a review, editing, or testing. The <year> element denotes a year.The <month> element denotes a month of the year. The <day> element denotes a day of the month. The <reviewed> element contains information about when and by
whom the book was reviewed during its publication history.The <edited> element contains information about when and by
whom the book was edited during its publication history.The <tested> element contains information about when and by
whom the book was tested during its publication history.The <approved> element contains information about when and by
whom the book was approved during its publication history.The <bookevent> element indicates a general event in the publication
history of a book. This is an appropriate element for specialization if the
current set of specific book event types, that is, review, edit, test or approval,
does not meed your needs. The <bookeventtype> element indicates the specific nature of
a <bookevent>, such as updated, indexed, or deprecated. The required name attribute
indicates the event's type. The <bookpartno> element contains the book's part number; such
as 99F1234. This is generally the number that the publisher uses to identify
the book for tracking purposes. The <edition> element contains the edition number information,
such as First Edition, or Third Edition, used by a publisher to identify a
book.The <isbn> element contains the book's International Standard
Book Number (ISBN).The <booknumber> element contains the book's form number, such
as SC21-1920.The <volume> element contains the book's volume number, such
as Volume 2.The <maintainer> element contains information about who maiintains
the document; this can be an organization or a person.The <bookrights> element contains the information about the
legal rights associated with the book, including copyright dates and owners.The <copyfirst> element contains the first copyright year within
a multiyear copyright statement.The <copylast> element contains the last copyright year within
a multiyear copyright statement.The <bookowner> element contains the owner of the copyright.The <bookrestriction> element indicates whether the book is
classified, or restricted in some way. The value attribute indicates the restrictions;
this may be a string like "All Rights Reserved," representing the publisher's
copyright restrictions.The <booktitle> element contains the title information for a
book. , including <booklibrary> data, a <maintitle> and subtitle (<titlealt>)
as required. The <booklibrary> element contains the library information for
a book. Library entries contain information about the series, library, or
collection of documents to which the book belongs. The <mainbooktitle> element contains the primary title information
for a book.The <booktitlealt> element contains the alternative title, subtitle,
or short title for a book.The <draftintro> element references a topic used as an introduction
to the draft of this book.The <bookabstract> element references a topic used within a bookmap as
a brief summary of book content, generally output as part of the book's front
matter. It is used to help the reader quickly evaluate the book's purpose.The <dedication> element references a topic containing a dedication
for the book, such as to a person or group.The <preface> element references introductory information about
a book, such as the purpose and structure of the document. The <chapter> element references a topic as a chapter within
a book. The <part> element references a part topic for the book. A new
part is started. Use <part> to divide a document's chapters into logical
groupings. For example, in a document that contains both guide and reference
information, you can define two parts, one containing the guide information
and the other containing the reference information. designates a topic as an appendix within a bookmapThe <notices> element references special notice information,
for example, legal notices about supplementary copyrights and trademarks associated
with the book.The <amendments> element references a list of amendments or
updates to the book. It indicates to the processing software that the author
wants an amendments list generated at the particular location. The <colophon> element references a topic describing how this
document was created. In publishing, a colophon describes details of the production
of a book. This information generally includes the typefaces used, and often
the names of their designers; the paper, ink and details of the binding materials
and methods may also receive mention. In the case of technical books, a colophon
may specify the software used to prepare the text and diagrams for publication. The <booklists> element references lists of various kinds within
the book. For example, it can be used within front matter to reference a <toc>,
<tablelist>, and <figurelist>, or within back matter to reference a
<glossarylist>, <indexlist>, and <abbrevlist>. It indicates to the
processing software that the author wants the lists generated at the <booklists>
location. The <toc> element references the table of contents within the
book. It indicates to the processing software that the author wants a table
of contents generated at the particular location.The <figurelist> element references a list of figures in the
book. It indicates to the processing software that the author wants a list
of figures generated at the particular location. The <tablelist> element references a list of tables within the
book. It indicates to the processing software that the author wants a list
of tables generated at the particular location.The <abbrevlist> element references a list of abbreviations.
It indicates to the processing software that the author wants an abbreviation
list generated at the particular location. The <trademarklist> element references a list of trademarks
within the book. It indicates to the processing software that the author wants
a list of trademarks generated at the particular location.The <bibliolist> element references a list of bibliographic
entries within the book. It indicates to the processing software that the
author wants a bibliography, containing links to related books, articles,
published papers, or other types of material, generated at the particular
location. The <glossarylist> element references a list of glossary entries
within the book. It indicates to the processing software that the author wants
a glossary list generated at the particular location. The <indexlist> element lists the index entries in the book.
It indicates to the processing software that the author wants an index generated
at the particular location. The <booklist> element is a general purpose element, designed
for use in specializations, that references a list of particular types of
topics within the book. It indicates to the processing software that the author
wants that list of topics generated at the particular location. For example,
it could be used in a specialization to reference the location of a list of
program listings or of authors of topics. dita-ot-1.5.3/demo/dita11/schema/commonElementGrp.xsd 0000664 0000000 0000000 00000020343 11671002146 0022323 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/schema/commonElementMod.xsd 0000664 0000000 0000000 00000264471 11671002146 0022326 0 ustar 00root root 0000000 0000000
Display attributes is a parameter entity declaration in the topic
DTD that includes attributes whose values may be used for affecting the display
of a topic or its selection by search tools.
ID attributes (%id-atts;) is a parameter entity declaration in the
topic DTD that includes attributes that enable the naming and referencing
of elements in a DITA topic: id and conref.
Attributes that support both filtering and flagging include platform, product,
audience, and otherprops. Attribute rev only
lets you flag information that matches a run-time parameter. Attribute importance currently
provides output effects only for steps (where only the values "optional" and
"required" are supported).
Universal attributes is a parameter entity declaration in the topic DTD that
includes all of the attributes in the select-atts and id-atts attribute groups.
Debugging attributes, normally hidden from authoring view.
The <title> element contains a heading or
label for the main parts of a document such as <topic>, <section>, and
<example> and for the display elements such as figure (<fig>)
and <table>.
The <keyword> element identifies a keyword
or token, such as a single value from an enumerated list, the name of a command
or parameter, or a lookup key for a message (contrast with term).
The <desc> element contains the description
of the current element. A description should provide more information than
the title.
The phrase (<ph>) element is used to organize
content for reuse or conditional processing (for example, when part of a paragraph
applies to a particular audience). It can be used by future specializations
of DITA to apply specific processing or formatting to marked up phrases.var & keyword defined by syntax diagramThe <term> element identifies words that
represent extended definitions or explanations. In future development of DITA,
for example, terms might provide associative linking to matching glossary
entries.
Inline content (prhases)The trademark (<tm>) element in DITA is used
to markup and identify a term or phrase that is trademarked. Trademarks include
registered trademarks, service marks, slogans and logos.
( Deprecated ) - The <boolean> element is used to express
one of two opposite values, such as yes or no, on or off, true or false, high
or low, and so forth. The element itself is empty; the value of the element
is stored in its state attribute, and
the semantic associated with the value is typically in a specialized name
derived from this element. If you need more than two values (for example,
"yes," "no" and "don't care") use the <state> element instead. This element is primarily for specialization, where
it can be used to require a logical true or false designation in a particular
part of the document.
The <state> element specifies a name/value
pair whenever it is necessary to represent a named state that has a variable
value. The element is primarily intended for use in specializations to represent
specific states (like logic circuit states, chemical reaction states, airplane
instrumentation states, and so forth).
A paragraph element (<p>) is a block of
text containing a single main idea.
TThe long quote (<lq>) element indicates
content quoted from another source. Use the quote element <q>for
short, inline quotations, and long quote <lq> for quotations
that are too long for inline use, following normal guidelines for quoting
other sources. You can store a URL to the source of the quotation in the href attribute.
A <note> element contains information, differentiated
from the main text, which expands on or calls attention to a particular point.
A quotation element (<q>) indicates content quoted from another
source. This element is used for short quotes which are displayed inline.
Use the long quote element (<lq>) for quotations that should be set off
from the surrounding text.
In an unordered list (<ul>), the order of the list items is
not significant. List items are typically styled on output with a "bullet"
character, depending on nesting level.
An ordered list (<ol>) is a list of items sorted by sequence
or order of importance.
The <sl> element contains a simple list of
items of short, phrase-like content, such as in documenting the materials
in a kit or package.
A simple list item (<sli>) is a single item in a simple list<sl>.
Simple list items have phrase or text content, adequate for describing package
contents, for example. When a DITA topic is formatted for output, the items
of a simple list are placed each on its own line, with no other prefix such
as a number (as in an ordered list) or bullet (as in an unordered list)..
A list (<li>) item is a single item in an ordered <ol> or
unordered <ul> list. When a DITA topic is formatted for output, numbers
and alpha characters are usually output with list items in ordered lists,
while bullets and dashes are usually output with list items in unordered lists.
The <itemgroup> element is reserved for specialization
of DITA. As a container element, it can be used to sub-divide or organize
elements that occur inside a list item, definition, or parameter definition.A definition list (<dl>) is a list of terms
and corresponding definitions. The term (<dt>) is usually
flush left. The description or definition (<dt>) is
usually either indented and on the next line, or on the same line to the right
of the term.
The <dlhead> element contains optional headings
for the term and description columns in a definition list. The definition
list heading contains a heading <dthd> for the column
of terms and an optional heading <ddhd>for the column
of descriptions.
The definition descriptions heading (<ddhd>) element contains
an optional heading or title for a column of descriptions or definitions in
a definition list
The definition term heading (<dthd>) element is contained in
a definition list head (<dlhead>) and provides an optional heading for
the column of terms in a description list.In a definition list, each list item is defined by the definition
list entry (<dlentry>) element. The definition list entry element includes
a term <dt> and one or more definitions or descriptions <dd> of that
term.
The definition term <dt> element contains
a term in a definition list entry.
The definition description (<dd>) element
contains the description of a term in a definition list entry.
The figure (<fig>) element is a display context
(sometimes called an exhibit) with an optional title for a wide variety
of content. Most commonly, the figure element contains an image element (a
graphic or artwork), but it can contain several kinds of text objects as well.
A title is placed inside the figure element to provide a caption to describe
the content.
The <figgroup> element is used only for specialization
at this time. Figure groups can be used to contain multiple cross-references,
footnotes or keywords, but not multipart images. Multipart images in DITA
should be represented by a suitable media type displayed by the <object>
element.
The preformatted element (<pre>) preserves
line breaks and spaces entered manually by the author in the content of the
element, and also presents the content in a monospaced type font (depending
on your output formatting processor).
The <lines> element may be used to represent
dialogs, lists, text fragments, and so forth. The <lines>
element is similar to <pre> in that hard line breaks
are preserved, but the font style is not set to monospace, and extra spaces
inside the lines are not preserved.
Include artwork or images in a DITA topic by using the <image>
element. The <image> element has optional attributes
that indicate whether the placement of the included graphic or artwork should
be inline (like a button or icon), or on a separate line for a larger image.
An href attribute is required on the image element,
as this attribute creates a pointer to the image, and allows the output formatting
processor to bring the image into the text flow. To make the intent of the
image more accessible for users using screen readers or text-only readers,
always include a description of the image's content in the alt attribute.
The alt element provides an element equivalent of the alt attribute
on the image element. As an element, it provides direct text entry within
an XML editor and is more easily accessed than an attribute for translation.
DITA's <object> element corresponds to the
HTML <object> element. The <object>
element allows authors to include animated images, applets, plug-ins, ActiveX
controls, video clips, and other multimedia objects in a topic for rendering
after transformation to HTML.
The parameter (<param>)element specifies
a set of values that may be required by an <object>
at runtime. Any number of <param> elements may appear
in the content of an object in any order, but must be placed at the start
of the content of the enclosing object. This element is comparable to the
XHMTL <param> element.
The <simpletable> element is used for tables
that are regular in structure and do not need a caption. Choose the simple
table element when you want to show information in regular rows and columns.
For example, multi-column tabular data such as phone directory listings or
parts lists are good candidates for simpletable. Another good use of simpletable
is for information that seems to beg for a "three-part definition list"—just
use the keycol attribute to indicate which column represents the "key" or
term-like column of your structure.
The simpletable header (<sthead>) element contains the table's
header row. The header row is optional in a simple table.
The <simpletable> row (<strow>)
element specifies a row in a simple table, like row in a conventional table.
The simpletable entry (<stentry>) element represents a single
table cell, like <entry> in <table>. You can place any number of stentry
cells in either an sthead element
(for headings) or strow element (for
rows of data).
The <draft-comment> element allows simple
review and discussion of topic contents within the marked-up content. Use
the <draft-comment> element to ask a question or make a comment that you
would like others to review. To indicate the source of the draft comment or
the status of the comment, use the author, time or disposition attributes.
A <required-cleanup> element is used as a
placeholder for migrated elements that cannot be appropriately tagged without
manual intervention. As the element name implies, the intent for authors is
to clean up the contained material and eventually get rid of the <required-cleanup>
element. Authors should not insert this element into documents.
Use footnote (<fn>) to annotate text with
notes that are not appropriate for inclusion in line or to indicate the source
for facts or other material used in the text.
An <indextermref> is a reference to an index
entry in a lookup table used by the indexing process. If you want to create
index markers pointing to referenced items, but only want page numbers instead
of separate index entries to be generated, use the index term reference <indextermref>
element. This adds the page number of the reference to the index without creating
a separate index entry.
The <cite> element is used when you need
a bibliographic citation that refers to a book or article. It specifically
identifies the title of the resource. Its keyref attribute
allows the citation to be associated to other possible bibliographic processing
(not supported yet).
Use the cross-reference (<xref>) element
to link to a different location within the current topic, or a different topic
within the same help system or DITA document. You can also point to external
sources, such as Web pages, or to a location in another topic as well. The href attribute
on the <xref> element is used to create the link pointer,
or URL.
The class attribute supports specialization. Its predefined values help
the output transforms work correctly with ranges of related content.
The <data> element represents a property
within a DITA topic or map. While the <data> element
can be used directly to capture properties, it is particularly useful as a
basis for specialization. Default processing treats the property values as
an unknown kind of metadata, but custom processing can match the name attribute
or specialized element to format properties as sidebars or other adornments
or to harvest properties for automated processing.
The <data-about> element identifies the subject
of a property when the subject isn't associated with the context in which
the property is specified. The property itself is expressed by the <data>
element. The <data-about> element handles exception
cases where a property must be expressed somewhere other than inside the actual
subject of the property. The <data-about> element is
particularly useful as a basis for specialization in combination with the <data>
element.
Don't use the <data-about>
element to identify the object of a property. The href attribute
of the <data> element serves that purpose.
The <foreign> element is an open extension that allows information architects
to incorporate existing standard vocabularies for non-textual content. like MathML and SVG, as inline
objects. If <foreign> contains more than one alternative content element, they will all be processed.
Specialization of <foreign> should be implemented as a domain, but for those looking for more
control over the content can implement foreign vocabulary as an element specialization.An <indexterm> is an index entry. You can
nest entries to create multi-level indexes. The content is not output as part
of topic content, only as part of the index.
The <index-base> element allows indexing extensions to be added by specializing off this
element. It does not in itself have any meaning and should be ignored in processing.
The <unknown> element is an open extension that allows information architects to
incorporate xml fragments that does not necessarily fit into an exisitng DITA use case.
The base processing for <unknown> is to supress unless otherwise instructed.
dita-ot-1.5.3/demo/dita11/schema/concept.xsd 0000664 0000000 0000000 00000013025 11671002146 0020502 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/schema/conceptGrp.xsd 0000664 0000000 0000000 00000003402 11671002146 0021151 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/schema/conceptMod.xsd 0000664 0000000 0000000 00000013047 11671002146 0021146 0 ustar 00root root 0000000 0000000
The <concept> element is the top-level
element for a topic that answers the question what is? Concepts provide
background information that users must know before they can successfully work
with a product or interface. Often, a concept is an extended definition of
a major abstraction such as a process or function. It might also have an example
or a graphic, but generally the structure of a concept is fairly simple.
The <conbody> element is the main body-level
element for a concept. Like the body element of a general topic, <conbody>
allows paragraphs, lists, and other elements as well as sections and examples.
But <conbody> has a constraint that a section
or an example can be followed only by other sections or examples.
dita-ot-1.5.3/demo/dita11/schema/ditaarch.xsd 0000664 0000000 0000000 00000003557 11671002146 0020637 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/schema/ditabase.xsd 0000664 0000000 0000000 00000022121 11671002146 0020620 0 ustar 00root root 0000000 0000000
The <dita> element provides a top-level container
for multiple topics when you create documents using the ditabase DTD. The
<dita> element lets you create any sequence of concept,
task, and reference topics, and the ditabase DTD lets you further nest these
topic types inside each other. The <dita> element has
no particular output implications; it simply allows you to create multiple
topics of different types at the same level in a single document.
dita-ot-1.5.3/demo/dita11/schema/glossary.xsd 0000664 0000000 0000000 00000015047 11671002146 0020720 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/schema/glossaryGrp.xsd 0000664 0000000 0000000 00000003574 11671002146 0021373 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/schema/glossaryMod.xsd 0000664 0000000 0000000 00000012571 11671002146 0021357 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/schema/highlightDomain.xsd 0000664 0000000 0000000 00000024215 11671002146 0022151 0 ustar 00root root 0000000 0000000
The superscript (<sup>) element indicates that text should
be superscripted, or vertically raised in relationship to the surrounding
text. Superscripts are usually a smaller font than the surrounding text.
Use this element only when there is not some other more proper tag. For example,
for specific items such as GUI controls, use the uicontrol tag. This element is part of the DITA highlighting
domain.
A subscript (<sub>) indicates that text should be subscripted,
or placed lower in relationship to the surrounding text. Subscripted text
is often a smaller font than the surrounding text. Formatting may vary depending
on your output process. This element is part of the DITA highlighting domain.
The teletype (<tt>) element is used to apply monospaced
highlighting to the content of the element. Use this element only when there
is not some other more proper tag. For example, for specific items such as
GUI controls, use the uicontrol tag.
This element is part of the DITA highlighting domain.
The bold (<b>) element is used to apply bold highlighting
to the content of the element. Use this element only when there is not some
other more proper tag. For example, for specific items such as GUI controls,
use the uicontrol tag.
This element is part of the DITA highlighting domain.
The underline (<u>) element is used to apply
underline highlighting to the content of the element. Use this element only
when there is not some other more proper tag. For example, for specific items
such as GUI controls, use the uicontrol tag.
This element is part of the DITA highlighting domain.
The italic (<i>) element is used to apply italic highlighting
to the content of the element. Use this element only when there
is not some other more proper tag. For example, for specific items such as
GUI controls, use the uicontrol tag.
Italic highlighting generally means a font that is slanted for emphasis, but
this may vary depending on your output formatting process. This element is
part of the DITA highlighting domain.
dita-ot-1.5.3/demo/dita11/schema/indexingDomain.xsd 0000664 0000000 0000000 00000011144 11671002146 0022004 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/schema/map.xsd 0000664 0000000 0000000 00000007357 11671002146 0017637 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/schema/mapGroupMod.xsd 0000664 0000000 0000000 00000011703 11671002146 0021302 0 ustar 00root root 0000000 0000000
The <topichead> element provides a title-only
entry in a navigation map, as an alternative to the fully-linked title provided
by the <topicref> element.
The <topicgroup> element is for creating
groups of <topicref> elements without affecting the
hierarchy, as opposed to nested <topicref> elements
within a <topicref>, which does imply a structural hierarchy.
It is typically used outside a hierarchy to identify groups for linking without
affecting the resulting toc/navigation output.
dita-ot-1.5.3/demo/dita11/schema/mapGrp.xsd 0000664 0000000 0000000 00000006211 11671002146 0020274 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/schema/mapMod.xsd 0000664 0000000 0000000 00000055544 11671002146 0020300 0 ustar 00root root 0000000 0000000
The %topicref-atts; parameter entity represents a group of attributes
used in numerous map elements: map, topicref, relcolspec, relcell, topichead,
and topicgroup. The set is similar to those documented in topicref-atts-no-toc but
includes the toc attribute.
The %topicref-atts-no-toc; parameter entity represents the set
of attributes used in the reltable map
element. The set is similar to those documented in topicref-atts but
for <reltable> the toc attribute
defaults to no. For the other elements that use the %topicref-atts;
group declaration, the toc attribute doesn't have
a default; they can inherit their toc value from
the nearest container, otherwise it functions upon output as if set to yes.
The <map> element is used to define a map
which describes the relationships among a set of DITA topics. Maps consist
of references to topics organized into hierarchies and tables. Maps provide
a way to express these relationships in a single common format that can be
used for different outputs.
The <navref> element references a map file
from within a map file. The reference is resolved at runtime for Eclipse
navigation, typically to pull together the navigation for multiple components
into a product navigation.
The <topicref> element designates a topic
(such as a concept, task, or reference) as a link in a DITA map. A <topicref>
can contain other<topicref> elements, allowing you to
express navigation or table-of-contents hierarchies, as well as implying relationships
between the containing <topicref> and its children.
You can set the collection-type of a container <topicref>
to determine how its children are related to each other. Relationships end
up expressed as links in the output (with each participant in a relationship
having links to the other participants).
The relationship table (<reltable>) defines
relationships between topics, based on the familiar table model of rows (<relrow>),
columns (<relheader>), and cells (<relcell>).
The <relcell> elements can contain <topicref>
elements, which are then related to other <topicref>
elements in the same row (although not necessarily in the same cell). By default,
the contents of a <reltable> element are not output
for navigation or TOC purposes, and are used only to define relationships
that can be expressed as topic-to-topic links.
The <relheader> element is a row of column
definitions (<relcolspec> elements) in a relationship
table. Each table can have only one set of column definitions.
A column definition in the relationship table. You can use <relcolspec>
column definitions to set defaults for the attributes of <topicref>
elements in the column. For example, you can set type="concept" to treat all
untyped <topicref> elements in the column as concepts.
A <relrow> is a row in the relationship table.
This creates a relationship between the cells in the row, which will end up
expressed as links among the <topicref> elements in
the cells.
A <relcell> element is a cell in the relationship
table. The <topicref> elements it contains will be related
to topicrefs in other cells of the same row. By default, topicrefs in the
same cell are not related to each other, unless you change the relcell's collection-type
attribute to indicate that they are related.
The <anchor> element is used for runtime
integration of navigation. It provides an integration point that another map
can point to in order to insert its navigation into the current navigation
tree. It is currently supported by Eclipse output only.
The <topicmeta> element defines the metadata
that applies to a topic and the topic's children. When creating links, it
can also be used to override the title and short description of the topic.
In addition, it can insert index entries through the <keywords>
element.
The <linktext> element provides the literal
label or line of text for a link. In most cases, the text of a link can be
resolved during processing by cross reference with the target resource. Use
the <linktext> element only when the target cannot be
reached, such as when it is a peer or external link.
When your DITA topic is transformed to XHTML, the <searchtitle>
element is used to create a title element at the top of the resulting HTML
file. This title is normally used in search result summaries by some search
engines, such as that in Eclipse (http://eclipse.org); if not set, the XHTML's
title element defaults to the source topic's title content (which may not
be as well optimized for search summaries)
The short description (<shortdesc>) element
occurs between the topic title and the topic body, as the initial paragraph-like
content of a topic. The short description, which represents the purpose or
theme of the topic, is also intended to be used as a link preview and for
searching.
dita-ot-1.5.3/demo/dita11/schema/metaDeclGrp.xsd 0000664 0000000 0000000 00000011137 11671002146 0021240 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/schema/metaDeclMod.xsd 0000664 0000000 0000000 00000065174 11671002146 0021241 0 ustar 00root root 0000000 0000000
The <author> metadata element contains the
name of the topic's author. The currently unsupported keyref attribute can
point to another location where the author information is defined.
The <source> element contains a reference
to a resource from which the present topic is derived, either completely or
in part. The element can contain a description of the resource; the href reference
can be a string or a URL that points to it.
The <publisher> metadata element contains
the name of the person, company, or organization responsible for making the
content or subject of the topic available.
The <copyright> element is used for a single
copyright entry. It includes the copyright years and the copyright holder.
Multiple <copyright> statements are allowed.
The <copyryear> element contains the copyright
year as specified by the year attribute.
The copyright holder (<copyrholder>) element
names the entity that holds legal rights to the material contained in the
topic.
The <critdates> element contains the critical
dates in a document life cycle, such as the creation date and multiple revision
dates.
The <revised> element in the prolog is used
to maintain tracking dates that are important in a topic development cycle,
such as the last modification date, the original availability date, and the
expiration date.
The <created> element specifies the document
creation date using the date attribute.
The <resourceid> element provides an identifier
for applications that require them in a particular format, when the normal
id attribute of the topic can't be used. Each resourceid entry should be unique.
It is one of the metadata elements that can be included within the prolog
of a topic, along with document tracking and product information, etc. The
element has no content, but takes an id attribute
or an appname attribute.
The <audience> metadata element indicates,
through the value of its type attribute, the intended audience for a topic.
Since a topic can have multiple audiences, you can include multiple audience
elements. For each audience you specify, you can identify the high-level task
(job) they are trying to accomplish and the level
of experience (experiencelevel) expected.
The <category> element can represent any
category by which a topic might be classified for retrieval or navigation;
for example, the categories could be used to group topics in a generated navigation
bar. Topics can belong to multiple categories.
The <keywords> element contains a list of
keyword entries (using indexterm or keyword markup) that can be used by a search
engine.
The <othermeta> element can be used to identify
properties not otherwise included in <metadata> and
assign name/content values to those properties. The name attribute identifies
the property and the content attribute specifies the property's value. The
values in this attribute are output as HTML metadata elements, and have no
defined meaning for other possible outputs such as PDF.
The <permissions> empty prolog element can
indicate any preferred controls for access to a topic. Topics can be filtered
based on the permissions element. This capability depends on your output formatting
process.
The <prodinfo> metadata element in the prolog
contains information about the product or products that are the subject matter
of the current topic.
The <brand> element indicates the manufacturer
or brand associated with the product described by the parent <prodinfo> element.
The <series> metadata element contains information
about the product series that the topic supports.
The <platform> metadata element contains
a description of the operating system and/or hardware related to the product
being described by the <prodinfo> element.
The <prognum> metadata element identifies
the program number of the associated program product. This is typically an
order number or a product tracking code that could be replaced by an order
number when a product completes development.
The <featnum> element contains the feature
number of a product in the document metadata.
The <component> element describes the component
of the product that this topic is concerned with. For example, a product might
be made up of many components, each of which is installable separately. Components
might also be shared by several products so that the same component is available
for installation with many products. This identification can be used to check
cross-component dependencies when some components are installed, but not others.
It could also be used to make sure that topics are hidden, removed, or flagged
in some way when the component they describe isn't installed. Such process-control
logic is not currently supported in DITA processing.
The <prodname> metadata element contains
the name of the product that is supported by the information in this topic.
The <vrmlist> element contains a set of <vrm>
elements for logging the version, release, and modification information for
multiple products or versions of products to which the topic applies.
The empty <vrm> element contains information about a single product's
version, modification, and release, to which the current topic applies.
dita-ot-1.5.3/demo/dita11/schema/programmingDomain.xsd 0000664 0000000 0000000 00000113052 11671002146 0022522 0 ustar 00root root 0000000 0000000
The code phrase (<codeph>) element represents a snippet
of code within the main flow of text. The code phrase may be displayed in
a monospaced font for emphasis. This element is part of the DITA programming
domain, a special set of DITA elements designed to document programming tasks,
concepts and reference information.
The <codeblock> element represents lines of
program code. Like the <pre> element,
content of this element has preserved line endings and is output in a monospaced
font. This element is part of the DITA programming domain, a special set of
DITA elements designed to document programming tasks, concepts and reference
information.
The <option> element describes an option
that can be used to modify a command (or something else, like a configuration).
This element is part of the DITA programming domain, a special set of DITA
elements designed to document programming tasks, concepts and reference information.
Within a syntax definition, the <var> element
defines a variable for which the user must supply content, such as their user
name or password. It is represented in output in an italic font.
This element is part of the DITA programming domain, a special set of DITA
elements designed to document programming tasks, concepts and reference information.
When referencing the name of an application programming interface
parameter within the text flow of your topic, use the parameter
name (<parmname>) element to markup the parameter. This element
is part of the DITA programming domain, a special set of DITA elements designed
to document programming tasks, concepts and reference information.
The syntax phrase (<synph>) element is a container for syntax
definition elements. It is used when a complete syntax definition is not needed,
but some of the syntax elements, such as kwd, oper, delim, are used within
the text flow of the topic content. This element is part of the DITA programming
domain, a special set of DITA elements designed to document programming tasks,
concepts and reference information.
The operator (<oper>) element defines an operator
within a syntax definition. Typical operators are equals (=), plus (+) or
multiply (*). This element is part of the DITA programming domain, a special
set of DITA elements designed to document programming tasks, concepts and
reference information.
Within a syntax definition, the delimiter (<delim>) element defines
a character marking the beginning or end of a section or part of the complete
syntax. Typical delimiter characters are the parenthesis, comma, tab, vertical
bar or other special characters. This element is part of the DITA programming
domain, a special set of DITA elements designed to document programming tasks,
concepts and reference information.
The separator (<sep>) element defines a separator character that
is inline with the content of a syntax definition. The separator occurs between
keywords, operators or groups in a syntax definition. This element is part
of the DITA programming domain, a special set of DITA elements designed to
document programming tasks, concepts and reference information.
The <apiname> element provides the name of
an application programming interface (API) such as a Java class name or method
name. This element is part of the DITA programming domain, a special set of
DITA elements designed to document programming tasks, concepts and reference
information.
The parameter list (<parml>) element contains a list of
terms and definitions that describes the parameters in an application programming
interface. This is a special kind of definition list that is
designed for computer parameters. This element is part of the DITA programming
domain, a special set of DITA elements designed to document programming tasks,
concepts and reference information.
The parameter list entry element (<plentry>) contains one or more parameter terms and definitions (pd and pt).
This element is part of the DITA programming domain, a special set of DITA elements designed to document
programming tasks, concepts and reference information.
A parameter term, within a parameter list entry, is enclosed by the <pt> element.
This element is part of the DITA programming domain, a special set of DITA elements designed to document
programming tasks, concepts and reference information.
A parameter definition, within a parameter list entry, is enclosed by the <pd> element.
This element is part of the DITA programming domain, a special set of DITA elements designed to document
programming tasks, concepts and reference information.
The syntax diagram (<syntaxdiagram>) element
is the main container for all the syntax elements that make up a syntax definition.
The syntax diagram represents the syntax of a statement from a computer language,
or a command, function call or programming language statement. Traditionally,
the syntax diagram is formatted with railroad tracks that
connect the units of the syntax together, but this presentation may differ
depending on the output media. The syntax diagram element is part of the DITA
programming domain, a special set of DITA elements designed to document programming
tasks, concepts and reference information.
The syntax block (<synblk>) element
organizes small pieces of a syntax definition into a larger piece. The syntax
block element is part of the DITA programming domain, a special set of DITA
elements designed to document programming tasks, concepts and reference information.
The <groupseq> element is part of the subset
of elements that define syntax diagrams in DITA. A group is a logical set
of pieces of syntax that go together. Within the syntax definition, groups
of keywords, delimiters and other syntax units act as a combined unit, and
they occur in a specific sequence, as delimited by the <groupseq>
element. This element is part of the DITA programming domain, a special set
of DITA elements designed to document programming tasks, concepts and reference
information.
The <groupchoice> element is part
of the subset of elements that define syntax diagrams in DITA. A group is
a logical set of pieces of syntax that go together. A group choice specifies
that the user must make a choice about which part of the syntax to use. Groups
are often nested. This element is part of the DITA programming domain, a special
set of DITA elements designed to document programming tasks, concepts and
reference information.
The <groupcomp> element is part
of the subset of elements that define syntax diagrams in DITA. A group is
a logical set of pieces of syntax that go together. The group composite means
that the items that make up the syntax diagram will be formatted close together
rather than being separated by a horizontal or vertical line, which is the
usual formatting method. This element is part of the DITA programming domain,
a special set of DITA elements designed to document programming tasks, concepts
and reference information.
Within a syntax definition, a <fragment> is
a labeled subpart of the syntax. The <fragment> element
allows breaking out logical chunks of a large syntax diagram
into named fragments. This element is part of the DITA programming domain,
a special set of DITA elements designed to document programming tasks, concepts
and reference information.
The fragment reference (<fragref>) element provides a
logical reference to a syntax definition fragment so that you can reference
a syntax fragment multiple times. This element is part of the DITA programming
domain, a special set of DITA elements designed to document programming tasks,
concepts and reference information.
The syntax note (<synnote>) element
contains a note (similar to a footnote) within a syntax definition group or
fragment. The syntax note explains aspects of the syntax that cannot be expressed
in the markup itself. The note will appear at the bottom of the syntax diagram
instead of at the bottom of the page. The syntax block element is part of
the DITA programming domain, a special set of DITA elements designed to document
programming tasks, concepts and reference information.
The syntax note (<synnoteref>) reference element references
a syntax note element (<synnote>) that has already been defined
elsewhere in the topic. The same notation can be used in more than one syntax
definition. The syntax note reference element is part of the DITA programming
domain, a special set of DITA elements designed to document programming tasks,
concepts and reference information.
The repeat separator (<repsep>) element defines
a group of syntax elements that can (or should) be repeated. If the <repsep>
element contains a separator character, such as a plus (+), this
indicates that the character must be used between repetitions of the syntax
elements. This element is part of the DITA programming domain, a special set
of DITA elements designed to document programming tasks, concepts and reference
information.
The <kwd> element defines a keyword in a syntax
definition. A keyword must be typed or output, either by the user or application,
exactly as specified in the syntax definition. This element is
part of the DITA programming domain, a special set of DITA elements designed
to document programming tasks, concepts and reference information.
dita-ot-1.5.3/demo/dita11/schema/reference.xsd 0000664 0000000 0000000 00000012654 11671002146 0021014 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/schema/referenceGrp.xsd 0000664 0000000 0000000 00000005704 11671002146 0021463 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/schema/referenceMod.xsd 0000664 0000000 0000000 00000037725 11671002146 0021462 0 ustar 00root root 0000000 0000000
The <reference> element defines a top-level container
for a reference topic. Reference topics document programming constructs or
facts about a product. Examples of reference topics include language elements,
class descriptions, commands, functions, statements, protocols, types, declarators,
operands, and API information, which provide quick access to facts, but no
explanation of concepts or procedures. Reference topics have the same high-level
structure as any other topic type, with a title, short description, and body.
Within the body, reference topics are typically organized into one or more
sections, property lists, and tables. The reference topic type provides general
rules that apply to all kinds of reference information, using elements like <refsyn> for
syntax or signatures, and <properties> for lists of properties
and values.
The <refbody> element is a container for the
main content of the reference topic. Reference topics limit the body structure
to tables (both simple and standard), property lists, syntax sections, and
generic sections and examples, in any sequence or number.
The <refsyn> element is a special section inside
a reference topic. The section often contains syntax or signature content
(for example, a command-line utility's calling syntax, or an API's signature).
The <refsyn> contains a brief, possibly diagrammatic
description of the subject's interface or high-level structure.
The <properties> element gives a list of properties for
the subject of the current topic, for example whether a class is public or protected.
Each property can include the type, value, and a description. The typical rendering is
usually in a table-like format. To represent multiple values for a type, just create
additional property elements and use only the <propvalue>
element (and <propdesc> when needed) for each successive
value.
The <property> element represents a property
of the current topic's subject. For example, if the current topic is a class,
the property might show that the class is protected rather than public.
It contains three optional elements: type, value, and description.
The <propvalue> element indicates the value or values
for the current property type. You can put values in separate rows if they
need separate descriptions, and just leave the <proptype> element
blank.
The <propdesc> element is used to provide a short description
of the property type and its listed values (or just the value).
The proptype element describes the type of property.
The prophead element supports regular headings for the properties element.
dita-ot-1.5.3/demo/dita11/schema/softwareDomain.xsd 0000664 0000000 0000000 00000031303 11671002146 0022030 0 ustar 00root root 0000000 0000000
The message phrase (<msgph>) element contains the text content
of a message produced by an application or program. It can also contain the
variable name (varname) element to illustrate where variable text content
can occur in the message. This element is part of the DITA software domain,
a special set of DITA elements designed to document software tasks, concepts
and reference information.
The message number (<msgnum>) element contains the number
of a message produced by an application or program. This element is part of
the DITA software domain, a special set of DITA elements designed to document
software tasks, concepts and reference information.
The variable name (<varname>) element defines a variable
that must be supplied to a software application. The variable name element
is very similar to the variable (var) element, but variable name is used outside
of syntax diagrams, possibly within a message or API description to describe
a system variable or environment variable. This element is part of the DITA
software domain, a special set of DITA elements designed to document software
tasks, concepts and reference information.
The message block (<msgblock>) element contains a multi-line
message or set of messages. The message block can contain multiple message
numbers and message descriptions, each enclosed in a <msgnum> and <msgph> element.
It can also contain the message content directly. This element is part of
the DITA software domain, a special set of DITA elements designed to document
software tasks, concepts and reference information.
The command name (<cmdname>) element specifies the name of a command
when it is part of a software discussion. This element is part of the DITA
software domain, a special set of DITA elements designed to document software
tasks, concepts and reference information.
The <filepath> element indicates
the name and optionally the location of a referenced file by specifying the
directory containing the file, and other directories that may precede it in
the system hierarchy. This element is part of the DITA software domain, a
special set of DITA elements designed to document software tasks, concepts
and reference information.
The user input (<userinput>) element represens the text
a user should input in response to a program or system prompt.
This element is part of the DITA software domain, a special set of DITA elements
designed to document software tasks, concepts and reference information.
The system output (<systemoutput>) element
represents computer output or responses to a command or situation.
A generalized element, it represents any kind of output from the computer,
so the author may wish to choose more specific markup, such as msgph, for
messages from the application. The system output element is part of the DITA
software domain, a special set of DITA elements designed to document software
tasks, concepts and reference information.
dita-ot-1.5.3/demo/dita11/schema/task.xsd 0000664 0000000 0000000 00000012636 11671002146 0020020 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/schema/taskGrp.xsd 0000664 0000000 0000000 00000011302 11671002146 0020456 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/schema/taskMod.xsd 0000664 0000000 0000000 00000100267 11671002146 0020456 0 ustar 00root root 0000000 0000000
The <task> element is the top-level element
for a task topic. Tasks are the main building blocks for task-oriented user
assistance. They generally provide step-by-step instructions that will enable
a user to perform a task. A task answers the question of "how to?" by telling
the user precisely what to do and the order in which to do it. Tasks have
the same high-level structure as other topics, with a title, short description
and body.
The <taskbody> element is the main body-level
element inside a task topic. A task body has a very specific structure, with
the following elements in this order: <prereq>, <context>,
<steps>, <result, <example>
and <postreq>. Each of the body sections are optional.
The pre-requisite (<prereq>) section of a
task should document things the user needs to know or do before starting the
current task. Prerequisite links will be placed in a list after the related-links
section; on output the <prereq> links from the related-links
section are added to the <prereq> section.
The <context> section of a task provides
background information for the task. This information helps the user understand
what the purpose of the task is and what they will gain by completing the
task. This section should be brief and does not replace or recreate a concept
topic on the same subject, although the context section may include some conceptual
information
The <result> element describes the expected
outcome for the task as a whole.
The <postreq> element describes steps or
tasks that the user should do after the successful completion of the current
task. It is often supported by links to the next task or tasks in the <related-links>
section.
Each <choice> element describes one way that
the user could accomplish the current step.
The <step> element represents an action that
a user must follow to accomplish a task. Each step in a task must contain
a command <cmd> element which describes the particular
action the user must do to accomplish the overall task. The step element can
also contain information <info>, substeps <substeps>,
tutorial information <tutorialinfo>, a step example
<stepxmp>, choices <choices> or
a stepresult <stepresult>, although these are optional.
A <substep> element has the same structure
as a <step>, except that it does not allow lists of
choices or substeps within it, in order to prevent unlimited nesting of steps.
Like the <steps> element, the <steps-unordered>
section of a task provides the main content of the task topic, but particularly
for cases in which the order of steps may vary from one situation to another.
For example, fields of a form can be filled in without particular regard
to order as long as the required ones are filled in before submitting the
form. One or more steps is required inside the <steps-unordered>
section.
The <choices> element contains a list of
<choice> elements. It is used when the user will need
to choose one of several actions while performing the steps of a task.
The <steps> section of a task provides the
main content of the task topic. The task is described as a series of steps
that the user must follow to accomplish the task. One or more <steps>
elements is required inside the <steps> section.
The <substeps> element allows you to break
a step down into a series of separate actions, and should be used only if
necessary. Try to describe the steps of a task in a single level of steps.
If you need to use more than one level of substep nesting, you should probably
rewrite the task to simplify it.
The command (<cmd>) element is required as
the first element inside a <step>. It provides the active
voice instruction to the user for completing the step, and should not be more
than one sentence. If the step needs additional explanation, this can follow
the <cmd> element inside an info element.
The information element (<info>) occurs inside
a <step> element to provide additional information about
the step.
The tutorial info (<tutorialinfo>) element
contains information that is included in a step when a task is part of a tutorial.
The <tutorialinfo> element allows you to turn a task
into a learning exercise by including explanatory content about methods for
completing the current step. This information is currently included in all
output processing results, not just tutorials. It is not for use in tasks
that are being used outside of tutorials.
The step example (<stepxmp>) element is used
to illustrate a step of a task. The example can be a couple of words, or an
entire paragraph.
The <stepresult> element provides information
on the expected outcome of a step. If a user interface is being documented,
the outcome could describe a dialog box opening, or the appearance of a progress
indicator. Step results are useful to assure a user that they are on track,
but should not be used for every step, as this quickly becomes tedious.
The <choicetable> element contains a series
of optional choices available within a step of a task.
The <chhead> element is a container inside
the <choicetable> element that provides specific heading
text to override the default Options and Description headings.
The <chhead> element contains both a choptionhd and chdeschd element as a pair.
The <chrow> element is a container inside
the <choicetable> element. The <chrow>
element contains both a <choption> and <chdesc>
element as a pair.
The <choptionhd> element provides a specific
label for the list of options that a user chooses from to accomplish a step.
The default label for options is Option.
The <chdeschd> option provides a specific
label for the list of descriptions of options that a user must choose to accomplish
a step of a task. The default label overridden by <chdeschd>
is Description.
The <choption> element describes an option
that a user could choose to accomplish a step of a task. In a user interface,
for example, this might be the name of radio button.
The <chdesc> element is a description of
an option that a user chooses while performing a step to accomplish a task.
It explains why the user would choose that option, and might explain the result
of the choice when it is not immediately obvious.
dita-ot-1.5.3/demo/dita11/schema/tblDeclGrp.xsd 0000664 0000000 0000000 00000006270 11671002146 0021075 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/schema/tblDeclMod.xsd 0000664 0000000 0000000 00000031542 11671002146 0021064 0 ustar 00root root 0000000 0000000
The <table> element organizes arbitrarily
complex relationships of tabular information. This standard table markup allows
column or row spanning and table captions or descriptions. A optional title
allowed inside the table element provides a caption to describe the table.
See simpletable for a simplified
table model that can be specialized to represent more regular relationships
of data.
The <tgroup> element in a table contains
column, row, spanning, header and footer specifications, and the body (<tbody>)
of the table.
The <colspec> element contains a column specification
for a table, including assigning a column name and number, cell content alignment,
and column width.
The table header (<thead>) element precedes
the table body (<tbody>) element in a complex table.
The <tbody> element contains the rows in
a table.
The <row> element contains a single row in
a table <tgroup>.
The <entry> element defines a single cell
in a table.
dita-ot-1.5.3/demo/dita11/schema/topic.xsd 0000664 0000000 0000000 00000011572 11671002146 0020172 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/schema/topicGrp.xsd 0000664 0000000 0000000 00000007506 11671002146 0020645 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita11/schema/topicMod.xsd 0000664 0000000 0000000 00000067610 11671002146 0020636 0 ustar 00root root 0000000 0000000
Relational attributes (<%rel-atts;>) is a
parameter entity declaration in the topic DTD that includes attributes whose
values may be used for representing navigational relationships. These attributes
occur only on elements that represent relationships between topics.
The <topic> element is the top-level DITA
element for a single-subject topic or article. Other top-level DITA elements
that are more content-specific are <concept>, <task>,
and <reference>.
The <no-topic-nesting> element is a placeholder
in the DITA architecture. It is not actually used by the DITA DTDs; it is
for use only when creating a customized DTD where the information designer
wants to eliminate the ability to nest topics. Not for use by authors.The alternate title element (<titlealts>)
is optional, but can occur after the topic title. Two elements can be inserted
as sub-elements of <titlealts>: navigation title <navtitle>
and search title <searchtitle>. When your DITA topic
is transformed to XHTML, the <searchtitle> element is
used to create a title element at the top of the resulting XHTML file. This
title may differ from the first level heading that shows in the main browser
window. In HTML output, the <navtitle> may be used to
create navigation panels when your DITA topics are part of an HTML-based help
or information system. The design intent is to enable navigation for HTML
Help and Eclipse help systems.
The navigation title (<navtitle>) element
is one of a set of alternate titles that can be included inside the <titlealts>
element. This navigation title may differ from the first level heading that
shows in the main browser window. Use <navtitle> when
the actual title of the topic isn't appropriate for use in navigation panes
or online contents (for example, because the actual title is too long or needs
stated in terse, imperative voice in the navigation).
When your DITA topic is transformed to XHTML, the <searchtitle>
element is used to create a title element at the top of the resulting HTML
file. This title is normally used in search result summaries by some search
engines, such as that in Eclipse (http://eclipse.org); if not set, the XHTML's
title element defaults to the source topic's title content (which may not
be as well optimized for search summaries)
The short description (<shortdesc>) element
occurs between the topic title and the topic body, as the initial paragraph-like
content of a topic. The short description, which represents the purpose or
theme of the topic, is also intended to be used as a link preview and for
searching.
The <body> element is the container for the
main content of a <topic>.
The <section> element represents an organizational
division in a topic. Sections are used to organize subsets of information
that are directly related to the topic. For example, the titles Reference
Syntax, Example and Properties might represent section-level
discourse within a topic about a command-line process—the content in each
section relates uniquely to the subject of that topic. Multiple sections within
a single topic do not represent a hierarchy, but rather peer divisions of
that topic. Sections cannot be nested. A section may have an optional title.
The <example> element is a section with the
specific role of containing examples that illustrate or support the current
topic. The <example> element has the same content model
as <section>.
The <prolog> element contains information
about the topic as an whole (for example, author information or subject category)
that is either entered by the author or machine-maintained. Much of the metadata
inside the <prolog> will not be displayed with the topic
on output, but may be used by processes that generate search indexes or customize
navigation.
The <metadata> section of the prolog contains
information about a topic such as audience and product information. Metadata
can be used by computational processes to select particular topics or to prepare
search indexes or to customize navigation.
The related information links of a topic (<related-links>
element) are stored in a special section following the body of the topic.
After a topic is processed into it final output form, the related links are
usually displayed at the end of the topic, although some Web-based help systems
might display them in a separate navigation frame.
The <linklist> element defines an author-arranged
group of links. Within <linklist>, the organization
of links on final output is in the same order as originally authored in the
DITA topic file.
The <linkinfo> element allows you to place
a descriptive paragraph following a list of links in a linklist element.
The <linkpool> element defines a group of
links that have common characteristics, such as type or audience or source.
Within <linkpool>, the organization of links on final
output is determined by the output process, not by the order that the links
actually occur in the DITA topic file.
The <linktext> element provides the literal
label or line of text for a link. In most cases, the text of a link can be
resolved during processing by cross reference with the target resource. Use
the <linktext> element only when the target cannot be
reached, such as when it is a peer or external link.
The <link> element defines a relationship
to another topic. Links represent the types and roles of topics in a web of
information, and therefore represent navigational links within that web. The
parent structures of link allow authors to define named groups and even sort
orders that can be applied to sets of links.
dita-ot-1.5.3/demo/dita11/schema/uiDomain.xsd 0000664 0000000 0000000 00000022252 11671002146 0020616 0 ustar 00root root 0000000 0000000
The user interface control (<uicontrol>) element represents
a button, entry field, menu item, or other object that allows the user to
control the interface. This could also include a menu or dialog. For example,
use the <uicontrol> element inside a <menucascade> element
when the menu item is nested, such as FileNew. This element is part
of the DITA user interface domain, a special set of DITA elements designed
to document user interface tasks, concepts and reference information.
The <shortcut> element identifies
a keyboard shortcut for a menu or window action. This element is part of the
DITA user interface domain, a special set of DITA elements designed to document
user interface tasks, concepts and reference information.
The window title <wintitle> element represents the title
text that appears at the top of a window or dialog, and applies to wizard
titles, wizard page titles, and pane titles. This element is part of the DITA
user interface domain, a special set of DITA elements designed to document
user interface tasks, concepts and reference information.
The <menucascade> element is used to document
a series of menu choices, or to show any choice on a menu from which the user
needs to choose. The <menucascade> element contains
one or more user interface control (<uicontrol>) elements,
for example: Start > Programs > Accessories > Notepad. If
there is more than one <uicontrol> element, the formatter
may show connecting characters between the menu items to represent the menu
cascade. This element is part of the DITA user interface domain, a special
set of DITA elements designed to document user interface tasks, concepts and
reference information.
The <screen> element contains or refers to a textual representation
of a computer screen or user interface panel (window).
dita-ot-1.5.3/demo/dita11/schema/utilitiesDomain.xsd 0000664 0000000 0000000 00000013615 11671002146 0022217 0 ustar 00root root 0000000 0000000
The imagemap element supports the basic functionality of the HTML client-side image map markup.
The area element supports the basic functionality of the HTML image map markup.
The shape element supports the basic functionality of the HTML client-side image map markup.
The coords element supports the basic functionality of the HTML client-side image map markup.
dita-ot-1.5.3/demo/dita11/schema/xml.xsd 0000664 0000000 0000000 00000006126 11671002146 0017653 0 ustar 00root root 0000000 0000000
See http://www.w3.org/XML/1998/namespace.html and
http://www.w3.org/TR/REC-xml for information about this namespace.
This schema defines attributes and an attribute group
suitable for use by
schemas wishing to allow xml:base, xml:lang or xml:space attributes
on elements they define.
To enable this, such a schema must import this schema
for the XML namespace, e.g. as follows:
<schema . . .>
. . .
<import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>
Subsequently, qualified reference to any of the attributes
or the group defined below will have the desired effect, e.g.
<type . . .>
. . .
<attributeGroup ref="xml:specialAttrs"/>
will define a type which will schema-validate an instance
element with any of those attributesIn keeping with the XML Schema WG's standard versioning
policy, this schema document will persist at
http://www.w3.org/2001/03/xml.xsd.
At the date of issue it can also be found at
http://www.w3.org/2001/xml.xsd.
The schema document at that URI may however change in the future,
in order to remain compatible with the latest version of XML Schema
itself. In other words, if the XML Schema namespace changes, the version
of this document at
http://www.w3.org/2001/xml.xsd will change
accordingly; the version at
http://www.w3.org/2001/03/xml.xsd will not change.
In due course, we should install the relevant ISO 2- and 3-letter
codes as the enumerated possible values . . .See http://www.w3.org/TR/xmlbase/ for
information about this attribute.
dita-ot-1.5.3/demo/dita11/schema/xnalDomain.xsd 0000664 0000000 0000000 00000074144 11671002146 0021152 0 ustar 00root root 0000000 0000000
The <authorinformation> element contains detailed information
about the author or authoring organization. The <addressdetails> element contains information about the
address of the author or authoring group.The <administrativearea> element contains information about
a county, state, or province. A <contactnumber> element contains a telephone number. The <contactnumbers> element contains a list of telephone and
fax numbers. The <country> element contains the name of a country. The <emailaddress> element contains an e-mail address. The <emailaddress> element contains a list of e-mail addresses. The <firstname> element contains the person's first name. The <generationidentifier> element contains information about
the person's generation, such as: Jr, III, or VIII.The <honorific> element contains the person's title, such as:
Dr., Mr., Ms., HRH.. or Grand Exalted Wizard. The <lastname> element contains the person's last name. The <locality> element contains information about the city and
postal or ZIP code. It can contain the information directly, or by acting
as a wrapper for <localityname> and <postalcode>. The <localityname> element contains the name of the locality
or city.The <middlename> element contains the person's middle name or
initial. The <namedetails> element contains information about the name
of the author or the authoring organization. The <organizationinfo> element contains detailed information
about an authoring organization. The <organizationname> element contains name information about
the authoring organization. The <organizationnamedetails> element contains information about
the name of an authoring organization. The <otherinfo> element contains other name information about
the author or authoring organization. The <personinfo> element is a wrapper containing all relevant
data about a person, including name, address, and contact information.The <personname> element contains name information about the
author.The <postalcode> element contains information about the postal
code or the ZIP code.The <thoroughfare> element contains information about the thoroughfare
- for example, the street, avenue, or boulevard - on which an address is located.The <url> element contains a Uniform Resource Locator (URL). The <urls> element contains a list of Uniform Resource Locators
(URLs). dita-ot-1.5.3/demo/dita132/ 0000775 0000000 0000000 00000000000 11671002146 0015152 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/dita132/catalog.xml 0000664 0000000 0000000 00000005715 11671002146 0017316 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/dtd/ 0000775 0000000 0000000 00000000000 11671002146 0015725 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/dita132/dtd/concept.dtd 0000664 0000000 0000000 00000006047 11671002146 0020064 0 ustar 00root root 0000000 0000000
%ui-d-dec;
%hi-d-dec;
%pr-d-dec;
%sw-d-dec;
%ut-d-dec;
%topic-type;
%concept-typemod;
%ui-d-def;
%hi-d-def;
%pr-d-def;
%sw-d-def;
%ut-d-def;
dita-ot-1.5.3/demo/dita132/dtd/concept.mod 0000664 0000000 0000000 00000004400 11671002146 0020057 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/dtd/ditabase.dtd 0000664 0000000 0000000 00000007126 11671002146 0020204 0 ustar 00root root 0000000 0000000
%ui-d-dec;
%hi-d-dec;
%pr-d-dec;
%sw-d-dec;
%ut-d-dec;
%topic-type;
%concept-typemod;
%task-typemod;
%reference-typemod;
%ui-d-def;
%hi-d-def;
%pr-d-def;
%sw-d-def;
%ut-d-def;
dita-ot-1.5.3/demo/dita132/dtd/highlight-domain.ent 0000664 0000000 0000000 00000001655 11671002146 0021660 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/dtd/highlight-domain.mod 0000664 0000000 0000000 00000004430 11671002146 0021643 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/dtd/map.dtd 0000664 0000000 0000000 00000003040 11671002146 0017174 0 ustar 00root root 0000000 0000000
%mapgroup-d-dec;
%map-type;
%mapgroup-d-def;
dita-ot-1.5.3/demo/dita132/dtd/map.mod 0000664 0000000 0000000 00000020623 11671002146 0017206 0 ustar 00root root 0000000 0000000
%metaXML;
dita-ot-1.5.3/demo/dita132/dtd/mapgroup.ent 0000664 0000000 0000000 00000001655 11671002146 0020276 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/dtd/mapgroup.mod 0000664 0000000 0000000 00000002773 11671002146 0020271 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/dtd/meta_xml.mod 0000664 0000000 0000000 00000016266 11671002146 0020247 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/dtd/programming-domain.ent 0000664 0000000 0000000 00000002103 11671002146 0022220 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/dtd/programming-domain.mod 0000664 0000000 0000000 00000024752 11671002146 0022227 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/dtd/reference.dtd 0000664 0000000 0000000 00000006152 11671002146 0020364 0 ustar 00root root 0000000 0000000
%ui-d-dec;
%hi-d-dec;
%pr-d-dec;
%sw-d-dec;
%ut-d-dec;
%topic-type;
%reference-typemod;
%ui-d-def;
%hi-d-def;
%pr-d-def;
%sw-d-def;
%ut-d-def;
dita-ot-1.5.3/demo/dita132/dtd/reference.mod 0000664 0000000 0000000 00000013254 11671002146 0020371 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/dtd/software-domain.ent 0000664 0000000 0000000 00000002025 11671002146 0021533 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/dtd/software-domain.mod 0000664 0000000 0000000 00000006621 11671002146 0021532 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/dtd/task.dtd 0000664 0000000 0000000 00000006100 11671002146 0017361 0 ustar 00root root 0000000 0000000
%ui-d-dec;
%hi-d-dec;
%pr-d-dec;
%sw-d-dec;
%ut-d-dec;
%topic-type;
%task-typemod;
%ui-d-def;
%hi-d-def;
%pr-d-def;
%sw-d-def;
%ut-d-def;
dita-ot-1.5.3/demo/dita132/dtd/task.mod 0000664 0000000 0000000 00000023254 11671002146 0017376 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/dtd/tbl_xml.mod 0000664 0000000 0000000 00000013570 11671002146 0020075 0 ustar 00root root 0000000 0000000
]]>
dita-ot-1.5.3/demo/dita132/dtd/topic.dtd 0000664 0000000 0000000 00000005675 11671002146 0017555 0 ustar 00root root 0000000 0000000
%ui-d-dec;
%hi-d-dec;
%pr-d-dec;
%sw-d-dec;
%ut-d-dec;
%topic-type;
%ui-d-def;
%hi-d-def;
%pr-d-def;
%sw-d-def;
%ut-d-def;
dita-ot-1.5.3/demo/dita132/dtd/topic.mod 0000664 0000000 0000000 00000062305 11671002146 0017552 0 ustar 00root root 0000000 0000000
%topicDefns;
%tableXML;
%metaXML;
%topicClasses;
dita-ot-1.5.3/demo/dita132/dtd/topic_class.ent 0000664 0000000 0000000 00000011116 11671002146 0020740 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/dtd/topic_defn.ent 0000664 0000000 0000000 00000007074 11671002146 0020557 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/dtd/ui-domain.ent 0000664 0000000 0000000 00000001755 11671002146 0020327 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/dtd/ui-domain.mod 0000664 0000000 0000000 00000005257 11671002146 0020321 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/dtd/utilities-domain.ent 0000664 0000000 0000000 00000001651 11671002146 0021720 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/dtd/utilities-domain.mod 0000664 0000000 0000000 00000006142 11671002146 0021711 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/plugin.xml 0000664 0000000 0000000 00000000416 11671002146 0017173 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/schema/ 0000775 0000000 0000000 00000000000 11671002146 0016412 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/dita132/schema/concept.grp 0000664 0000000 0000000 00000000535 11671002146 0020562 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/schema/concept.mod 0000664 0000000 0000000 00000005515 11671002146 0020554 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/schema/concept.xsd 0000664 0000000 0000000 00000004160 11671002146 0020566 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/schema/ditabase.xsd 0000664 0000000 0000000 00000007562 11671002146 0020720 0 ustar 00root root 0000000 0000000
This element allows you to combine several articles into a single
XML file. You can mix the article types after the DITA element. For example,
you can start with an introductory topic, continue with concept and task information,
and conclude with reference information. You can create several peer articles
at the main level, and create heierarchies under each main article.
dita-ot-1.5.3/demo/dita132/schema/highlight-domain.mod 0000664 0000000 0000000 00000007301 11671002146 0022330 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/schema/map.grp 0000664 0000000 0000000 00000003252 11671002146 0017703 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/schema/map.mod 0000664 0000000 0000000 00000040311 11671002146 0017667 0 ustar 00root root 0000000 0000000
Select attributes is a parameter entity declaration in the topic DTD that includes
attributes whose values may be used for affecting the display of a topic or its
selection by search tools.ID attributes is a parameter entity declaration in the topic DTD that includes
attributes whose values may be used for conditional processing or for selection by
search tools.Universal attributes is a parameter entity declaration in the topic DTD that
includes all of the attributes in the select-atts and id-atts attribute groups. dita-ot-1.5.3/demo/dita132/schema/map.xsd 0000664 0000000 0000000 00000001517 11671002146 0017713 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/schema/mapgroup.mod 0000664 0000000 0000000 00000005113 11671002146 0020745 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/schema/meta_xml.grp 0000664 0000000 0000000 00000003124 11671002146 0020732 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/schema/meta_xml.mod 0000664 0000000 0000000 00000046123 11671002146 0020727 0 ustar 00root root 0000000 0000000
This metadata element can contain the name and address of the topic's
author, or it can be left empty and point to another location where the author
is defined.This element contains a reference to a resource from which the present
topic is derived, either completely or in part. The reference can be a string
or a cross-reference.This metadata element contains the name of the person, company,
or organization responsible for making the resource available.This is the container element for a single copyright entry. It includes
the copyright years and the copyright holder. Multiple <copyright> statements
are allowed.This empty element contains the copyright date or dates as specified
by the year attribute. This element indicates the ownership of the information contained
in the topic.This element contains the critical dates in a document life cycle,
such as the creation, revision, and publication dates.This empty prolog element contains tracking dates that are important
in a topic development cycle.This empty element specifies the document creation date using the
date attribute. More Information to be addedThis empty metadata element indicates the intended audience for a
topic using its type attribute. Since a topic can have multiple audiences,
you can include multiple audience elements. For each audience you specify,
you can identify the high-level task they are trying to accomplish (job) and
the level of experience expected.This element can represent any category by which a topic might
be classified for retrieval or navigation; for example, the categories could
be used to group topics in a generated navigation bar. Topics can belong to
multiple categories.An index entry. You can nest entries to create multi-level indexes.This element contains a list of keywords, separated by commas, that
can be used by a search engine.Identifies a key word of some sort. Can be used in specialized topic
types as a base for particular kinds of keywords, which can then be processed
in particular ways (formatted differently, automatically indexed, etc.). If
the keyref attribute is used, the keyword may be turned into a hyperlink on
output.This element can be used to identify properties not otherwise included
in <metadata> and assign property/pair values to those properties. The
name attribute identifies the property and the content attribute specifies
the property's value.This empty prolog element can indicate any preferred controls for
access to a topic. Permissions can be used as viewing filters. Standard DITA
processing does not use this element.This metadata element in the prolog contains information about the
product or products that are the subject matter of the current topic.This element indicates the manufacturer or brand associated with
the current product.This metadata element contains information about the product series
that the topic supports.This metadata element contains a description of the operating system
and hardware that comprise a platform.This metadata element identifies the program number of the associated
program product. This is typically an order number or a product tracking
code that could be replaced by an order number when a product completes development.This element contains the feature number of a product in the document
metadata.This element is used to identify a piece of documentation or of a
product which is associated with the current topic. For example, a product
might be made up of many components, each of which is installable separately.
Components might also be shared by several products so that the same component
could be available for installation with many products. This identification
could be used to check cross-component dependencies when some components are
installed and not others. http://www.w3.org/TR/REC-html40/struct/objects.htmlThis metadata element contains the names of the products that are
supported by the information in this topic.This is the container for a list (<vrm>) containing the version,
release, and.modification information for multiple products or versions of
products to which the topic applies.This empty element contains information about a single product's
version,.modification, and release, to which the current topic applies.
dita-ot-1.5.3/demo/dita132/schema/programming-domain.mod 0000664 0000000 0000000 00000046226 11671002146 0022714 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/schema/reference.grp 0000664 0000000 0000000 00000003071 11671002146 0021063 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/schema/reference.mod 0000664 0000000 0000000 00000020212 11671002146 0021046 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/schema/reference.xsd 0000664 0000000 0000000 00000004173 11671002146 0021075 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/schema/relnotes_schema.txt 0000664 0000000 0000000 00000000431 11671002146 0022324 0 ustar 00root root 0000000 0000000 This DITA release includes an implementation of the topic architecture in
XML Schema. The DTDs are still the canonical representation of DITA. The
design pattern for the DITA Schemas is based on the W3C XML Schema 1.0
Specification and may be subject to change in the future.
dita-ot-1.5.3/demo/dita132/schema/software-domain.mod 0000664 0000000 0000000 00000013214 11671002146 0022213 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/schema/task.grp 0000664 0000000 0000000 00000006037 11671002146 0020074 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/schema/task.mod 0000664 0000000 0000000 00000036712 11671002146 0020066 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/schema/task.xsd 0000664 0000000 0000000 00000004147 11671002146 0020102 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/schema/tbl_xml.grp 0000664 0000000 0000000 00000002217 11671002146 0020567 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/schema/tbl_xml.mod 0000664 0000000 0000000 00000022465 11671002146 0020565 0 ustar 00root root 0000000 0000000
The container element for CALS table elements. See <simpletable>
for a simplified table.model.The element in a <table> that contains column, row, spanning,
header and footer specifications, and the body (<tbody>) of the table.This element contains a column specification for a table, including
assigning a column name and number, cell content alignment, and column width. A span specification in a table column or row specifies how two or
more cells are to be combined.This table header element precedes the table body (<tbody>) element.
It is currently not used.This table footer element precedes the <table> body (<tbody>)
element. It is currently not used.This element contains the rows in a <table>This element contains a single row in a table <tgroup>.This element defines an entry (a single cell) in a table row.
dita-ot-1.5.3/demo/dita132/schema/topic.grp 0000664 0000000 0000000 00000016073 11671002146 0020251 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/schema/topic.mod 0000664 0000000 0000000 00000227033 11671002146 0020240 0 ustar 00root root 0000000 0000000
Display attributes is a parameter entity declaration in the topic DTD that includes
attributes whose values may be used for affecting the display of a topic or its
selection by search tools.
Relation attributes is a parameter entity declaration in the topic DTD that includes
attributes whose values may be used for conditional processing or for selection by
search tools.
ID attributes is a parameter entity declaration in the topic DTD that includes
attributes whose values may be used for conditional processing or for selection by
search tools.Select attributes is a parameter entity declaration in the topic DTD that includes
attributes whose values may be used for affecting the display of a topic or its
selection by search tools.Universal attributes is a parameter entity declaration in the topic DTD that
includes all of the attributes in the select-atts and id-atts attribute groups. Topic is the archetype from which other typed topics may be derived. Its body has completely optional content, which allows topic to be used as a titled container role: migration target for XHTML, other hierarchically structured source.
This is the top-level DITA element for a single-subject topic or article. Other top-level DITA elements that are more content-specific are <concept>, <task>, and <reference>.
This element contains a heading or label for the main parts of a document such as
<topic>, <section>, and <example> and for the exhibit elements such as figure
<fig> and <table>.
More Information to be added
More Information to be added
More Information to be added
This element contains a short description of a topic which indicates the content or
intent of the topic more completely than the title. This element does not allow
paragraphs; use <longdesc> if paragraphs are needed for a longer description. One
possible use of this element is to provide a link preview or hover-help for links to
this topic from other topics or documents.
This is the containing element for the main content of a <topic>. This element is a division in a <topic>. Use sections for organizing subsets of
information that are directly related to the topic. For example, Syntax, Usage, and
Example might all be sections within a topic about a command-line process.
Sections within a<topic> do not represent a hierarchy, but rather parallel divisions
of that <topic> so they cannot be nested. If you want to accomplish nesting (for
example, documenting options within a process each of which has its own syntax,
usage and example), do so by creating subtopics insteads. Section <title>s are
optional and should be used first in a section.
This element is a section that has the specific role of containing examples that
illustrate or support the current topic. <example> has the same content.model as
<section>.
This element contains the description of a figure, table, object, or linkgroup. A
8lt;desc> should provide more information than the title.
This could be trex, xpath, relax, xsd, etc.The prolog contains information about the whole topic (for example, author
information, subject category, and relationships to other topics) that is either
entered by the author or machine-maintained. Much of the metadata will not be
displayed with the topic on output, but may be used by processes generating
search indexes, or customizing navigation.
Links defined in the prolog are typically displayed as part of the topic on output,
but their placement in the output will be dependent on the process, and is not
directly controlled by the author.
The metadata section of the <prolog> contains information about a topic such as
audience and product information. Metadata can be used by processes to select
particular topics or to prepare search indexes or customize navigation.
This element allows multiple links to be specified in a <prolog>. At processing
time, they may be displayed elsewhere (for example, at the end of the topic). By
relegating links to the prolog, it becomes easier to reuse the content of the topic in
new collections or delivery contexts, where the related topics may not be available.
More Information to be added
More Information to be added
More Information to be added
This element defines a hyperlink to another topic (either in the same file or a
different file). If you leave the title empty, the text of the hyperlink will be derived
from the title of the target. The link placement on output will depend on the type
of the link and the logic of the output process. Often hyperlinks are displayed in a
group at the end of the topic, even though they are defined in a topics prolog.
The <ph> element logically groups a set of words or phrase-level elements, for
selection by property or formatting according to the typestyle attribute. Phrases
can define containment structures to associate one element with another, such as
associating a footnote with a specific sentence, or they can be used as a base for
specialization to create specific kinds of phrases. When specializing, do not include
the typestyle attribute: once you have identified a semantic class of information,
you should associate formatting using a stylesheet. Storing formatting instructions
in topic content limits the reusability of the information, and is only appropriate
when authoring at a base level, where there aren't enough semantic elements for a
stylesheet to operate on.
The <ph> element can also be used to associate a specific property with a specific
phrase. For example, you can associate a revision or version level with a phrase, or
identify a word as a particular type of data for special processing.
This element is also used during source migration when it is not apparent which
new elements should be used for tagging.
var & keyword defined by syntax diagramThis element identifies a term that is specific to a particular vocabulary. It may be
used to generate keyword links to a glossary, or to generate a glossary based on
terms used in a particular collection of topics.
Inline content (prhases)
More Information to be added
Use this element to express yes or no values, or true or false
values. The element itself is empty; you store the value of the element in
its state attribute. This element is primarily for specialization, where it
could be used to require a true | false choice in a particular part of the
document. For example, a specialized application program interface (API) topic
type could include an <abstractclass> element as a specialization of <boolean>,
to allow authors to specify whether the interface being documented is abstract or
concrete.This empty element can specify a name/value pair. It is primarily
intended for use by specializations, which can create specific kinds of state
elements with fixed name values and a choice of values. For example, a specialized
<accesstype> element could have a fixed name of "Access Type" (defined
in a side file for translation purposes) and enumerated values of public,
protected, and private. A paragraph is a block of text containing a single main idea. This element indicates content quoted from another source. Use <q>
for quotations that are too long for inline use. You can store a link to the
source of the quotation in the href attribute. A note contains information, differentiated from the main text, which
expands on or calls attention to a particular point. A quotation phrase indicates content quoted from another source.
This element is used inline; use <lq> for long quotations set off from
the surrounding text.This is an unordered list where the order of the list items is not
significant.An ordered list is a list of items sorted by sequence or order of
importance.An ordered list is a list of items sorted by sequence or order of
importance.A list item is a single item in an ordered <ol> or unordered <ul>
list. Numbers and alpha characters are usually output with list items in ordered
lists; bullets and dashes are usually output with list items in unordered
lists.This element allows specialization in a list item. For example,
if you want to create a new element that represents part of a list item (for
example, an "additional information" section of a task step), you can specialize
from lisection. In topic, lisection has no purpose other than to logically
group content within a list item; it has no intended display characteristics. A definition list is a list of terms and corresponding definitions.
The term (<dt>) is usually flush left. The description or definition
(<dd>) is usually either indented and on the next line, or on the same
line to the right of the term.You may also provide an optional heading
for the terms and definitions, using the <dlhead> element, which contains
header elements for those columns. The default formatting looks like a table
with a heading row.A <dlhead> contains optional headings for the term and description
columns in a definition list. <dlhead> contains a heading <dthd> for
the column of terms and an optional heading <ddhd> for the column of descriptions.
The default formatting looks like a table with a heading row.This element can contain an optional heading or title for a column
of descriptions or definitions in a definition list.This element is contained in a definition or description list head
(<dlhead>) and provides an optional heading for the column of terms in
a description list.This element contains a single entry in a definition list that includes
a term <dt> and one or more definitions or descriptions <dd> of that
term.This element contains a term in a description (definition) list.This element contains the description of a term in a description/definition
list.This block element contains images or other displays or objects along
with an optional title and description.
More Information to be added
A <pre> is a block element indicating text that has been formatted
for the screen and is rendered using a fixed-width font. All whitespace,
including multiple spaces, tabs, carriage returns and line feeds, is interpreted
literally and retained in the display. Use this element for computer listings
and program content.Lines are like paragraphs (<p>), except that line endings are
significant and are preserved.This empty element specifies a non-text object such as an image,
vector graphic, or video clip. This element includes an alternate text description
<alt> that can be read as an alternative to viewing the object itself.
Linking to a multi-media object is done by referencing the ID of the containing
element, for example, <fig>.
describe new alt element here
This element corresponds to the HTML <object> element. <object>
allows authors to include (embed) images, applets, plug-ins, ActiveX controls,
video clips, and so on in a topic for rendering after transformation to HTML.
(You can also use the <image> element for graphics.) The <object>
element can contain attributes, a description, and parametersThis empty element specifies a set of values that may be required
by an <object> at run-time. Any number of <param> elements may appear
in the content of an <object> in any order, but must be placed at the start
of the content of the enclosing <object>. This element is comparable to
the XHMTL <param> element. More information about <param> can be found
at This is a container element for a simple table used to present
information in unspanned columns and rows, when a CALS <table> is too complex.
A simple table can be labeled either across the top or down a column, or both.This element indicates the top row of a semantic table and contains
the column heads.This element specifies a row in a semantic table, like <row> in
<table>.This element in a simple table represents a table cell, like <entry>
in a <table>.This element is specifically for containing discussions that are
needed during the document review process. A reviewer can open an issue identifying
himself with the reviewer attribute. Discussion of a review comment can be
added using the <discussion> element, again with author identified using
the reviewer attribute on <discussion>. Tracking and disposition of review
comments can be handled with the <review-comment> attributes.
It is recommended that output stylesheets (other than those specifically for
review purposes) strip out remaining <draft-comment> elements prior to
publication and create a log file containing them. This element is a place-holder element for migrated elements that
cannot be appropriately tagged without writer intervention.
It is recommended
that output stylesheets other than those for review purposes strip out remaining
<required-cleanup> elements prior to publication and create a log file
containing them.
A footnote is used for indicating a source or including text that
is not appropriate for inclusion in-line. This element generates a number
by default or a character according to the callout attribute value. To refer
to the same footnote again, use a <link> with the attribute type set toA reference to an abstract index entry in a lookup table used by
the indexing process. The current index location will be added to the abstract
index entry on output. Use this element to refer to another document, book, or website that
is not part of your collection of topics. The citation can reference the document
directly (through an internal or external URL) or indirectly (through a reference
to a bibliographic entry in the same or another topic).A cross-reference is a link to another topic, a significant figure
or table in another topic, or an external web site.
dita-ot-1.5.3/demo/dita132/schema/topic.xsd 0000664 0000000 0000000 00000003706 11671002146 0020256 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/schema/topic_domains.mod 0000664 0000000 0000000 00000004607 11671002146 0021752 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/schema/ui-domain.mod 0000664 0000000 0000000 00000007641 11671002146 0021005 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/schema/utilities-domain.mod 0000664 0000000 0000000 00000007131 11671002146 0022375 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/dita132/schema/xml.xsd 0000664 0000000 0000000 00000006630 11671002146 0017737 0 ustar 00root root 0000000 0000000
See http://www.w3.org/XML/1998/namespace.html and
http://www.w3.org/TR/REC-xml for information about this namespace.
This schema defines attributes and an attribute group
suitable for use by
schemas wishing to allow xml:base, xml:lang or xml:space attributes
on elements they define.
To enable this, such a schema must import this schema
for the XML namespace, e.g. as follows:
<schema . . .>
. . .
<import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>
Subsequently, qualified reference to any of the attributes
or the group defined below will have the desired effect, e.g.
<type . . .>
. . .
<attributeGroup ref="xml:specialAttrs"/>
will define a type which will schema-validate an instance
element with any of those attributesIn keeping with the XML Schema WG's standard versioning
policy, this schema document will persist at
http://www.w3.org/2001/03/xml.xsd.
At the date of issue it can also be found at
http://www.w3.org/2001/xml.xsd.
The schema document at that URI may however change in the future,
in order to remain compatible with the latest version of XML Schema
itself. In other words, if the XML Schema namespace changes, the version
of this document at
http://www.w3.org/2001/xml.xsd will change
accordingly; the version at
http://www.w3.org/2001/03/xml.xsd will not change.
In due course, we should install the relevant ISO 2- and 3-letter
codes as the enumerated possible values . . .See http://www.w3.org/TR/xmlbase/ for
information about this attribute.
dita-ot-1.5.3/demo/eclipsemap/ 0000775 0000000 0000000 00000000000 11671002146 0016125 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/eclipsemap/catalog.xml 0000664 0000000 0000000 00000001260 11671002146 0020260 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/eclipsemap/dtd/ 0000775 0000000 0000000 00000000000 11671002146 0016700 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/eclipsemap/dtd/eclipsemap.dtd 0000664 0000000 0000000 00000010042 11671002146 0021514 0 ustar 00root root 0000000 0000000
%eclipsemap-dec;
%map-type;
%eclipsemap-type;
dita-ot-1.5.3/demo/eclipsemap/dtd/eclipsemap.mod 0000664 0000000 0000000 00000000642 11671002146 0021525 0 ustar 00root root 0000000 0000000
%eclipsemap-type; dita-ot-1.5.3/demo/eclipsemap/dtd/plugin.ent 0000664 0000000 0000000 00000004567 11671002146 0020722 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/eclipsemap/dtd/plugin.mod 0000664 0000000 0000000 00000054656 11671002146 0020717 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/eclipsemap/plugin.xml 0000664 0000000 0000000 00000001632 11671002146 0020147 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/eclipsemap/sample/ 0000775 0000000 0000000 00000000000 11671002146 0017406 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/eclipsemap/sample/compA/ 0000775 0000000 0000000 00000000000 11671002146 0020445 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/eclipsemap/sample/compA/aboutA.dita 0000664 0000000 0000000 00000000577 11671002146 0022534 0 ustar 00root root 0000000 0000000
All about AThis tells you all about component A
It's a component.
dita-ot-1.5.3/demo/eclipsemap/sample/compA/installA.dita 0000664 0000000 0000000 00000000627 11671002146 0023064 0 ustar 00root root 0000000 0000000
Installing component AThis teaches you how to install Ahere's some context
dita-ot-1.5.3/demo/eclipsemap/sample/compA/useA.dita 0000664 0000000 0000000 00000000644 11671002146 0022211 0 ustar 00root root 0000000 0000000
Using AThis tells you how to use AOpenRun
dita-ot-1.5.3/demo/eclipsemap/sample/compB/ 0000775 0000000 0000000 00000000000 11671002146 0020446 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/eclipsemap/sample/compB/aboutB.dita 0000664 0000000 0000000 00000000562 11671002146 0022530 0 ustar 00root root 0000000 0000000
All about BThis describes the B component
about.html
dita-ot-1.5.3/demo/eclipsemap/sample/compB/installB.dita 0000664 0000000 0000000 00000000630 11671002146 0023060 0 ustar 00root root 0000000 0000000
Installing BBBBThis tells how to install Bsetup.exe
dita-ot-1.5.3/demo/eclipsemap/sample/compB/useB.dita 0000664 0000000 0000000 00000000633 11671002146 0022211 0 ustar 00root root 0000000 0000000
B RunningThis tells how to run with the B componentrun.exe
dita-ot-1.5.3/demo/eclipsemap/sample/componentA.ditamap 0000664 0000000 0000000 00000001276 11671002146 0023060 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/eclipsemap/sample/componentB.ditamap 0000664 0000000 0000000 00000001176 11671002146 0023060 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/eclipsemap/sample/comprels.ditamap 0000664 0000000 0000000 00000001571 11671002146 0022577 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/eclipsemap/sample/eclipse.ditamap 0000664 0000000 0000000 00000003023 11671002146 0022371 0 ustar 00root root 0000000 0000000
IBMMy Component system
dita-ot-1.5.3/demo/eclipsemap/script.xml 0000664 0000000 0000000 00000000563 11671002146 0020157 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/eclipsemap/xsl/ 0000775 0000000 0000000 00000000000 11671002146 0016733 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/eclipsemap/xsl/map2plugin.xsl 0000664 0000000 0000000 00000075454 11671002146 0021560 0 ustar 00root root 0000000 0000000
DOTX.xml.xml.xml.xmlorg.eclipse.core.runtime.productshelpProduct%productName%nameManifest-Version: 1.0Bundle-ManifestVersion: 2Bundle-Localization: pluginBundle-Name: %nameBundle-Vendor: %providerNameEclipse-LazyStart: trueBundle-SymbolicName: ; singleton:=trueBundle-SymbolicName: org.sample.help.doc; singleton:=true050WFragment-Host: ;Bundle-SymbolicName: Bundle-SymbolicName: org.sample.help.docFragment-Host: org.sample.help.doc..;;lang; 050W: bundle-version=""Bundle-Version: 0.0..0..Require-Bundle: , "; bundle-version="[(, ], )# NLS_MESSAGEFORMAT_NONE# NLS_ENCODING=UTF-8name=providerName=productName==
dita-ot-1.5.3/demo/eclipsemap/xsl/maplink-plugin.xsl 0000664 0000000 0000000 00000002246 11671002146 0022416 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/eclipsemap/xsl/mappull-plugin.xsl 0000664 0000000 0000000 00000005252 11671002146 0022435 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/eclipsemap/xsl/mapref-plugin.xsl 0000664 0000000 0000000 00000005252 11671002146 0022235 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/elementref/ 0000775 0000000 0000000 00000000000 11671002146 0016131 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/elementref/README_ELEMENTREF.txt 0000664 0000000 0000000 00000006730 11671002146 0021343 0 ustar 00root root 0000000 0000000 ##
ELEMENTREF EXAMPLE
This example gives a demonstration of topic specialization by
defining a simple elementref topic.
The purpose of the elementref topic is to model a reference description
of an XML element and its attributes. The elementref topic uses a
specialization of the simpletable element to model the attribute list so
multiple attributes or element properties can be described for each
elementref element.
The example includes the DTD module, an XSL module for generating HTML
output, and a sample data file.
Drop the demo source file map.xml or topicref.xml onto a Mozilla-class
browser to see the effect of CSS styling on literally rendered DITA XML
elements. Drag/drop the demo file onto IE6 to see the effect of a DITA
XML topic rendered by XSLT directly in the browser.
CAVEAT
The elementref example is provided only as an example of topic specialization
and not as a standard topic type within the DITA architecture. Other
design approaches are possible.
For instance, you could model semantically-important phrases like
topic and class by deriving them from
apiname, which itself derives from keyword. A "markup domain" is under
consideration but has not been defined yet. Your ideas are welcome!
elementref EXAMPLE FILES
This directory contains the elementref examples, including:
topicref.xml, map.xml, commonlrdefs.xml
- sample data source files
topicref.html, map.html
- sample data output files
elementref.mod
- topic module to define the elementref information type
elementref_shell.dtd
- shell DTD to merge base and elementref information types
elementref.css
- convenience CSS for styling elementref elements (for instance, in
editors such as XMetaL)
elementref_shell.css
- convenience shell CSS to merge base and elementref styles
elementref2html.xsl
- XSL module to format the elementref deltas as HTML
elementref2html_shell.xsl
- shell XSL to merge base and elementref formatting
elementref2fo.xsl
- XSL module to format the elementref deltas as XSL-FO
elementref2fo_shell.xsl
- shell XSL to merge base and elementref formatting
elementref_strings.xml
- example internationalization file
GENERATING OUTPUT FROM THE EXAMPLE
To generate HTML output, you need to install an XSLT processor.
There are many options for XSLT processor. For one example, you can
install a Java„1¤7 runtime (JRE) and an XSLT processor such as Saxon.
JRE
- Get a JRE (or a JDK bundling a JRE) such as the Sun J2SE plaform:
http://java.sun.com/j2se/downloads.html
Java„1¤7 comes with an install program.
Saxon
- http://saxon.sourceforge.net/
To install Saxon, you unzip the package and add the saxon.jar
file to the CLASSPATH environment variable.
Using Saxon, you can generate HTML or XSL formatting objects from the sample data with
java com.icl.saxon.StyleSheet -o topicref.html topicref.xml elementref2html_shell.xsl
java com.icl.saxon.StyleSheet -o topicref.fo topicref.xml elementref2fo_shell.xsl
FEEDBACK
If you run into problems or want to discuss this example, please feel
free to ask questions on the DITA forum:
news://news.software.ibm.com:119/ibm.software.developerworks.xml.dita
Have fun exploring,
The DITA Team
Java is a registered trademark of Sun Microsystems, Inc.. dita-ot-1.5.3/demo/elementref/catalog.xml 0000664 0000000 0000000 00000001011 11671002146 0020256 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/elementref/commonLRdefs.xml 0000664 0000000 0000000 00000010772 11671002146 0021252 0 ustar 00root root 0000000 0000000
Common content for Language Reference
This topic documents the common definitions for attributes that
appear within the DITA DTDs, and provides the content for reuse within the
individual element descriptions of the DITA Language Reference.
classNot for use by authors. If an editor displays class attribute
values, do not edit them. The class attribute supports specialization.
Its predefined values help the output transforms work correctly with ranges
of related content.CDATA#IMPLIEDhrefA hyperlink to an external Web page (URL) or to another topic in
the same file or in another file. The href attribute identifies the destination
of the cross-reference link using conventional URL syntax:
href="http://www.xxx.com" format="html"
href="myfile.dita" type="concept"
(or task, reference, or topic)
href="myfile.dita#topicid/figid" type="fig"
(or table, fn, or section)
href="mything.pdf" format="pdf"
CDATA#IMPLIEDidAn anchor point. This ID is the target for references by link, xref,
and conref, and for external applications that refer to DITA content..ID#IMPLIEDidThis attribute is only used for debugging purposes to tell where
generated links came from.ID#IMPLIEDnavtitleSpecifies the title of a container in a toc.CDATA#IMPLIEDtitleAn identifying title for this element.CDATA#IMPLIEDtypeDescribes the target of a cross-reference and may generate cross-reference
text based on that description.
Allowed values are:
fig
Indicates a link to a figure.
table
Indicates a link to a table.
li
Indicates a link to an ordered list item.
fn
Indicates a link to a footnote.
section
"section" indicates a link to a section.
concept, task, reference, topic
Cross-reference to a topic type.
other
Indicates a cross-reference to an alternate topic information type (currently
unsupported).
Valid types for <link> include
topic, concept, task, and reference. Valid types for <xref>
also include fig, figgroup, table, li, fn, and section.The values external and local are
deprecated for this attribute, and will be removed in later versions of the
DTDs. Use the scope attribute instead to specify
these linking semantics.CDATA#IMPLIED (Processed as if the target were of type topic.)
dita-ot-1.5.3/demo/elementref/elementref-xs.mod 0000664 0000000 0000000 00000033442 11671002146 0021416 0 ustar 00root root 0000000 0000000
The element "element" can be substituted wherever the element "term" is used (global).
No abstraction of this is needed.
dita-ot-1.5.3/demo/elementref/elementref.css 0000664 0000000 0000000 00000004006 11671002146 0020771 0 ustar 00root root 0000000 0000000 /*
| (c) Copyright IBM Corp. 2004, 2005 All Rights Reserved.
*/
elementref {
display: block;
margin-top: 6pt;
margin-bottom: 9pt;
font-family: sans-serif;
padding-left: 5px;
padding-right: 5px;
}
elementname {
display: block;
margin-top: 16pt;
margin-bottom: 9pt;
font-size: 20pt;
font-weight: bold;
color: #000000;
}
elementdesc {
display: block;
margin-left: 12pt;
}
/* general setup for section-like divisions and exhibits */
purpose, containedby, contains, attributes, examples, syntax {
margin-bottom: 12pt;
display: block;
}
purpose:before {
display: block;
font-weight: bold;
content: "Purpose: ";
}
containedby:before {
display: block;
font-weight: bold;
content: "Contained by: ";
}
contains:before {
display: block;
font-weight: bold;
content: "Contains: ";
}
examples:before {
display: block;
font-weight: bold;
content: "Examples: ";
}
syntax:before {
display: block;
font-weight: bold;
content: "Syntax: ";
}
attributes:before {
display: block;
font-weight: bold;
content: "Attributes: Name - Description - Data type - Default value - Required?(y/n)";
}
attlist {
display: table;
}
attribute {
display: table-row;
}
attname {
display: table-cell;
border: thin inset gray;
}
attdesc {
display: table-cell;
border: thin inset gray;
}
attdefvalue {
display: table-cell;
border: thin inset gray;
}
attrequired {
display: table-cell;
border: thin inset gray;
}
atttype {
display: table-cell;
border: thin inset gray;
}
boolean[state="yes"]:before {
display: inline;
font-weight: bold;
content: "Yes";
}
boolean[state="no"]:before {
display: inline;
content: "No";
}
boolean[state="NA"]:before {
display: inline;
content: "Not Applicable";
}
state:before {
color: red;
content: attr(value);
}
comment {
font-style: italic;
}
xref[href] {
/* link: target(href);*/
}
dita-ot-1.5.3/demo/elementref/elementref.mod 0000664 0000000 0000000 00000014361 11671002146 0020765 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/elementref/elementref2fo.xsl 0000664 0000000 0000000 00000020640 11671002146 0021420 0 ustar 00root root 0000000 0000000
(){arrived at h1 heading context FOR STANDALONE TOPICS!}NoYes123
dita-ot-1.5.3/demo/elementref/elementref2fo_shell.xsl 0000664 0000000 0000000 00000001624 11671002146 0022610 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/elementref/elementref2html.xsl 0000664 0000000 0000000 00000013045 11671002146 0021761 0 ustar 00root root 0000000 0000000
()
The <map> element is used to define a map which
describes the relationships among a set of DITA topics. Maps consist of references
to topics organized into hierarchies. Maps provide a way to
express these relationships in a single common format that can be used for
different outputs, such as to aggregate related topics for a single print
job.
The containing element for a map is the <map>
element, which can take title and id attributes. Within the map, use the <topicref>
element to add and organize references to the topics.
Contained by
This is the root element for mapping applications.
This attribute is only used for debugging purposes to tell where
generated links came from.
ID
#IMPLIED
boolean: no
class
Not for use by authors. If an editor displays class attribute
values, do not edit them. The class attribute supports specialization.
Its predefined values help the output transforms work correctly with ranges
of related content.
CDATA
#IMPLIED
boolean: no
Example
In this example, there are six topicrefs. They are nested and have
a hierarchical relationship. Bats.xml is the parent topic and the other topics
are its children.
dita-ot-1.5.3/demo/elementref/map.xml 0000664 0000000 0000000 00000004750 11671002146 0017436 0 ustar 00root root 0000000 0000000
mapThe <map> element is used to define a map which
describes the relationships among a set of DITA topics. Maps consist of references
to topics organized into hierarchies. Maps provide a way to
express these relationships in a single common format that can be used for
different outputs, such as to aggregate related topics for a single print
job.
The containing element for a map is the <map>
element, which can take title and id attributes. Within the map, use the <topicref>
element to add and organize references to the topics.
mapMap
elementsmapThis is the root element for mapping applications.topicref (0 or more) In this example, there are six topicrefs. They are nested and have
a hierarchical relationship. Bats.xml is the parent topic and the other topics
are its children.<map title="Bats" id="mybats"> Bats
<topicref href="bats.xml" type="topic"
<topicref href="batcaring.xml" type="task"></topicref>
<topicref href="batfeeding.xml" type="task"></topicref>
<topicref href="batsonar.xml" type="concept"></topicref>
<topicref href="batguano.xml" type="reference"></topicref>
<topicref href="bathistory.xml" type="reference"></topicref>
</topicref>
</map>
dita-ot-1.5.3/demo/elementref/plugin.xml 0000664 0000000 0000000 00000000612 11671002146 0020150 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/elementref/topicref.html 0000664 0000000 0000000 00000013561 11671002146 0020640 0 ustar 00root root 0000000 0000000
topicref
topicref
Purpose
The <topicref> element designates a topic (such
as a concept, task, or reference) as a link in a DITA map. A <topicref>
can contain other<topicref> elements, allowing you to
express navigation or table-of-contents hierarchies.
An anchor point. This ID is the target for references by link, xref,
and conref, and for external applications that refer to DITA content..
ID
#IMPLIED
boolean: no
href
A hyperlink to an external Web page (URL) or to another topic in
the same file or in another file. The href attribute identifies the destination
of the cross-reference link using conventional URL syntax:
href="http://www.xxx.com" format="html"
href="myfile.dita" type="concept"
(or task, reference, or topic)
href="myfile.dita#topicid/figid" type="fig"
(or table, fn, or section)
href="mything.pdf" format="pdf"
CDATA
#IMPLIED
boolean: no
type
Describes the target of a cross-reference and may generate cross-reference
text based on that description.
Allowed values are:
fig
Indicates a link to a figure.
table
Indicates a link to a table.
li
Indicates a link to an ordered list item.
fn
Indicates a link to a footnote.
section
"section" indicates a link to a section.
concept, task, reference, topic
Cross-reference to a topic type.
other
Indicates a cross-reference to an alternate topic information type (currently
unsupported).
Note: Valid types for <link> include
topic, concept, task, and reference. Valid types for <xref>
also include fig, figgroup, table, li, fn, and section.
Note: The values external and local are
deprecated for this attribute, and will be removed in later versions of the
DTDs. Use the scope attribute instead to specify
these linking semantics.
CDATA
#IMPLIED (Processed as if the target were of type "topic.")
boolean: no
class
Not for use by authors. If an editor displays class attribute
values, do not edit them. The class attribute supports specialization.
Its predefined values help the output transforms work correctly with ranges
of related content.
CDATA
#IMPLIED
boolean: no
Example
In this example, there are six topicrefs. They are nested and have
a hierarchical relationship. Bats.xml is the parent topic and the other topics
are its children.
dita-ot-1.5.3/demo/elementref/topicref.xml 0000664 0000000 0000000 00000005165 11671002146 0020475 0 ustar 00root root 0000000 0000000
topicrefThe <topicref> element designates a topic (such
as a concept, task, or reference) as a link in a DITA map. A <topicref>
can contain other<topicref> elements, allowing you to
express navigation or table-of-contents hierarchies.
topicrefMap elementstopicref
map, topicreftopicref (0 or more) In this example, there are six topicrefs. They are nested and have
a hierarchical relationship. Bats.xml is the parent topic and the other topics
are its children.<map title="Bats" Bats
<topicref href="bats.xml" type="topic">
<topicref href="batcaring.xml" type="task"></topicref>
<topicref href="batfeeding.xml" type="task"></topicref>
<topicref href="batsonar.xml" type="concept"></topicref>
<topicref href="batguano.xml" type="reference"></topicref>
<topicref href="bathistory.xml" type="reference"></topicref>
</topicref>
</map>
dita-ot-1.5.3/demo/enote/ 0000775 0000000 0000000 00000000000 11671002146 0015115 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/enote/catalog.xml 0000664 0000000 0000000 00000000747 11671002146 0017261 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/enote/enote.mod 0000664 0000000 0000000 00000015012 11671002146 0016727 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/enote/enote2fo.xsl 0000664 0000000 0000000 00000004444 11671002146 0017374 0 ustar 00root root 0000000 0000000
Subject: :
dita-ot-1.5.3/demo/enote/enote2fo_shell.xsl 0000664 0000000 0000000 00000001512 11671002146 0020554 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/enote/enote2html.xsl 0000664 0000000 0000000 00000023336 11671002146 0017735 0 ustar 00root root 0000000 0000000
,,
&body=
The Frequently Asked Questions for DITA have been collected from questions asked on the DITA Forum and among other communities. Some of the answers reflect DITA Best Practices.
General DITA questions
Question: Why is "Darwin" in the name of this architecture?
Answer: The entire name of the architecture has this combined explanation:
Darwin: it uses the principles of specialization and inheritance
Information Typing: it capitalizes on the semantics of topics (concept, task, reference) and of content (messages, typed phrases, semantic tables)
Architecture: it provides vertical headroom (new applications) and edgewise extension (specialization into new types) for information
This architecture supports the proper construction of specialized DTDs from any higher-level DTD or schema. The base DTD is ditabase DTD, which contains an archetype topic structure and three additional peer topics that are typed specializations from the basic topic: concept, task, and reftopic. The principles of specialization and inheritance resemble the principle of variation in species proposed by Charles Darwin. So the name reminds us of the key extensibility mechanism inherent in the architecture.
Question: Where can I learn more about topic-oriented writing and user assistance?
Answer: Look over the topic architecture FAQs below, and then try the following two introductory sites on information architectures:
Argus Center for Information Architecture
10 Questions about Information Architecture
Question: How does DITA differ from DocBook?
Answer: It's important to recognize that DocBook and DITA take fundamentally different approaches.
DocBook was originally designed for a single, continuous technical narrative (where the narrative might be of article, book, or multi-volume length). Through transforms, DocBook can chunk this technical narrative into topics to provide support for Web sites and other information sets. Because the goal of the DocBook DTD is to handle all standard requirements for technical documentation, the usage model encourages customization to exclude elements that aren't local requirements. The usage model supports but discourages local extensions because of the potential for unknown new elements to break tool support and interoperability.
By contrast, DITA was designed for discrete technical topics. DITA collects topics into information sets, potentially using filtering criteria. The core DITA information types are not intended to cover all requirements but, instead, provide a base for meeting new requirements through extension. Extension is encouraged, but new elements must be recognizable as specializations of existing elements. Through generalization, DITA provides for tool reuse and interoperability.
Each approach has its strengths. DocBook would be the likely choice for a technical narrative. DITA would be the likely choice for large, complex collections of topics or for applications that require both extensibility and interoperability. Technical communications groups might want to experiment with both packages to determine which approach is better suited for their processes and outputs.
Question: How will changes to the DTD be made and controlled?
Answer: The Darwin Information Typing Architecture was first introduced in April 2001. Since then users have discussed issues about the DITA within IBM and on the DITA forum, and various changes have evolved, leading to a major refresh a year later. The design will slow down so that the interested user community -- you! -- can focus on learning about and using DITA.
Use the DITA forum to discuss the use of the DITA DTDs and style sheets. The read-me document lists several known limitations, but doubtless others await discovery as you use the DTDs. Through discussion in the DITA forum, the significant ideas will be identified and applied to subsequent refreshes of the package. The forum will be actively monitored by the DITA project's architects, Don Day and Michael Priestley, among others.
Question: May I use this DTD in my own company?
Answer: Yes, we encourage you to use it.
Question: Is DITA integrated into any IBM products?
Answer: Yes. We have several projects underway that are using DITA. The purpose of those projects is to continue to validate the DITA architecture and use the DTD in a product development environment.
Question: Is there an XML schema for the DITA DTDs?
Answer: Yes, the DITA toolkit provides both DTD and XML Schema representations of the architecture. The basic concepts of DITA are not tied to implementation. Both schemas and DTDs can be used to define specializable DITA elements.
Answer: A topic is a chunk of information organized around a single subject. Structurally, it is a title followed by text and images, optionally organized into sections. Topics can be of many different types, the most common being concepts, tasks, and reference.
Question: Why topics?
Answer: DITA is based on topics because they are the optimal size to allow reuse in different delivery contexts without affecting a writer's efficiency. If we choose a smaller unit, the writer needs to check the unit in all its contexts to make sure that information flows correctly. If we choose a larger unit, the information cannot be easily reassembled into structures that different delivery contexts (such as a Web site or a book) require. A topic is large enough to be self contained from a writer's point of view but small enough to reuse effectively in whatever higher-level structure a particular delivery context requires.
Question: What is the topic structure in the architecture?
Answer: The topic structure is the result of some conditions that we established for the document architecture:
<topic> is the container for a single non-nesting body and any number of nesting topics.
<title> provides self-description, consistent with guidelines for authoring.
<body> is the container for paragraph-level content and any number of non-nesting sections.
A topic can be augmented by a prolog, a short description, and other optional metadata. These conditions lead to the following structure:
See the Sample topic, and its explanation, The structure of a DITA topic.
Question: What is "progressive disclosure" in a topic?
Answer: Because each topic has a title and short description in addition to its full content, applications can provide progressive disclosure. For example, a user can hover over a link to see its short description and then decide whether to follow the link for the rest of the topic. Progressive disclosure also allows topics to be meaningfully browsed in a variety of viewing contexts, whether full-screen browsers, integrated help panes, infopops, or PDA screens. The application can disclose as much information as the context supports, letting the user decide where and how to drill down to more content.
Question: Can topics be nested?
Answer: Topics can be nested to create larger document structures. However, the nesting always occurs outside the content boundary, so that child and parent topics can be easily separated and reused in different contexts (see The structure of a DITA topic). Here is a sample nesting structure:
<topic>
<title>A general topic</title>
<shortdesc>This general topic is pretty general.</shortdesc>
<body><p>General topics are not very specific. They are useful for
the big picture, but they don't get into details in the same way as
more specific topics.</p></body>
<topic>
<title>A specific topic</title>
<shortdesc>This is a more specific topic.</shortdesc>
<body><p>Specifically, this is more specific.</p></body>
</topic>
</topic>
You can author topics either as nested structures or as individual stand-alone documents. In the latter case, you assemble the documents into nested structures as required, such as when delivering printed or printable information that has a part and chapter hierarchy.
The nested structure gives a sequence and hierarchy of topics within a topic collection. In a Web environment you could disassemble this structure into individual topics and preserve the hierarchy in a generated navigation map or table of contents. However, if the Web is the main delivery vehicle, you might want to author the topics as separate documents and then apply several tables of contents to the same collection of topics.
Question: What is an information type?
Answer: An information type describes a category of topics, such as concepts, tasks, or reference. Typically, different information types support different kinds of content. For example, a task typically has a set of steps, whereas a reference topic has a set of customary sections, such as syntax, properties, and usage.
Question: Why information types?
Answer: With information types, you can divide topics into categories that you can manage and keep consistent more easily than without information types. Information types also make it easier for users to find the information that they are looking for: how-to information in a task versus background information in a concept versus detailed specifications in a reference topic.
Question: What is specialization?
Answer: Specialization is the process of creating new categories of topics, or information types, as well as new categories of elements, or domain types. You can define these new types using the existing ones as a base. For example, a product group might identify three main types of reference topic -- messages, utilities, and APIs -- and define three domains -- networking, programming, and databases. By creating a specialized topic type for each kind of reference information, and creating a domain type for each kind of subject, the product architect can ensure that each type of topic has the appropriate structures and 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 searching for xyz across reference topics in general.
Rules govern how to specialize safely: Each new information type must map to an existing one, and new information types must be more restrictive than the existing one in the content that they allow. 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. The DITA specialization articles outline the rules for each kind of specialization (topic type and domain type).
Question: How can I combine several topics into a single document?
Answer: The DITA design has a unified content reuse mechanism by which an element can replace itself with the content of a like element elsewhere, either in the current topic or in a separate topic that shares the same content models. The distinction between reusable content and reusing content, which is enshrined in the file entity scheme, disappears: Any element with an ID, in any DITA topic, is reusable by conref.
DITA's conref "transclusion" mechanism is similar to the SGML conref mechanism, which uses an empty element as a reference to a complete element elsewhere. However, DITA requires that at least a minimal content model for the referencing element be present, and performs checks during processing to ensure that the replacement element is valid in its new context. This mechanism goes beyond standard XInclude, in that content can be incorporated only when it is equivalent: If there is a mismatch between the reusing and reused element types, the conref is not resolved. It also goes beyond standard entity reuse, in that it allows the reused content to be in a valid XML file with a DTD. The net result is that reused content gets validated at authoring time, rather than at reuse time, catching problems at their source.
Content referencing can be used at any scope of elements in a DITA document, from a keyword phrase that contains only PCDATA to a whole topic with other nested topics. Conref can cross file boundaries, using the same syntax as that of the href attribute on the xref element. If your authoring DTD allows topic nesting, you can create a set of minimal child topics and then use their conref attributes to pull in content from fully populated topics in other files.
Question: What if my information doesn't break down into topics?
Answer: Most information can be broken down into topics (headings and content). However, if your information requires a more seamless flow of information across topic boundaries, don't use this architecture.
Question: When should I specialize?
Answer: Create specialized topics when you have a restrictive category of topics that you want to keep consistent and that your users want to distinguish from other categories. Create specialized domains when you have a set of elements that you want available across several of your topic types. Be sure to specialize from the correct base: For example, categories of reference topics should specialize <reference>, categories of tasks should specialize <task>, and domain types should always specialize either <topic> or another domain type. If you need to allow more content structures than the base types allow, you can specialize directly from topic, or form your own base type. However, the lower down in the hierarchy that you can specialize, the better; you can then take advantage of any transforms or processes that have been developed for the more general categories that you specialize from.
Question: How do I specialize?
Answer: You need to identify the differences between your new type of information and the more general type that you are specializing from. After you have identified the differences, you create a DTD file to declare the new elements that you require. Create another module to declare a set of mapping attributes for the new elements that point to the generic element types that they specialize. Then add import statements in the DTD file to bring in the mapping module and any ancestor modules. Finally, add a line that redefines the information types entity to include your new type. You now have a customized DTD.
When you specialize a domain, you need to first determine what elements must be specialized for the domain. Then you write an entity declaration file to list the specialized elements, along with their topic types and domain types. Next, you create a file where you define both the elements that are introduced for the domain and the specialization hierarchy. Finally, you write the shell DTD to combine the domain with topics and other domains.
These processes are described in more detail in the documents Specializing topics in DITA and Specializing domains in DITA.
Question: How do I extend specialization-aware transforms?
Answer: See the article on specializing topic types.
Question: Can I use HTML in this DTD?
Answer: Yes. Many writers have had at least some experience with HTML as a markup language. Therefore the base DITA DTD incorporates as many HTML elements as are useful for the type of technical information for which topics might be used. In addition, we have defined a subset of XHTML for which there is a very simple transformation into the DITA format -- often with no change to many content elements! In fact, if you can load an XHTML document into the same editor as an XML DITA document, you can probably copy and paste long stretches of the XHTML content directly into the topic. Regardless, to gain the real advantage of XML, you should use the semantics of the DTD.
Question: Where can I see the DITA DTD in use?
Answer: Right here! The original documents that accompany this proposal were authored in XML using the ditabase DTD.
dita-ot-1.5.3/demo/faq/DITA-faq.xml 0000664 0000000 0000000 00000045411 11671002146 0016567 0 ustar 00root root 0000000 0000000
Frequently Asked Questions about the Darwin Information Typing ArchitectureThe Frequently Asked Questions for DITA have been collected from questions asked on the DITA Forum and among other communities. Some of the answers reflect DITA Best Practices.General DITA questions Why is "Darwin" in the name of this architecture?The entire name of the architecture has this combined explanation:
Darwin: it uses the principles of specialization and inheritance
Information Typing: it capitalizes on the semantics of topics (concept, task, reference) and of content (messages, typed phrases, semantic tables)
Architecture: it provides vertical headroom (new applications) and edgewise extension (specialization into new types) for information
This architecture supports the proper construction of specialized DTDs from any higher-level DTD or schema. The base DTD is ditabase DTD, which contains an archetype topic structure and three additional peer topics that are typed specializations from the basic topic: concept, task, and reftopic. The principles of specialization and inheritance resemble the principle of variation in species proposed by Charles Darwin. So the name reminds us of the key extensibility mechanism inherent in the architecture.
Where can I learn more about topic-oriented writing and user assistance?Look over the topic architecture FAQs below, and then try the following two introductory sites on information architectures:
Argus Center for Information Architecture
10 Questions about Information Architecture
How does DITA differ from DocBook?It's important to recognize that DocBook and DITA take fundamentally different approaches.
DocBook was originally designed for a single, continuous technical narrative (where the narrative might be of article, book, or multi-volume length). Through transforms, DocBook can chunk this technical narrative into topics to provide support for Web sites and other information sets. Because the goal of the DocBook DTD is to handle all standard requirements for technical documentation, the usage model encourages customization to exclude elements that aren't local requirements. The usage model supports but discourages local extensions because of the potential for unknown new elements to break tool support and interoperability.
By contrast, DITA was designed for discrete technical topics. DITA collects topics into information sets, potentially using filtering criteria. The core DITA information types are not intended to cover all requirements but, instead, provide a base for meeting new requirements through extension. Extension is encouraged, but new elements must be recognizable as specializations of existing elements. Through generalization, DITA provides for tool reuse and interoperability.
Each approach has its strengths. DocBook would be the likely choice for a technical narrative. DITA would be the likely choice for large, complex collections of topics or for applications that require both extensibility and interoperability. Technical communications groups might want to experiment with both packages to determine which approach is better suited for their processes and outputs.
How will changes to the DTD be made and controlled?The Darwin Information Typing Architecture was first introduced in April 2001. Since then users have discussed issues about the DITA within IBM and on the DITA forum, and various changes have evolved, leading to a major refresh a year later. The design will slow down so that the interested user community -- you! -- can focus on learning about and using DITA.
Use the DITA forum to discuss the use of the DITA DTDs and style sheets. The read-me document lists several known limitations, but doubtless others await discovery as you use the DTDs. Through discussion in the DITA forum, the significant ideas will be identified and applied to subsequent refreshes of the package. The forum will be actively monitored by the DITA project's architects, Don Day and Michael Priestley, among others.
May I use this DTD in my own company?Yes, we encourage you to use it.Is DITA integrated into any IBM products?Yes. We have several projects underway that are using DITA. The purpose of those projects is to continue to validate the DITA architecture and use the DTD in a product development environment. Is there an XML schema for the DITA DTDs?
Yes, the DITA toolkit provides both DTD and XML Schema representations of the architecture. The basic concepts of DITA are not tied to implementation. Both schemas and DTDs can be used to define specializable DITA elements.
The topic architecture of DITA What is a topic? A topic is a chunk of information organized around a single subject. Structurally, it is a title followed by text and images, optionally organized into sections. Topics can be of many different types, the most common being concepts, tasks, and reference. Why topics? DITA is based on topics because they are the optimal size to allow reuse in different delivery contexts without affecting a writer's efficiency. If we choose a smaller unit, the writer needs to check the unit in all its contexts to make sure that information flows correctly. If we choose a larger unit, the information cannot be easily reassembled into structures that different delivery contexts (such as a Web site or a book) require. A topic is large enough to be self contained from a writer's point of view but small enough to reuse effectively in whatever higher-level structure a particular delivery context requires. What is the topic structure in the architecture? The topic structure is the result of some conditions that we established for the document architecture:
<topic> is the container for a single non-nesting body and any number of nesting topics.
<title> provides self-description, consistent with guidelines for authoring.
<body> is the container for paragraph-level content and any number of non-nesting sections.
A topic can be augmented by a prolog, a short description, and other optional metadata. These conditions lead to the following structure:
See the Sample topic, and its explanation, The structure of a DITA topic.
What is "progressive disclosure" in a topic? Because each topic has a title and short description in addition to its full content, applications can provide progressive disclosure. For example, a user can hover over a link to see its short description and then decide whether to follow the link for the rest of the topic. Progressive disclosure also allows topics to be meaningfully browsed in a variety of viewing contexts, whether full-screen browsers, integrated help panes, infopops, or PDA screens. The application can disclose as much information as the context supports, letting the user decide where and how to drill down to more content. Can topics be nested? Topics can be nested to create larger document structures. However, the nesting always occurs outside the content boundary, so that child and parent topics can be easily separated and reused in different contexts (see The structure of a DITA topic). Here is a sample nesting structure:
<topic>
<title>A general topic</title>
<shortdesc>This general topic is pretty general.</shortdesc>
<body><p>General topics are not very specific. They are useful for
the big picture, but they don't get into details in the same way as
more specific topics.</p></body>
<topic>
<title>A specific topic</title>
<shortdesc>This is a more specific topic.</shortdesc>
<body><p>Specifically, this is more specific.</p></body>
</topic>
</topic>
You can author topics either as nested structures or as individual stand-alone documents. In the latter case, you assemble the documents into nested structures as required, such as when delivering printed or printable information that has a part and chapter hierarchy.
The nested structure gives a sequence and hierarchy of topics within a topic collection. In a Web environment you could disassemble this structure into individual topics and preserve the hierarchy in a generated navigation map or table of contents. However, if the Web is the main delivery vehicle, you might want to author the topics as separate documents and then apply several tables of contents to the same collection of topics.
What is an information type? An information type describes a category of topics, such as concepts, tasks, or reference. Typically, different information types support different kinds of content. For example, a task typically has a set of steps, whereas a reference topic has a set of customary sections, such as syntax, properties, and usage. Why information types? With information types, you can divide topics into categories that you can manage and keep consistent more easily than without information types. Information types also make it easier for users to find the information that they are looking for: how-to information in a task versus background information in a concept versus detailed specifications in a reference topic. What is specialization? Specialization is the process of creating new categories of topics, or information types, as well as new categories of elements, or domain types. You can define these new types using the existing ones as a base. For example, a product group might identify three main types of reference topic -- messages, utilities, and APIs -- and define three domains -- networking, programming, and databases. By creating a specialized topic type for each kind of reference information, and creating a domain type for each kind of subject, the product architect can ensure that each type of topic has the appropriate structures and 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 searching for xyz across reference topics in general.
Rules govern how to specialize safely: Each new information type must map to an existing one, and new information types must be more restrictive than the existing one in the content that they allow. 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. The DITA specialization articles outline the rules for each kind of specialization (topic type and domain type).
Tips and techniquesHow can I combine several topics into a single document?The DITA design has a unified content reuse mechanism by which an element can replace itself with the content of a like element elsewhere, either in the current topic or in a separate topic that shares the same content models. The distinction between reusable content and reusing content, which is enshrined in the file entity scheme, disappears: Any element with an ID, in any DITA topic, is reusable by conref.
DITA's conref "transclusion" mechanism is similar to the SGML conref mechanism, which uses an empty element as a reference to a complete element elsewhere. However, DITA requires that at least a minimal content model for the referencing element be present, and performs checks during processing to ensure that the replacement element is valid in its new context. This mechanism goes beyond standard XInclude, in that content can be incorporated only when it is equivalent: If there is a mismatch between the reusing and reused element types, the conref is not resolved. It also goes beyond standard entity reuse, in that it allows the reused content to be in a valid XML file with a DTD. The net result is that reused content gets validated at authoring time, rather than at reuse time, catching problems at their source.
Content referencing can be used at any scope of elements in a DITA document, from a keyword phrase that contains only PCDATA to a whole topic with other nested topics. Conref can cross file boundaries, using the same syntax as that of the href attribute on the xref element. If your authoring DTD allows topic nesting, you can create a set of minimal child topics and then use their conref attributes to pull in content from fully populated topics in other files.
What if my information doesn't break down into topics?Most information can be broken down into topics (headings and content). However, if your information requires a more seamless flow of information across topic boundaries, don't use this architecture. When should I specialize?Create specialized topics when you have a restrictive category of topics that you want to keep consistent and that your users want to distinguish from other categories. Create specialized domains when you have a set of elements that you want available across several of your topic types. Be sure to specialize from the correct base: For example, categories of reference topics should specialize <reference>, categories of tasks should specialize <task>, and domain types should always specialize either <topic> or another domain type. If you need to allow more content structures than the base types allow, you can specialize directly from topic, or form your own base type. However, the lower down in the hierarchy that you can specialize, the better; you can then take advantage of any transforms or processes that have been developed for the more general categories that you specialize from. How do I specialize?You need to identify the differences between your new type of information and the more general type that you are specializing from. After you have identified the differences, you create a DTD file to declare the new elements that you require. Create another module to declare a set of mapping attributes for the new elements that point to the generic element types that they specialize. Then add import statements in the DTD file to bring in the mapping module and any ancestor modules. Finally, add a line that redefines the information types entity to include your new type. You now have a customized DTD.
When you specialize a domain, you need to first determine what elements must be specialized for the domain. Then you write an entity declaration file to list the specialized elements, along with their topic types and domain types. Next, you create a file where you define both the elements that are introduced for the domain and the specialization hierarchy. Finally, you write the shell DTD to combine the domain with topics and other domains.
These processes are described in more detail in the documents Specializing topics in DITA and Specializing domains in DITA.
How do I extend specialization-aware transforms?See the article on specializing topic types.Can I use HTML in this DTD?Yes. Many writers have had at least some experience with HTML as a markup language. Therefore the base DITA DTD incorporates as many HTML elements as are useful for the type of technical information for which topics might be used. In addition, we have defined a subset of XHTML for which there is a very simple transformation into the DITA format -- often with no change to many content elements! In fact, if you can load an XHTML document into the same editor as an XML DITA document, you can probably copy and paste long stretches of the XHTML content directly into the topic. Regardless, to gain the real advantage of XML, you should use the semantics of the DTD. Where can I see the DITA DTD in use?Right here! The original documents that accompany this proposal were authored in XML using the ditabase DTD.
dita-ot-1.5.3/demo/faq/README_FAQ.txt 0000664 0000000 0000000 00000006544 11671002146 0016750 0 ustar 00root root 0000000 0000000 ##
FAQ EXAMPLE
This example gives a demonstration of topic specialization by
defining a simple FAQ topic.
The purpose of the FAQ topic is to model a list of frequently asked
questions. The FAQ topic uses a specialization of the simpletable
element to model the list so multiple types of information can be
tracked for each FAQ item.
The example includes the DTD module, an XSL module for generating HTML
output, and a sample data file.
Drop the demo source file ditafaq.xml onto a Mozilla-class browser to
see the effect of CSS styling on literally rendered DITA XML elements.
Drag/drop the demo file onto IE6 to see the effect of a DITA XML topic
rendered by XSLT directly in the browser.
CAVEAT
The FAQ example is provided only as an example of topic specialization
and not as a standard topic type within the DITA architecture. Other
design approaches are possible.
For instance, you could model a FAQ list as a domain specialization
of the simpletable element. This approach would let you provide a FAQ
list within topic types such as concept or reference.
Or, you could model a FAQ list with each FAQ item as a separate
topic. This approach would make it easy to assemble different kinds
of FAQ lists from a pool of FAQ items.
The design for a FAQ information type would need to be validated with
a community.
FAQ EXAMPLE FILES
This directory contains the FAQ example, including:
ditafaq.xml
- a sample data source file
ditafaq.html
- a sample data output file
faq.mod
- topic module to define the FAQ information type
faq_shell.dtd
- shell DTD to merge base and FAQ information types
faq.css
- convenience CSS for styling FAQ elements (for instance, in
editors such as XMetaL)
faq_shell.css
- convenience shell CSS to merge base and FAQ styles
faq2html.xsl
- XSL module to format the FAQ deltas as HTML
faq2html_shell.xsl
- shell XSL to merge base and FAQ formatting
faq2fo.xsl
- XSL module to format the FAQ deltas as XSL-FO
faq2fo_shell.xsl
- shell XSL to merge base and FAQ formatting
faq_strings.xml
- example internationalization file
GENERATING OUTPUT FROM THE EXAMPLE
To generate HTML output, you need to install an XSLT processor.
There are many options for XSLT processor. For one example, you can
install a Java„1¤7 runtime (JRE) and an XSLT processor such as Saxon.
JRE
- Get a JRE (or a JDK bundling a JRE) such as the Sun J2SE plaform:
http://java.sun.com/j2se/downloads.html
Java„1¤7 comes with an install program.
Saxon
- http://saxon.sourceforge.net/
To install Saxon, you unzip the package and add the saxon.jar
file to the CLASSPATH environment variable.
Using Saxon, you can generate HTML or XSL formatting objects from the sample data with
java com.icl.saxon.StyleSheet -o ditafaq.html ditafaq.xml faq2html_shell.xsl
java com.icl.saxon.StyleSheet -o ditafaq.fo ditafaq.xml faq2fo_shell.xsl
FEEDBACK
If you run into problems or want to discuss this example, please feel
free to ask questions on the DITA forum:
news://news.software.ibm.com:119/ibm.software.developerworks.xml.dita
Have fun exploring,
The DITA Team
Java is a registered trademark of Sun Microsystems, Inc.. dita-ot-1.5.3/demo/faq/catalog.xml 0000664 0000000 0000000 00000000737 11671002146 0016715 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/faq/ditafaq.html 0000664 0000000 0000000 00000007317 11671002146 0017061 0 ustar 00root root 0000000 0000000
About DITA
Answer: First, consider whether the default formatting for the base elements meets your requirements. If not, create a new XSLT script that imports the base XSLT script and provides the special formatting for your specialized elements.
Question: What if another DITA user needs to reuse my content but doesn't have my specialization?
Answer: DITA provides a built-in generalization process that automatically promotes your specialized elements to the base elements that the other user already has.
dita-ot-1.5.3/demo/faq/ditafaq.xml 0000664 0000000 0000000 00000004034 11671002146 0016706 0 ustar 00root root 0000000 0000000
About DITADesigning SpecializationsHow do I create a specialization?Create a DTD module in which the DTD elements derive from elements in an existing DTD module.Jane SmithWhich element should be the basis for my specialized element?You should look for a base element that
Has a more general meaning that also applies to your content
Can accomodate the substructure of your content.
For example, this specialization is based on the simpletable element, which models information with a repeating substructure.
Processing SpecializationsHow do I format my specialization?First, consider whether the default formatting for the base elements meets your requirements. If not, create a new XSLT script that imports the base XSLT script and provides the special formatting for your specialized elements. What if another DITA user needs to reuse my content but doesn't have my specialization?DITA provides a built-in generalization process that automatically promotes your specialized elements to the base elements that the other user already has.
dita-ot-1.5.3/demo/faq/faq-xs.mod 0000664 0000000 0000000 00000020716 11671002146 0016460 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/faq/faq.css 0000664 0000000 0000000 00000002576 11671002146 0016045 0 ustar 00root root 0000000 0000000 /*
| (c) Copyright IBM Corp. 2004, 2005 All Rights Reserved.
*/
faq {
display: block;
margin-top: 6pt;
margin-bottom: 9pt;
font-family: sans-serif;
padding-left: 5px;
padding-right: 5px;
}
faq>title {
display: block;
margin-top: 16pt;
margin-bottom: 9pt;
font-size: 20pt;
font-weight: bold;
color: #000001;
}
faqgroup>title {
display: block;
font-weight: bold;
font-style: normal;
margin-bottom: 1em;
}
faqitem {
display: block;
margin-left: 1em;
margin-bottom: 1em;
}
faqans {
display: block;
margin-bottom: 0.5em;
line-height: 125%;
}
faqquest {
display: block;
font-style: italic;
margin-bottom: 0.5em;
line-height: 125%;
}
keyword {
font-family: Courier, Monospace;
}
faqprop {
display: block;
background-color: #EEEEEE;
padding-top: 0.25em;
padding-right: 0.25em;
padding-left: 0.25em;
padding-bottom: 0.25em;
}
faqquest, faqans {
display: list-item;
list-style-type: none;
}
faqquest:before {
content: "Q: ";
font-weight: bold;
}
faqans:before {
content: "A: ";
font-weight: bold;
}
name:before {
content: "Name: ";
font-weight: bold;
color: #990000;
}
name, ownerEmail {
display: block;
}
ownerEmail:before {
display: block;
font-weight: bold;
content: "Email: "attr(href);
color: #990000;
}
dita-ot-1.5.3/demo/faq/faq.mod 0000664 0000000 0000000 00000007326 11671002146 0016032 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/faq/faq2fo.xsl 0000664 0000000 0000000 00000006523 11671002146 0016466 0 ustar 00root root 0000000 0000000
::
dita-ot-1.5.3/demo/faq/faq2fo_shell.xsl 0000664 0000000 0000000 00000001504 11671002146 0017647 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/faq/faq2html.xsl 0000664 0000000 0000000 00000006742 11671002146 0017031 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/faq/faq2xhtml_shell.xsl 0000664 0000000 0000000 00000001514 11671002146 0020400 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/faq/faq_shell.css 0000664 0000000 0000000 00000000202 11671002146 0017214 0 ustar 00root root 0000000 0000000 /*
| (c) Copyright IBM Corp. 2004, 2005 All Rights Reserved.
*/
@import url(../../css/topic.css);
@import url(faq.css);
dita-ot-1.5.3/demo/faq/faq_shell.dtd 0000664 0000000 0000000 00000001221 11671002146 0017201 0 ustar 00root root 0000000 0000000
%topic-type;
%faq-typemod;
dita-ot-1.5.3/demo/faq/faq_shell.xsd 0000664 0000000 0000000 00000001735 11671002146 0017236 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/faq/faq_strings.xml 0000664 0000000 0000000 00000001255 11671002146 0017617 0 ustar 00root root 0000000 0000000
QuestionAnswerPreguntaRespuestaFrageAntwort
dita-ot-1.5.3/demo/faq/plugin.xml 0000664 0000000 0000000 00000000603 11671002146 0016571 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/fo/ 0000775 0000000 0000000 00000000000 11671002146 0014407 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/fo/Customization/ 0000775 0000000 0000000 00000000000 11671002146 0017257 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/fo/Customization/README.txt 0000664 0000000 0000000 00000003440 11671002146 0020756 0 ustar 00root root 0000000 0000000 About fo/Customization
======================
This directory is where the custom files live that make up customized
versions of the OpenTopic publishing outputs. The FO publishing output
will look for certain files here to override the standard ones. Things
you can currently override include:
- Custom XSL via fo/xsl/custom.xsl, xhtml/xsl/custom.xsl and
fo/attrs/custom.xsl
- Layout overrides via fo/layout-masters.xml
- Font overrides via fo/font-mappings.xml
- Per-locale variable overrides via common/vars/[locale].xml
- I18N configuration via fo/i18n/[locale].xml
- Index configuration via fo/index/[locale].xml
When customizing any of these areas, modify the relevant file(s) in
fo/Customization. Then, to enable the changes in the publishing process,
you find the corresponding entry for each file you modified in
fo/Customization/catalog.xml. It should look like this:
Remove the comment markers "!--" and "--" to enable the change:
Your customization should now be enabled as part of the publishing process.
We have provided template files that you can start with throughout
this directory structure. These files end in the suffix ".orig" (for
example, "catalog.xml.orig"). To enable these files, make a copy of
them and remove the ".orig" suffix. For example, copy
"catalog.xml.orig" to "catalog.xml". You can then make modifications
to the copy.
The Fo output also provides a general configuration file called
"build.properties" that allows you to control the publishing process.
To modify these settings, copy "build.properties.orig" to
"build.properties" and then modify the relevant options.
dita-ot-1.5.3/demo/fo/Customization/common/ 0000775 0000000 0000000 00000000000 11671002146 0020547 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/fo/Customization/common/artwork/ 0000775 0000000 0000000 00000000000 11671002146 0022240 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/fo/Customization/common/artwork/README.txt 0000664 0000000 0000000 00000001204 11671002146 0023733 0 ustar 00root root 0000000 0000000 About fo/Customization/common/artwork
=============================================
This folder houses custom artwork files that override the standard
ones in fo/cfg/common/artwork. These files are used
to graphically identify different types of DITA element.
The mapping between type and graphic is contained in a subset of
the locale-dependent variable files, such as
fo/cfg/common/vars
The variables that control graphics all follow the form
{AIS Path of image file}
where {type} contains a possible value for the @type attribute.
dita-ot-1.5.3/demo/fo/Customization/common/index/ 0000775 0000000 0000000 00000000000 11671002146 0021656 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/fo/Customization/common/index/README.txt 0000664 0000000 0000000 00000001743 11671002146 0023361 0 ustar 00root root 0000000 0000000 About fo/Customization/common/index
===========================================
This folder houses custom index definition files that override the standard
ones in fo/cfg/common/index. Each file contains data for a single locale, and
should take that locale's ISO code as its name (for example, de_DE.xml).
The index files consist of elements which contain sorting
information on one or more characters. Index groups are listed in sort order
("specials" before numbers, numbers before the letter 'A', etc), and the
entries they contain are also listed in sort order (uppercase before
lowercase).
The best way to start editing a custom index file is by making a copy of the
original from fo/cfg/common/index and making changes as desired.
In order to apply a custom index definition to your publishing outputs, you
must edit fo/Customization/catalog.xml and uncomment the appropriate
entry in the "Index configuration override entries" section.
dita-ot-1.5.3/demo/fo/Customization/common/vars/ 0000775 0000000 0000000 00000000000 11671002146 0021522 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/fo/Customization/common/vars/README.txt 0000664 0000000 0000000 00000003432 11671002146 0023222 0 ustar 00root root 0000000 0000000 About fo/Customization/common/vars
===========================================
This folder houses custom variable files that override the standard ones in
fo/cfg/common/vars. Each file contains data for a single locale, and should
take that locale's ISO code as its name (for example, de_DE.xml).
Variable files contain a set of elements, identified by their id
attribute. The variable definitions are used to store static text that is used
as part of the published outputs. For example, page headers, hyperlinks, etc.
The id attribute for each variable should make it clear how the variable text
is being used.
Some variables contain elements which indicate parameter values which
are substituted in at publish time by the XSL. For example, a page number that
is being generated as part of the publishing process might be identified by
When editing or translating a variable file, these should be included in the
translation, though they can be moved and rearranged within the
content as needed.
The best way to start editing a custom variables file is by making a copy of
the original from fo/cfg/common/vars and making changes as desired. When
adding a new locale, start from an existing locale's list of variables and
translate each entry as needed.
Note that unchanged elements can be omitted: the custom variables
file need only include those elements which you have modified.
Variables not found in the custom file will are taken from the standard
OpenTopic variable files.
Applying a custom variable does not require modifying the
fo/Customization/catalog.xml file. The publishing process will automatically
use any custom variables definitions in place of the original ones.
dita-ot-1.5.3/demo/fo/Customization/fo/ 0000775 0000000 0000000 00000000000 11671002146 0017663 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/fo/Customization/fo/attrs/ 0000775 0000000 0000000 00000000000 11671002146 0021020 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/fo/Customization/fo/attrs/README.txt 0000664 0000000 0000000 00000001600 11671002146 0022513 0 ustar 00root root 0000000 0000000 About fo/Customization/fo/attrs
=======================================
This folder houses custom configuration files that override the
standard ones in fo/cfg/fo/attrs. These files that define the appearance
of different elements in XML assets when they are rendered as PDF outputs.
The different DITA elements are organized into files by element type --
index-related definitions in index-attr.xsl, table-related definitions in
tables-attr.xsl, etc.
Idiom has provided template files that you can start with throughout
this directory structure. These files end in the suffix ".orig" (for
example, "catalog.xml.orig"). To enable these files, make a copy of
them and remove the ".orig" suffix. For example, copy
"custom.xsl.orig" to "custom.xsl". You can then make modifications
to the copy.
The files in this directory will override the out-of-the-box settings.
dita-ot-1.5.3/demo/fo/Customization/fo/i18n/ 0000775 0000000 0000000 00000000000 11671002146 0020442 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/fo/Customization/fo/i18n/README.txt 0000664 0000000 0000000 00000001534 11671002146 0022143 0 ustar 00root root 0000000 0000000 About fo/Customization/fo/i18n
======================================
This folder houses custom configuration files that override the standard ones
in fo/cfg/fo/i18n. Each file contains data for a single
locale, and should take that locale's ISO code as its name (for example,
de_DE.xml). These files are used only in the generation of PDF outputs.
Each configuration file contains mappings of certain symbols to the Unicode
codepoint which should be used to represent them in the given locale.
The best way to start editing a custom configuration is by making a copy of the
original from fo/cfg/fo/i18n and making changes as desired.
In order to apply a custom configuration to your publishing outputs, you must
edit fo/Customization/catalog.xml and uncomment the appropriate entry
in the "I18N configuration override entries" section.
dita-ot-1.5.3/demo/fo/Customization/fo/xsl/ 0000775 0000000 0000000 00000000000 11671002146 0020471 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/fo/Customization/fo/xsl/README.txt 0000664 0000000 0000000 00000001212 11671002146 0022163 0 ustar 00root root 0000000 0000000 About fo/Customization/fo/xsl
=============================
This folder houses custom configuration files that override the
standard ones in fo/cfg/fo/xsl.
Idiom has provided template files that you can start with throughout
this directory structure. These files end in the suffix ".orig" (for
example, "catalog.xml.orig"). To enable these files, make a copy of
them and remove the ".orig" suffix. For example, copy
"custom.xsl.orig" to "custom.xsl". You can then make modifications
to the copy.
The files in this directory will override the out-of-the-box settings.
See the OpenTopic Customization Guide for more information.
dita-ot-1.5.3/demo/fo/README.txt 0000664 0000000 0000000 00000026024 11671002146 0016111 0 ustar 00root root 0000000 0000000 Welcome to Idiom FO output for the DITA Open Toolkit
======================================================
Apache FOP (Formatting Objects Processor) is a print formatter driven
by XSL formatting objects (XSL-FO) and an output independent formatter.
It is a Java application that reads a formatting object (FO) tree and
renders the resulting pages to a specified output. Output formats
currently supported include PDF, PS, PCL, AFP, XML (area tree representation),
Print, AWT and PNG, and to a lesser extent, RTF and TXT. The primary
output target is PDF.
Installing Idiom FO output
=========================================
* If you are using a full-easy-install package, you don't need to do additional
work to run pdf conversion. Just use the pdf transtype to build your pdf output.
* If you are NOT using a full-easy-install package, some additional efforts are
needed to get pdf conversion run. You will need the following software:
- Apache FOP: Apache FOP can be obtained from http://xmlgraphics.apache.org/fop/
This plugin also requires Saxon 6.5.3. But if you are using JDK 1.5 or
newer, you will need Saxon 6.5.5 or newer which has fixes for JDK 1.5
compatibility. Download Saxon 6.5.5 from http://saxon.sourceforge.net.
- ICU4J: You can find this library by clicking on the "Download ICU" link
at http://icu.sourceforge.net. Look for the ICU4J downloads. ICU4J is
an optional jar that will give you better collation of index entries.
To install and use with the Open Toolkit's distribution,
1. Install the DITA Open Toolkit.
2. Unzip this plugin into an Open Toolkit installation's
demo directory.
3. Install Apache FOP into demo/fo/fop. The minimum requirements are to place
fop.jar into demo/fo/fop/build/ and all library jar files provided in Apache
FOP package into demo/fo/fop/lib/.
4. Copy "fop.xconf", which is shipped together within the Apache FOP package
in the conf directory, to demo/fo/fop/conf/.
5. Edit the copied fop.xconf, add this line:
false
below the line ".". Save and close fop.xconf.
6. If you are using JDK 1.5, install saxon.jar in FO plug-in's library directory demo/fo/lib/.
7. Install the ICU4j jar (optional) into OT's library directory lib/icu4j.jar
8. From the Open Toolkit directory, run "ant -f integrator.xml"
At this point, the FO output is fully integrated into the Open
Toolkit's pipeline. The plugin infrastructure will detect the FO
plugin and provide a "pdf" output: this will invoke this FO
output instead of the previous FOP-based output. Invoke with a command
line like:
java -jar lib/dost.jar /i:doc/DITA-readme.ditamap /transtype:pdf
If you are using the startcmd.bat/sh script, make sure the classpath in that
script lists saxon.jar before xalan.jar.
About the index extensions
==========================
The index generation feature adds extensions to DITA's indexterm that can be
expressed as content of that element. These extensions are expressed in a
FrameMaker-like syntax in the element's textual content, and provide
functionality not yet available in the standard indexterm element. They also
help migration from legacy FrameMaker content. For example, the following
generates a "see also" entry:
Carp:<$nopage>see also Goldfish
As:
Carp, 34
see also Goldfish
The extended syntax consists of:
: (colon) Separates levels in an entry
; (semicolon) Separates entries in a marker
[] (brackets) Specifies a special sort order for the entry
<$startrange> Indicates the beginning of a page range
<$endrange> Indicates the end of a page range
<$nopage> Suppresses the page number in the entry (for example, in
a See entry)
<$singlepage> In a marker that contains several entries, restores the
page number for an entry that follows a <$nopage>
building block
DITA 1.1 indexing elements have been implemented in this plugin that
should make these extensions unnecessary. You can now express see/see
also, sort order and page ranges using standard DITA 1.1 elements.
About /Customization
====================
This directory is where the custom files live that make up customized
versions of the FO publishing outputs. Idiom's FO publishing output will
look for certain files here to override the standard ones. Things you can
currently override include:
- Custom XSL via fo/xsl/custom.xsl and fo/attrs/custom.xsl
- Layout overrides via fo/layout-masters.xml
- Font overrides via fo/font-mappings.xml
- Per-locale variable overrides via common/vars/[locale].xml
- I18N configuration via fo/i18n/[locale].xml
- Index configuration via fo/index/[locale].xml
When customizing any of these areas, modify the relevant file(s) in
/Customization. Then, to enable the changes in the publishing process,
you find the corresponding entry for each file you modified in
/Customization/catalog.xml. It should look like this:
Remove the comment markers "!--" and "--" to enable the change:
Your customization should now be enabled as part of the publishing process.
Idiom has provided template files that you can start with throughout
this directory structure. These files end in the suffix ".orig" (for
example, "catalog.xml.orig"). To enable these files, make a copy of
them and remove the ".orig" suffix. For example, copy
"catalog.xml.orig" to "catalog.xml". You can then make modifications
to the copy.
Idiom's FO output also provides a general configuration file called
"build.properties" that allows you to control the publishing process.
To modify these settings, copy "build.properties.orig" to
"build.properties" and then modify the relevant options.
History
=======
FO Plugin Release 1.4.3
Available since
Sourceforge bug fixes:
- 1803111: Idiom plug fails when processing bookmap with DITA composite
- 1930201: FO 1.4.2 doesn't fail correctly when called from Ant
- 1829816: Value of otherprops is written as a text element
- 1942252: should come before TOC in PDF output
----------------------------------------------------------------------------
FO Plugin Release 1.4.2
Available since Feb 26, 2008
- Misc internal fixes.
Sourceforge bug fixes:
- 1710233: summary element in bookmeta not handled properly (15251)
- 1744350: Navtitle not supported in PDF2
- 1807277: FO topicmerge needs to discard reltables
----------------------------------------------------------------------------
FO Plugin Release 1.4.1
Available since Oct 5, 2007
- more flexible index configuration (see common/index/zh_CN.xml for example)
Sourceforge bug fixes:
- 1793307: issue with topicref in bookmap's (16587)
- 1791403: invalid column-width attribute value (16586)
- 1805389: XSLT errors in FO plugin
- 1694607: Use-by-reference footnotes not rendered correctly (15249), (not quite right).
----------------------------------------------------------------------------
FO Plugin Release 1.4
- Rebased with Idiom's internal code as of August 28, 2007.
- Updated DITA 1.1 support: new bookmap and indexing elements.
- Minor fixes
Sourceforge bug fixes:
- 1686323: Idiom FO plug-in fails during pdf2 build (15348)
- 1729594: Topichead not supported in pdf2 output (15247)
- 1647267: Single-step tasks numbers the step (15248)
----------------------------------------------------------------------------
FO Plugin Release 1.2.1
- rebased with Idiom's internal code as of Nov 6, 2006.
- updated copyright/licensing notices in files.
- fixed image copying task for customization.
Sourceforge bug fixes:
- 1574115: Using 1.3 and Idiom FO 1.2 plugin fail
- 1523653: pdf2 transform assumes basedir = ditadir (for real, this time!)
----------------------------------------------------------------------------
FO Plugin Release 1.2
Available since Sept 29, 2006
- rebased with Idiom's internal code as of Sept 28, 2006
- removed icu4j requirement: it will be used if found, otherwise the built-in
Java Collator will be used.
- some preliminary DITA 1.1 support. No point going into details since the
standard is still in flux.
Bug fixes (IDs are Idiom's internal tracking numbers):
- 11492: image sometimes indented too far right
- 11625: footnote text's formatting not rendered
- 10955: tables with titles should be numbered sequentially
- 11273: table col span @namest/@nameend not respected
- 11432:
* Respresents the Adobe Framemaker's index entry
* See "Adobe Framemaker 7.1" help, topic "Adding index markers" (page is "1_15_8_0.html") for details
*/
public interface IndexEntry {
/**
* @return index reference ids
*/
public String[] getRefIDs();
/**
* @return index entry value
*/
public String getValue();
/**
* @return index entry "so value". "So value" is a value used in Japanese entries to help computer to sort the index
* strings properly. In other words it specifies string used to sort entries. It called "so value" because the syntax
* to specify it within strings is following: "index string valueindex string pronunciation"
* (h.e. after the "" tag there is a "so value"). These so strings is being inserted either by the authors
* or by the automatic translation tools.
*/
public String getSoValue();
/**
* @return The string with formatting
* See "Adobe Framemaker 7.1" help, topic "Adding index markers" (page is "1_15_8_0.html") for details
*/
public String getFormattedString();
/**
* @return the sort string for the entry
* See "Adobe Framemaker 7.1" help, topic "Adding index markers" (page is "1_15_8_0.html") for details
*/
public String getSortString();
/**
* @return child entries of this entry
*/
public IndexEntry[] getChildIndexEntries();
/**
* @return if this entry starts range
* See "Adobe Framemaker 7.1" help, topic "Adding index markers" (page is "1_15_8_0.html") for details
*/
public boolean isStartingRange();
/**
* @return if this entry ends range
* See "Adobe Framemaker 7.1" help, topic "Adding index markers" (page is "1_15_8_0.html") for details
*/
public boolean isEndingRange();
/**
* @return if this entry suppresses page number
* See "Adobe Framemaker 7.1" help, topic "Adding index markers" (page is "1_15_8_0.html") for details
*/
public boolean isSuppressesThePageNumber();
/**
* @return if this entry restores page number
* See "Adobe Framemaker 7.1" help, topic "Adding index markers" (page is "1_15_8_0.html") for details
*/
public boolean isRestoresPageNumber();
/**
* Adds reference id to the index entry
*
* @param theID reference id
*/
void addRefID(String theID);
/**
* Adds child to the entry
*
* @param theEntry index entry
*/
void addChild(IndexEntry theEntry);
/**
* Sets if the index entry restores page number
* See "Adobe Framemaker 7.1" help, topic "Adding index markers" (page is "1_15_8_0.html") for details
*
* @param theRestoresPageNumber
*/
void setRestoresPageNumber(boolean theRestoresPageNumber);
/**
* Sets if the index entry suppresses page number
* See "Adobe Framemaker 7.1" help, topic "Adding index markers" (page is "1_15_8_0.html") for details
*
* @param theSuppressesThePageNumber
*/
void setSuppressesThePageNumber(boolean theSuppressesThePageNumber);
/**
* Sets if the index entry starts range
* See "Adobe Framemaker 7.1" help, topic "Adding index markers" (page is "1_15_8_0.html") for details
*
* @param theStartRange
*/
void setStartRange(boolean theStartRange);
/**
* Sets if the index entry ends range
* See "Adobe Framemaker 7.1" help, topic "Adding index markers" (page is "1_15_8_0.html") for details
*
* @param theEndsRange
*/
void setEndsRange(boolean theEndsRange);
/**
* Sets so value
*
* @param theSoValue
*/
void setSoValue(String theSoValue);
/**
* Sets sort string for the value
*
* @param theSortString
*/
void setSortString(String theSortString);
void addSeeChild(IndexEntry theEntry);
void addSeeAlsoChild(IndexEntry theEntry);
public IndexEntry[] getSeeChildIndexEntries();
public IndexEntry[] getSeeAlsoChildIndexEntries();
}
dita-ot-1.5.3/demo/fo/src/com/idiominc/ws/opentopic/fo/index2/IndexEntryFoundListener.java 0000664 0000000 0000000 00000003621 11671002146 0031435 0 ustar 00root root 0000000 0000000 package com.idiominc.ws.opentopic.fo.index2;
/*
Copyright � 2004-2006 by Idiom Technologies, Inc. All rights reserved.
IDIOM is a registered trademark of Idiom Technologies, Inc. and WORLDSERVER
and WORLDSTART are trademarks of Idiom Technologies, Inc. All other
trademarks are the property of their respective owners.
IDIOM TECHNOLOGIES, INC. IS DELIVERING THE SOFTWARE "AS IS," WITH
ABSOLUTELY NO WARRANTIES WHATSOEVER, WHETHER EXPRESS OR IMPLIED, AND IDIOM
TECHNOLOGIES, INC. DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE AND WARRANTY OF NON-INFRINGEMENT. IDIOM TECHNOLOGIES, INC. SHALL NOT
BE LIABLE FOR INDIRECT, INCIDENTAL, SPECIAL, COVER, PUNITIVE, EXEMPLARY,
RELIANCE, OR CONSEQUENTIAL DAMAGES (INCLUDING BUT NOT LIMITED TO LOSS OF
ANTICIPATED PROFIT), ARISING FROM ANY CAUSE UNDER OR RELATED TO OR ARISING
OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE, EVEN IF IDIOM
TECHNOLOGIES, INC. HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Idiom Technologies, Inc. and its licensors shall not be liable for any
damages suffered by any person as a result of using and/or modifying the
Software or its derivatives. In no event shall Idiom Technologies, Inc.'s
liability for any damages hereunder exceed the amounts received by Idiom
Technologies, Inc. as a result of this transaction.
These terms and conditions supersede the terms and conditions in any
licensing agreement to the extent that such terms and conditions conflict
with those set forth herein.
This file is part of the DITA Open Toolkit project hosted on Sourceforge.net.
See the accompanying license.txt file for applicable licenses.
*/
public interface IndexEntryFoundListener {
/**
* Notifies that the new index entry was found
*
* @param theEntry index entry
*/
void foundEntry(IndexEntry theEntry);
}
dita-ot-1.5.3/demo/fo/src/com/idiominc/ws/opentopic/fo/index2/IndexGroup.java 0000664 0000000 0000000 00000004156 11671002146 0026732 0 ustar 00root root 0000000 0000000 package com.idiominc.ws.opentopic.fo.index2;
/*
Copyright � 2004-2006 by Idiom Technologies, Inc. All rights reserved.
IDIOM is a registered trademark of Idiom Technologies, Inc. and WORLDSERVER
and WORLDSTART are trademarks of Idiom Technologies, Inc. All other
trademarks are the property of their respective owners.
IDIOM TECHNOLOGIES, INC. IS DELIVERING THE SOFTWARE "AS IS," WITH
ABSOLUTELY NO WARRANTIES WHATSOEVER, WHETHER EXPRESS OR IMPLIED, AND IDIOM
TECHNOLOGIES, INC. DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE AND WARRANTY OF NON-INFRINGEMENT. IDIOM TECHNOLOGIES, INC. SHALL NOT
BE LIABLE FOR INDIRECT, INCIDENTAL, SPECIAL, COVER, PUNITIVE, EXEMPLARY,
RELIANCE, OR CONSEQUENTIAL DAMAGES (INCLUDING BUT NOT LIMITED TO LOSS OF
ANTICIPATED PROFIT), ARISING FROM ANY CAUSE UNDER OR RELATED TO OR ARISING
OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE, EVEN IF IDIOM
TECHNOLOGIES, INC. HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Idiom Technologies, Inc. and its licensors shall not be liable for any
damages suffered by any person as a result of using and/or modifying the
Software or its derivatives. In no event shall Idiom Technologies, Inc.'s
liability for any damages hereunder exceed the amounts received by Idiom
Technologies, Inc. as a result of this transaction.
These terms and conditions supersede the terms and conditions in any
licensing agreement to the extent that such terms and conditions conflict
with those set forth herein.
This file is part of the DITA Open Toolkit project hosted on Sourceforge.net.
See the accompanying license.txt file for applicable licenses.
*/
/**
* User: Ivan Luzyanin
* Date: 21.06.2005
* Time: 10:38:48
*
* Respresents index group.
*/
public interface IndexGroup {
/**
* @return group label
*/
String getLabel();
/**
* @return group entries
*/
IndexEntry[] getEntries();
/**
* Adds entry to the index group
*
* @param theEntry index entry
*/
void addEntry(IndexEntry theEntry);
}
dita-ot-1.5.3/demo/fo/src/com/idiominc/ws/opentopic/fo/index2/IndexGroupProcessor.java 0000664 0000000 0000000 00000031770 11671002146 0030634 0 ustar 00root root 0000000 0000000 package com.idiominc.ws.opentopic.fo.index2;
import com.ibm.icu.text.Collator;
import com.idiominc.ws.opentopic.fo.index2.configuration.ConfigEntry;
import com.idiominc.ws.opentopic.fo.index2.configuration.IndexConfiguration;
import java.util.ArrayList;
import java.util.HashMap;
import java.util.Locale;
import java.util.Set;
/*
Copyright � 2004-2006 by Idiom Technologies, Inc. All rights reserved.
IDIOM is a registered trademark of Idiom Technologies, Inc. and WORLDSERVER
and WORLDSTART are trademarks of Idiom Technologies, Inc. All other
trademarks are the property of their respective owners.
IDIOM TECHNOLOGIES, INC. IS DELIVERING THE SOFTWARE "AS IS," WITH
ABSOLUTELY NO WARRANTIES WHATSOEVER, WHETHER EXPRESS OR IMPLIED, AND IDIOM
TECHNOLOGIES, INC. DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE AND WARRANTY OF NON-INFRINGEMENT. IDIOM TECHNOLOGIES, INC. SHALL NOT
BE LIABLE FOR INDIRECT, INCIDENTAL, SPECIAL, COVER, PUNITIVE, EXEMPLARY,
RELIANCE, OR CONSEQUENTIAL DAMAGES (INCLUDING BUT NOT LIMITED TO LOSS OF
ANTICIPATED PROFIT), ARISING FROM ANY CAUSE UNDER OR RELATED TO OR ARISING
OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE, EVEN IF IDIOM
TECHNOLOGIES, INC. HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Idiom Technologies, Inc. and its licensors shall not be liable for any
damages suffered by any person as a result of using and/or modifying the
Software or its derivatives. In no event shall Idiom Technologies, Inc.'s
liability for any damages hereunder exceed the amounts received by Idiom
Technologies, Inc. as a result of this transaction.
These terms and conditions supersede the terms and conditions in any
licensing agreement to the extent that such terms and conditions conflict
with those set forth herein.
This file is part of the DITA Open Toolkit project hosted on Sourceforge.net.
See the accompanying license.txt file for applicable licenses.
*/
public class IndexGroupProcessor {
/**
* Puts index entries to the group they are belongs
*
* @param theIndexEntries index entries
* @param theIndexConfiguration index configuration
* @param theLocale locale used to sort and compare index entries
* @return groups with sorted index entries inside
*/
public static IndexGroup[] process(IndexEntry[] theIndexEntries, IndexConfiguration theIndexConfiguration,
Locale theLocale) {
final IndexCollator collator = new IndexCollator(theLocale);
ArrayList result = new ArrayList();
final ConfigEntry[] entries = theIndexConfiguration.getEntries();
HashMap indexMap = createMap(theIndexEntries);
//Creating array of index groups
for (int i = 0; i < entries.length; i++) {
ConfigEntry configEntry = entries[i];
final String label = configEntry.getLabel();
MyIndexGroup group = new MyIndexGroup(label,configEntry);
result.add(group);
}
MyIndexGroup[] IndexGroups = (MyIndexGroup[]) result.toArray(new MyIndexGroup[result.size()]);
//Adding dependecies to group array
for (int i = 0; i < IndexGroups.length; i++) {
MyIndexGroup thisGroup = IndexGroups[i];
String[] thisGroupMembers = thisGroup.getConfigEntry().getGroupMembers();
for (int j = 0; j < IndexGroups.length; j++) {
if (j != i) {
MyIndexGroup compGroup = IndexGroups[j];
String[] compGroupMembers = compGroup.getConfigEntry().getGroupMembers();
if (doesStart(compGroupMembers, thisGroupMembers)) {
thisGroup.addChild(compGroup);
}
}
}
}
/*
for (int i = 0; i < IndexGroups.length; i++) {
IndexGroups[i].printDebug();
}
*/
for (int i = 0; i < IndexGroups.length; i++) {
MyIndexGroup group = IndexGroups[i];
ConfigEntry configEntry = group.getConfigEntry();
final String[] groupMembers = configEntry.getGroupMembers();
if (groupMembers.length > 0) {
//Find entries by comaping first letter with a chars in current config entry
final Set set = indexMap.keySet();
final Object[] keys = (Object[]) set.toArray(new Object[set.size()]);
for (int j = 0; j < keys.length; j++) {
String key = (String) keys[j];
if (key.length() > 0) {
String value = getValue((IndexEntry) indexMap.get(key));
// final char c = value.charAt(0);
if (configEntry.isInRange(value,collator)) {
final IndexEntry entry = (IndexEntry) indexMap.remove(key);
group.addEntry(entry);
}
}
}
} else {
//Get index entries by range specified by two keys
final String key1 = configEntry.getKey();
String key2 = null;
if ((i + 1) < entries.length) {
final ConfigEntry nextEntry = entries[i + 1];
key2 = nextEntry.getKey();
}
String[] indexMapKeys = getIndexKeysOfIndexesInRange(key1, key2, collator, indexMap);
for (int j = 0; j < indexMapKeys.length; j++) {
//Add entry to the group
String mapKey = indexMapKeys[j];
final IndexEntry entry = (IndexEntry) indexMap.remove(mapKey);
group.addEntry(entry);
}
}
/*
if (group.getEntries().length > 0) {
result.add(group);
}
*/
}
if (!indexMap.isEmpty()) {
final Set set = indexMap.keySet();
final Object[] keys = (Object[]) set.toArray(new Object[set.size()]);
for (int j = 0; j < keys.length; j++) {
String key = (String) keys[j];
if (key.length() > 0) {
final IndexEntry entry = (IndexEntry) indexMap.get(key);
System.out.println("[ERROR] Index entry '"+entry.toString()+"' is dropped, because corresponding group is not found");
}
}
if (IndexPreprocessorTask.failOnError) {
System.out.println("[ERROR] Build stopped. Problems occured during Index preprocess task. Please check the messages above.");
IndexPreprocessorTask.processingFaild=true;
}
}
ArrayList cleanResult = new ArrayList();
for (int i = 0; i < IndexGroups.length; i++) {
if (IndexGroups[i].getEntries().length > 0) {
cleanResult.add(IndexGroups[i]);
}
}
MyIndexGroup[] cleanIndexGroups = (MyIndexGroup[]) cleanResult.toArray(new MyIndexGroup[cleanResult.size()]);
return (IndexGroup[]) cleanIndexGroups;
}
private static String getValue(IndexEntry theEntry) {
//The so-value has higher priority
final String soValue = theEntry.getSoValue();
final String sortValue = theEntry.getSortString();
if (sortValue != null && sortValue.length() > 0) {
return sortValue;
} else if (soValue != null && soValue.length() > 0) {
return soValue;
} else return theEntry.getValue();
}
private static String[] getIndexKeysOfIndexesInRange(String theKey1, String theKey2, IndexCollator theCollator, HashMap theIndexEntryMap) {
final Set set = theIndexEntryMap.keySet();
final String[] allKeys = (String[]) set.toArray(new String[0]);
ArrayList res = new ArrayList();
for (int i = 0; i < allKeys.length; i++) {
String key = allKeys[i];
String value = getValue((IndexEntry) theIndexEntryMap.get(key));
final int res1 = theCollator.compare(theKey1, value);
if (res1 <= 0) {
if (theKey2 == null) {
//the right range is not specified
res.add(key);
continue;
}
final int res2 = theCollator.compare(theKey2, key);
if (res2 > 0) {
res.add(key);
}
}
}
return (String[]) res.toArray(new String[res.size()]);
}
private static boolean doesStart(String sourceString, String[] compStrings) {
for (int i = 0; i < compStrings.length; i++) {
if (sourceString.startsWith(compStrings[i])) {
return true;
}
}
return false;
}
private static boolean doesStart(String[] sourceStrings, String[] compStrings) {
for (int i = 0; i < sourceStrings.length; i++) {
String sourceString = sourceStrings[i];
for (int j = 0; j < compStrings.length; j++) {
if (sourceString.startsWith(compStrings[j]) && !sourceString.equals(compStrings[j])) {
return true;
}
}
}
return false;
}
private static HashMap createMap(IndexEntry[] theIndexEntries) {
HashMap map = new HashMap();
for (int i = 0; i < theIndexEntries.length; i++) {
IndexEntry indexEntry = theIndexEntries[i];
String value = indexEntry.getValue();
if (!map.containsKey(value)) {
map.put(value, indexEntry);
} else {
final IndexEntry existingEntry = (IndexEntry) map.get(value);
final IndexEntry[] childIndexEntries = indexEntry.getChildIndexEntries();
for (int j = 0; j < childIndexEntries.length; j++) {
IndexEntry childIndexEntry = childIndexEntries[j];
existingEntry.addChild(childIndexEntry);
}
final IndexEntry[] seeChildIndexEntries = indexEntry.getSeeChildIndexEntries();
for (int j = 0;seeChildIndexEntries != null && j < seeChildIndexEntries.length; j++) {
IndexEntry seeChildIndexEntry = seeChildIndexEntries[j];
existingEntry.addSeeChild(seeChildIndexEntry);
}
final IndexEntry[] seeAlsoChildIndexEntries = indexEntry.getSeeAlsoChildIndexEntries();
for (int j = 0;seeAlsoChildIndexEntries != null && j < seeAlsoChildIndexEntries.length; j++) {
IndexEntry seeAlsoChildIndexEntry = seeAlsoChildIndexEntries[j];
existingEntry.addSeeAlsoChild(seeAlsoChildIndexEntry);
}
//supress some attributes of given entry to the existing one
if (indexEntry.isRestoresPageNumber()) {
existingEntry.setRestoresPageNumber(true);
}
final String[] refIDs = indexEntry.getRefIDs();
if (refIDs.length > 0) {
for (int j = 0; j < refIDs.length; j++) {
String refID = refIDs[j];
existingEntry.addRefID(refID);
}
}
if (!indexEntry.isSuppressesThePageNumber()) {
existingEntry.setSuppressesThePageNumber(false);
}
if (indexEntry.isStartingRange()) {
existingEntry.setStartRange(true);
}
}
}
return map;
}
private static class MyIndexGroup
implements IndexGroup {
private String label;
private ConfigEntry configEntry;
private ArrayList entries = new ArrayList();
private ArrayList childList = new ArrayList();
public MyIndexGroup(String theLabel, ConfigEntry theConfigEntry) {
this.label = theLabel;
this.configEntry = theConfigEntry;
}
public String getLabel() {
return this.label;
}
public IndexEntry[] getEntries() {
return (IndexEntry[]) entries.toArray(new IndexEntry[entries.size()]);
}
public ConfigEntry getConfigEntry() {
return this.configEntry;
}
public void addEntry(IndexEntry theEntry) {
boolean isInserted = false;
if (!childList.isEmpty()) {
// MyIndexGroup[] childGroupList = (MyIndexGroup[]) childList.toArray(new MyIndexGroup[childList.size()]);
for (int i = 0; i < childList.size() && !isInserted;i++) {
MyIndexGroup thisChild = (MyIndexGroup) childList.get(i);
String[] thisGroupMembers = thisChild.getConfigEntry().getGroupMembers();
if (doesStart(theEntry.getValue(),thisGroupMembers)) {
thisChild.addEntry(theEntry);
isInserted = true;
}
}
}
if (!isInserted) this.entries.add(theEntry);
}
public void addChild(MyIndexGroup theIndexGroup) {
if (!this.childList.contains(theIndexGroup))
this.childList.add(theIndexGroup);
// MyIndexGroup[] childGroupList = (MyIndexGroup[]) childList.toArray(new MyIndexGroup[childList.size()]);
for (int i = 0; i < childList.size(); i++) {
MyIndexGroup thisChild = (MyIndexGroup) childList.get(i);
for (int j = 0; j < childList.size(); j++) {
if (i != j) {
MyIndexGroup compChild = (MyIndexGroup) childList.get(j);
String[] thisGroupMembers = thisChild.getConfigEntry().getGroupMembers();
String[] compGroupMembers = compChild.getConfigEntry().getGroupMembers();
if (doesStart(thisGroupMembers, compGroupMembers)) {
this.childList.remove(thisChild);
compChild.addChild(thisChild);
}
}
}
}
}
public void removeChild(MyIndexGroup theIndexGroup) {
this.childList.remove(theIndexGroup);
}
}
}
dita-ot-1.5.3/demo/fo/src/com/idiominc/ws/opentopic/fo/index2/IndexPreprocessResult.java 0000664 0000000 0000000 00000004203 11671002146 0031153 0 ustar 00root root 0000000 0000000 package com.idiominc.ws.opentopic.fo.index2;
import org.w3c.dom.Document;
/*
Copyright � 2004-2006 by Idiom Technologies, Inc. All rights reserved.
IDIOM is a registered trademark of Idiom Technologies, Inc. and WORLDSERVER
and WORLDSTART are trademarks of Idiom Technologies, Inc. All other
trademarks are the property of their respective owners.
IDIOM TECHNOLOGIES, INC. IS DELIVERING THE SOFTWARE "AS IS," WITH
ABSOLUTELY NO WARRANTIES WHATSOEVER, WHETHER EXPRESS OR IMPLIED, AND IDIOM
TECHNOLOGIES, INC. DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE AND WARRANTY OF NON-INFRINGEMENT. IDIOM TECHNOLOGIES, INC. SHALL NOT
BE LIABLE FOR INDIRECT, INCIDENTAL, SPECIAL, COVER, PUNITIVE, EXEMPLARY,
RELIANCE, OR CONSEQUENTIAL DAMAGES (INCLUDING BUT NOT LIMITED TO LOSS OF
ANTICIPATED PROFIT), ARISING FROM ANY CAUSE UNDER OR RELATED TO OR ARISING
OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE, EVEN IF IDIOM
TECHNOLOGIES, INC. HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Idiom Technologies, Inc. and its licensors shall not be liable for any
damages suffered by any person as a result of using and/or modifying the
Software or its derivatives. In no event shall Idiom Technologies, Inc.'s
liability for any damages hereunder exceed the amounts received by Idiom
Technologies, Inc. as a result of this transaction.
These terms and conditions supersede the terms and conditions in any
licensing agreement to the extent that such terms and conditions conflict
with those set forth herein.
This file is part of the DITA Open Toolkit project hosted on Sourceforge.net.
See the accompanying license.txt file for applicable licenses.
*/
public class IndexPreprocessResult {
private Document document;
private IndexEntry[] indexEntries;
public IndexPreprocessResult(Document theDocument, IndexEntry[] theIndexEntries) {
document = theDocument;
indexEntries = theIndexEntries;
}
public Document getDocument() {
return document;
}
public IndexEntry[] getIndexEntries() {
return indexEntries;
}
}
dita-ot-1.5.3/demo/fo/src/com/idiominc/ws/opentopic/fo/index2/IndexPreprocessor.java 0000664 0000000 0000000 00000044051 11671002146 0030322 0 ustar 00root root 0000000 0000000 package com.idiominc.ws.opentopic.fo.index2;
import com.idiominc.ws.opentopic.fo.index2.configuration.IndexConfiguration;
import com.idiominc.ws.opentopic.fo.index2.util.IndexStringProcessor;
import com.idiominc.ws.opentopic.fo.index2.util.IndexDitaProcessor;
import org.w3c.dom.*;
import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.parsers.ParserConfigurationException;
import java.util.*;
/*
Copyright � 2004-2006 by Idiom Technologies, Inc. All rights reserved.
IDIOM is a registered trademark of Idiom Technologies, Inc. and WORLDSERVER
and WORLDSTART are trademarks of Idiom Technologies, Inc. All other
trademarks are the property of their respective owners.
IDIOM TECHNOLOGIES, INC. IS DELIVERING THE SOFTWARE "AS IS," WITH
ABSOLUTELY NO WARRANTIES WHATSOEVER, WHETHER EXPRESS OR IMPLIED, AND IDIOM
TECHNOLOGIES, INC. DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE AND WARRANTY OF NON-INFRINGEMENT. IDIOM TECHNOLOGIES, INC. SHALL NOT
BE LIABLE FOR INDIRECT, INCIDENTAL, SPECIAL, COVER, PUNITIVE, EXEMPLARY,
RELIANCE, OR CONSEQUENTIAL DAMAGES (INCLUDING BUT NOT LIMITED TO LOSS OF
ANTICIPATED PROFIT), ARISING FROM ANY CAUSE UNDER OR RELATED TO OR ARISING
OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE, EVEN IF IDIOM
TECHNOLOGIES, INC. HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Idiom Technologies, Inc. and its licensors shall not be liable for any
damages suffered by any person as a result of using and/or modifying the
Software or its derivatives. In no event shall Idiom Technologies, Inc.'s
liability for any damages hereunder exceed the amounts received by Idiom
Technologies, Inc. as a result of this transaction.
These terms and conditions supersede the terms and conditions in any
licensing agreement to the extent that such terms and conditions conflict
with those set forth herein.
This file is part of the DITA Open Toolkit project hosted on Sourceforge.net.
See the accompanying license.txt file for applicable licenses.
*/
public class IndexPreprocessor {
private final String prefix;
private final String namespace_url;
private String elIndexName = "indexterm";
private String elIndexSortName = "index-sort-as";
private String elIndexSeeName = "index-see";
private String elIndexSeeAlsoName = "index-see-also";
private String elIndexRangeStartName = "start";
private String elIndexRangeEndName = "end";
public IndexPreprocessor(String prefix, String theNamespace_url) {
this.prefix = prefix;
this.namespace_url = theNamespace_url;
}
public IndexPreprocessor(String prefix, String theNamespace_url, String theElementIndexName) {
this.prefix = prefix;
this.namespace_url = theNamespace_url;
this.elIndexName = theElementIndexName;
}
public IndexPreprocessResult process(Document theInput)
throws ProcessException {
DocumentBuilderFactory documentBuilderFactory = DocumentBuilderFactory.newInstance();
DocumentBuilder documentBuilder = null;
try {
documentBuilder = documentBuilderFactory.newDocumentBuilder();
} catch (ParserConfigurationException e) {
e.printStackTrace();
}
Document doc = documentBuilder.newDocument();
Node rootElement = theInput.getDocumentElement();
final ArrayList indexes = new ArrayList();
IndexEntryFoundListener listener = new IndexEntryFoundListener() {
public void foundEntry(IndexEntry theEntry) {
indexes.add(theEntry);
}
};
Node node = processCurrNode(rootElement, doc, listener)[0];
doc.appendChild(node);
doc.getDocumentElement().setAttribute("xmlns:" + this.prefix, this.namespace_url);
return new IndexPreprocessResult(doc, (IndexEntry[]) indexes.toArray(new IndexEntry[0]));
}
public void createAndAddIndexGroups(final IndexEntry[] theIndexEntries, final IndexConfiguration theConfiguration, final Document theDocument, Locale theLocale) {
final IndexComparator indexEntryComparator = new IndexComparator(theLocale);
if (null == indexEntryComparator) System.out.println("Collator is not found, sort order of index group can be wrong");
final IndexGroup[] indexGroups = IndexGroupProcessor.process(theIndexEntries, theConfiguration, theLocale);
final Element rootElement = theDocument.getDocumentElement();
final Element indexGroupsElement = theDocument.createElementNS(namespace_url, "index.groups");
indexGroupsElement.setPrefix(prefix);
for (int i = 0; i < indexGroups.length; i++) {
IndexGroup group = indexGroups[i];
//Create group element
Node groupElement = theDocument.createElementNS(namespace_url, "index.group");
groupElement.setPrefix(prefix);
//Create group label element and index entry childs
Element groupLabelElement = theDocument.createElementNS(namespace_url, "label");
groupLabelElement.setPrefix(prefix);
groupLabelElement.appendChild(theDocument.createTextNode(group.getLabel()));
groupElement.appendChild(groupLabelElement);
Node[] entryNodes = transformToNodes(group.getEntries(), theDocument, indexEntryComparator);
for (int j = 0; j < entryNodes.length; j++) {
Node entryNode = entryNodes[j];
groupElement.appendChild(entryNode);
}
indexGroupsElement.appendChild(groupElement);
}
rootElement.appendChild(indexGroupsElement);
}
/**
* Processes curr node. Copies node to the target document if its is not a text node of index entry element.
* Otherwise it process it and creates nodes with "prefix" in given "namespace_url" from the parsed index entry text.
*
* @param theNode node to process
* @param theTargetDocument target document used to import and create nodes
* @param theIndexEntryFoundListener listener to notify that new index entry was found
* @return the array of nodes after processing input node
*/
private Node[] processCurrNode(Node theNode, Document theTargetDocument, IndexEntryFoundListener theIndexEntryFoundListener) {
NodeList childNodes = theNode.getChildNodes();
if (checkElementName(theNode.getNodeName())) {
return processIndexNode(theNode, theTargetDocument, theIndexEntryFoundListener);
/*
for (int i = 0; i < childNodes.getLength(); i++) {
Node child = childNodes.item(i);
if (child.getNodeType() == Node.TEXT_NODE) { //Look for the first non-empty text node
final String normIndex = IndexStringProcessor.normalizeTextValue(child.getNodeValue());
if (normIndex.length() > 0) {
return processIndexTextNode(child, theTargetDocument, theIndexEntryFoundListener);
}
}
}
*/
} else {
Node result = theTargetDocument.importNode(theNode, false);
for (int i = 0; i < childNodes.getLength(); i++) {
Node[] processedNodes = processCurrNode(childNodes.item(i), theTargetDocument, theIndexEntryFoundListener);
for (int j = 0; j < processedNodes.length; j++) {
Node node = processedNodes[j];
result.appendChild(node);
}
}
return new Node[]{result};
}
}
private Node[] processIndexNode(Node theNode, Document theTargetDocument, IndexEntryFoundListener theIndexEntryFoundListener) {
theNode.normalize();
boolean ditastyle = false;
boolean textNode = false;
NodeList childNodes = theNode.getChildNodes();
for (int i = 0; i < childNodes.getLength(); i++) {
final Node child = childNodes.item(i);
final String nodeName = child.getNodeName();
if (checkElementName(nodeName)) {
ditastyle = true;
break;
}
if (child.getNodeType() == Node.TEXT_NODE) {
final String normIndex = IndexStringProcessor.normalizeTextValue(child.getNodeValue());
if (normIndex.length() > 0) {
textNode = true;
}
}
}
if (theNode.getAttributes().getNamedItem(elIndexRangeStartName) != null ||
theNode.getAttributes().getNamedItem(elIndexRangeEndName) != null) {
ditastyle = true;
}
String[] indexStrings;
ArrayList res = new ArrayList();
if ((ditastyle)) {
IndexEntry[] indexEntries = IndexDitaProcessor.processIndexDitaNode(theNode,"");
for (int i = 0; i < indexEntries.length; i++) {
theIndexEntryFoundListener.foundEntry(indexEntries[i]);
}
final Node[] nodes = transformToNodes(indexEntries, theTargetDocument, null);
for (int j = 0; j < nodes.length; j++) {
Node node = nodes[j];
res.add(node);
}
} else if (textNode) {
for (int k = 0; k < childNodes.getLength(); k++) {
final Node child = childNodes.item(k);
indexStrings = new String[]{child.getNodeValue()};
for (int i = 0; i < indexStrings.length; i++) {
String indexString = indexStrings[i];
final Node[] nodes = processIndexString(indexString, theTargetDocument, theIndexEntryFoundListener);
for (int j = 0; j < nodes.length; j++) {
Node node = nodes[j];
res.add(node);
}
}
}
} else return new Node[0];
return (Node[]) res.toArray(new Node[res.size()]);
}
private Node[] processIndexTextNode(Node theNode, Document theTargetDocument, IndexEntryFoundListener theIndexEntryFoundListener) {
theNode.normalize();
boolean ditastyle = false;
NodeList childNodes = theNode.getParentNode().getChildNodes();
for (int i = 0; i < childNodes.getLength(); i++) {
final Node child = childNodes.item(i);
final String nodeName = child.getNodeName();
if (checkElementName(nodeName)) {
ditastyle = true;
break;
}
}
String[] indexStrings;
ArrayList res = new ArrayList();
if ((ditastyle)) {
IndexEntry[] indexEntries = IndexDitaProcessor.processIndexDitaNode(theNode.getParentNode(),"");
for (int i = 0; i < indexEntries.length; i++) {
theIndexEntryFoundListener.foundEntry(indexEntries[i]);
}
final Node[] nodes = transformToNodes(indexEntries, theTargetDocument, null);
for (int j = 0; j < nodes.length; j++) {
Node node = nodes[j];
res.add(node);
}
} else {
indexStrings = new String[]{theNode.getNodeValue()};
for (int i = 0; i < indexStrings.length; i++) {
String indexString = indexStrings[i];
final Node[] nodes = processIndexString(indexString, theTargetDocument, theIndexEntryFoundListener);
for (int j = 0; j < nodes.length; j++) {
Node node = nodes[j];
res.add(node);
}
}
}
return (Node[]) res.toArray(new Node[res.size()]);
}
private boolean checkElementName(String nodeName) {
return elIndexName.equals(nodeName) || elIndexSortName.equals(nodeName)
|| elIndexSeeName.equals(nodeName) || elIndexSeeAlsoName.equals(nodeName);
}
private String[] createIndexStringFromDitastyleIndex(Node theNode) {
//Go through the childs and append text nodes to the index string
//Index elements on the same level will create separate index strings
ArrayList resultList = new ArrayList();
if (elIndexName.equals(theNode.getNodeName())) //Is index element?
{
StringBuffer resIndexString = new StringBuffer();
boolean skipCurrentLevel = false;
final NodeList childNodes = theNode.getChildNodes();
for (int i = 0; i < childNodes.getLength(); i++) { //Go through child nodes to find text nodes
final Node child = childNodes.item(i);
if (child.getNodeType() == Node.TEXT_NODE) {
final String val = child.getNodeValue();
if (null != val) {
resIndexString.append(val); //append to result index string
}
} else if (elIndexName.equals(child.getNodeName())) {
skipCurrentLevel = true; //skip adding current level index string because it has continuation on the descendant level
String[] indexValues = createIndexStringFromDitastyleIndex(child); //call recursevelly but for the found child
for (int j = 0; j < indexValues.length; j++) {
String indexValue = indexValues[j];
resultList.add(resIndexString.toString() + ':' + indexValue); //append to result list prefixed by current level
}
}
}
if (!skipCurrentLevel) {
//No descendant index elements were found so add this level as final
resultList.add(resIndexString.toString());
}
}
return (String[]) resultList.toArray(new String[resultList.size()]); //return result
}
/**
* Processes index string and creates nodes with "prefix" in given "namespace_url" from the parsed index entry text.
*
* @param theIndexString index string
* @param theTargetDocument target document to create new nodes
* @param theIndexEntryFoundListener listener to notify that new index entry was found
* @return the array of nodes after processing index string
*/
private Node[] processIndexString(String theIndexString, Document theTargetDocument, IndexEntryFoundListener theIndexEntryFoundListener) {
IndexEntry[] indexEntries = IndexStringProcessor.processIndexString(theIndexString);
for (int i = 0; i < indexEntries.length; i++) {
theIndexEntryFoundListener.foundEntry(indexEntries[i]);
}
return transformToNodes(indexEntries, theTargetDocument, null);
}
/**
* Creates nodes from index entries
*
* @param theIndexEntries index entries
* @param theTargetDocument target document
* @param theIndexEntryComparator comparator to sort the index entries. if it is null the index entries will be unsorted
* @return nodes for the target document
*/
private Node[] transformToNodes(IndexEntry[] theIndexEntries, Document theTargetDocument, Comparator theIndexEntryComparator) {
if (null != theIndexEntryComparator) {
Arrays.sort(theIndexEntries, theIndexEntryComparator);
}
List result = new ArrayList();
for (int i = 0; i < theIndexEntries.length; i++) {
IndexEntry indexEntry = theIndexEntries[i];
Element indexEntryNode = createElement(theTargetDocument, "index.entry");
Element formattedStringElement = createElement(theTargetDocument, "formatted-value");
Text textNode = theTargetDocument.createTextNode(indexEntry.getFormattedString());
textNode.normalize();
formattedStringElement.appendChild(textNode);
indexEntryNode.appendChild(formattedStringElement);
String[] refIDs = indexEntry.getRefIDs();
for (int j = 0; j < refIDs.length; j++) {
String refID = refIDs[j];
final Element referenceIDElement = createElement(theTargetDocument, "refID");
referenceIDElement.setAttribute("value", refID);
indexEntryNode.appendChild(referenceIDElement);
}
String val = indexEntry.getValue();
if (null != val) {
indexEntryNode.setAttribute("value", val);
}
String so = indexEntry.getSoValue();
if (null != so) {
indexEntryNode.setAttribute("SO", so);
}
String sort = indexEntry.getSortString();
if (null != sort) {
indexEntryNode.setAttribute("sort-string", sort);
}
if (indexEntry.isStartingRange()) {
indexEntryNode.setAttribute("start-range", "true");
} else if (indexEntry.isEndingRange()) {
indexEntryNode.setAttribute("end-range", "true");
}
if (indexEntry.isSuppressesThePageNumber()) {
indexEntryNode.setAttribute("no-page", "true");
} else if (indexEntry.isRestoresPageNumber()) {
indexEntryNode.setAttribute("single-page", "true");
}
final IndexEntry[] childIndexEntries = indexEntry.getChildIndexEntries();
Node[] nodes = transformToNodes(childIndexEntries, theTargetDocument, theIndexEntryComparator);
for (int j = 0; j < nodes.length; j++) {
Node node = nodes[j];
indexEntryNode.appendChild(node);
}
IndexEntry[] seeChildIndexEntries = indexEntry.getSeeChildIndexEntries();
if (seeChildIndexEntries != null) {
Element seeElement = createElement(theTargetDocument, "see-childs");
Node[] seeNodes = transformToNodes(seeChildIndexEntries, theTargetDocument, theIndexEntryComparator);
for (int j = 0; j < seeNodes.length; j++) {
Node node = seeNodes[j];
seeElement.appendChild(node);
}
indexEntryNode.appendChild(seeElement);
}
IndexEntry[] seeAlsoChildIndexEntries = indexEntry.getSeeAlsoChildIndexEntries();
if (seeAlsoChildIndexEntries != null) {
Element seeAlsoElement = createElement(theTargetDocument, "see-also-childs");
Node[] seeAlsoNodes = transformToNodes(seeAlsoChildIndexEntries, theTargetDocument, theIndexEntryComparator);
for (int j = 0; j < seeAlsoNodes.length; j++) {
Node node = seeAlsoNodes[j];
seeAlsoElement.appendChild(node);
}
indexEntryNode.appendChild(seeAlsoElement);
}
result.add(indexEntryNode);
}
return (Node[]) result.toArray(new Node[result.size()]);
}
/**
* Creates element with "prefix" in "namespace_url" with given name for the target document
*
* @param theTargetDocument target document
* @param theName name
* @return new element
*/
private Element createElement(Document theTargetDocument, String theName) {
Element indexEntryNode = theTargetDocument.createElementNS(this.namespace_url, theName);
indexEntryNode.setPrefix(this.prefix);
return indexEntryNode;
}
}
dita-ot-1.5.3/demo/fo/src/com/idiominc/ws/opentopic/fo/index2/IndexPreprocessorTask.java 0000664 0000000 0000000 00000016400 11671002146 0031142 0 ustar 00root root 0000000 0000000 package com.idiominc.ws.opentopic.fo.index2;
import com.idiominc.ws.opentopic.fo.index2.configuration.IndexConfiguration;
import org.apache.tools.ant.BuildException;
import org.apache.tools.ant.Task;
import org.apache.tools.ant.Project;
import org.apache.xml.resolver.tools.CatalogResolver;
import org.w3c.dom.Document;
import org.xml.sax.InputSource;
import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.transform.OutputKeys;
import javax.xml.transform.Transformer;
import javax.xml.transform.TransformerFactory;
import javax.xml.transform.dom.DOMSource;
import javax.xml.transform.stream.StreamResult;
import java.io.FileOutputStream;
import java.util.Locale;
/*
Copyright � 2004-2006 by Idiom Technologies, Inc. All rights reserved.
IDIOM is a registered trademark of Idiom Technologies, Inc. and WORLDSERVER
and WORLDSTART are trademarks of Idiom Technologies, Inc. All other
trademarks are the property of their respective owners.
IDIOM TECHNOLOGIES, INC. IS DELIVERING THE SOFTWARE "AS IS," WITH
ABSOLUTELY NO WARRANTIES WHATSOEVER, WHETHER EXPRESS OR IMPLIED, AND IDIOM
TECHNOLOGIES, INC. DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE AND WARRANTY OF NON-INFRINGEMENT. IDIOM TECHNOLOGIES, INC. SHALL NOT
BE LIABLE FOR INDIRECT, INCIDENTAL, SPECIAL, COVER, PUNITIVE, EXEMPLARY,
RELIANCE, OR CONSEQUENTIAL DAMAGES (INCLUDING BUT NOT LIMITED TO LOSS OF
ANTICIPATED PROFIT), ARISING FROM ANY CAUSE UNDER OR RELATED TO OR ARISING
OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE, EVEN IF IDIOM
TECHNOLOGIES, INC. HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Idiom Technologies, Inc. and its licensors shall not be liable for any
damages suffered by any person as a result of using and/or modifying the
Software or its derivatives. In no event shall Idiom Technologies, Inc.'s
liability for any damages hereunder exceed the amounts received by Idiom
Technologies, Inc. as a result of this transaction.
These terms and conditions supersede the terms and conditions in any
licensing agreement to the extent that such terms and conditions conflict
with those set forth herein.
This file is part of the DITA Open Toolkit project hosted on Sourceforge.net.
See the accompanying license.txt file for applicable licenses.
*/
public class IndexPreprocessorTask
extends Task {
// private String input = null;
private String input = "";
private String output = "";
private String catalogs = null;
private String locale = "ja";
private String indexConfig = "";
public static boolean failOnError = false;
public static boolean processingFaild = false;
private String prefix = "opentopic-index";
private String namespace_url = "http://www.idiominc.com/opentopic/index";
private String indexElementName = "indexterm";
public static void main(String[] args) {
new IndexPreprocessorTask().execute();
}
public void execute()
throws BuildException {
checkParameters();
if (this.catalogs != null) {
System.setProperty("xml.catalog.files", this.catalogs);
}
try {
DocumentBuilderFactory documentBuilderFactory = DocumentBuilderFactory.newInstance();
DocumentBuilder documentBuilder = documentBuilderFactory.newDocumentBuilder();
documentBuilder.setEntityResolver(new CatalogResolver() {
public InputSource resolveEntity(String publicId, String systemId) {
// strip path from DTD location
int slashIdx = systemId.lastIndexOf("/");
if (slashIdx >= 0) {
systemId = systemId.substring(slashIdx + 1);
}
// resolve real location with XMLCatalogResolver
return super.resolveEntity(publicId, systemId);
}
});
Document doc = documentBuilder.parse(input);
IndexPreprocessor preprocessor = new IndexPreprocessor(this.prefix, this.namespace_url, this.indexElementName);
// Walks through source document and builds an array of IndexEntry and builds
// new Document with pre-processed index entries included.
IndexPreprocessResult result = preprocessor.process(doc);
final Document resultDoc = result.getDocument();
// Parse index configuration from file specified from ANT script
final IndexConfiguration configuration = IndexConfiguration.parse(documentBuilder.parse(this.indexConfig));
final IndexEntry[] indexEntries = result.getIndexEntries();
Locale loc;
// Split passed locale string to lang and country codes
if (locale.indexOf("-") == 2 || locale.indexOf("_") == 2) {
loc = new Locale(locale.substring(0, 2), locale.substring(3));
} else {
loc = new Locale(this.locale);
}
// Append index groups to the end of document
preprocessor.createAndAddIndexGroups(indexEntries, configuration, resultDoc, loc);
if (processingFaild) {
setActiveProjectProperty("ws.runtime.index.preprocess.fail","true");
}
// Serialize processed document
TransformerFactory transformerFactory = TransformerFactory.newInstance();
Transformer transformer = transformerFactory.newTransformer();
transformer.setOutputProperty(OutputKeys.OMIT_XML_DECLARATION, "no");
transformer.setOutputProperty(OutputKeys.INDENT, "no");
transformer.setOutputProperty(OutputKeys.ENCODING, "UTF-8");
transformer.setOutputProperty(OutputKeys.STANDALONE, "yes");
if (doc.getDoctype() != null) {
if (null != doc.getDoctype().getPublicId()) {
transformer.setOutputProperty(OutputKeys.DOCTYPE_PUBLIC, doc.getDoctype().getPublicId());
}
if (null != doc.getDoctype().getSystemId()) {
transformer.setOutputProperty(OutputKeys.DOCTYPE_SYSTEM, doc.getDoctype().getSystemId());
}
}
FileOutputStream out = new FileOutputStream(this.output);
StreamResult streamResult = new StreamResult(out);
transformer.transform(new DOMSource(resultDoc), streamResult);
out.close();
} catch (Exception e) {
e.printStackTrace();
throw new BuildException(e);
}
}
private void checkParameters()
throws BuildException {
if (null == locale || null == input || null == output || null == indexConfig) {
throw new BuildException("locale, indexConfig, input, output attributes are required");
}
}
public void setInput(String theInput) {
this.input = theInput;
}
public void setOutput(String theOutput) {
this.output = theOutput;
}
public void setCatalogs(String theCatalogs) {
this.catalogs = theCatalogs;
}
public void setLocale(String theLocale) {
this.locale = theLocale;
}
public void setIndexConfig(String theIndexConfig) {
this.indexConfig = theIndexConfig;
}
public void setFailOnError(String theFailOnErro) {
this.failOnError = theFailOnErro.equals("true");
}
public void setIndexElementName(String theIndexElementName) {
this.indexElementName = theIndexElementName;
}
private void setActiveProjectProperty(String propertyName, String propertyValue) {
Project activeProject = getProject();
if (activeProject != null) {
activeProject.setProperty(propertyName, propertyValue);
}
}
}
dita-ot-1.5.3/demo/fo/src/com/idiominc/ws/opentopic/fo/index2/ProcessException.java 0000664 0000000 0000000 00000003567 11671002146 0030150 0 ustar 00root root 0000000 0000000 package com.idiominc.ws.opentopic.fo.index2;
/*
Copyright � 2004-2006 by Idiom Technologies, Inc. All rights reserved.
IDIOM is a registered trademark of Idiom Technologies, Inc. and WORLDSERVER
and WORLDSTART are trademarks of Idiom Technologies, Inc. All other
trademarks are the property of their respective owners.
IDIOM TECHNOLOGIES, INC. IS DELIVERING THE SOFTWARE "AS IS," WITH
ABSOLUTELY NO WARRANTIES WHATSOEVER, WHETHER EXPRESS OR IMPLIED, AND IDIOM
TECHNOLOGIES, INC. DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE AND WARRANTY OF NON-INFRINGEMENT. IDIOM TECHNOLOGIES, INC. SHALL NOT
BE LIABLE FOR INDIRECT, INCIDENTAL, SPECIAL, COVER, PUNITIVE, EXEMPLARY,
RELIANCE, OR CONSEQUENTIAL DAMAGES (INCLUDING BUT NOT LIMITED TO LOSS OF
ANTICIPATED PROFIT), ARISING FROM ANY CAUSE UNDER OR RELATED TO OR ARISING
OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE, EVEN IF IDIOM
TECHNOLOGIES, INC. HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Idiom Technologies, Inc. and its licensors shall not be liable for any
damages suffered by any person as a result of using and/or modifying the
Software or its derivatives. In no event shall Idiom Technologies, Inc.'s
liability for any damages hereunder exceed the amounts received by Idiom
Technologies, Inc. as a result of this transaction.
These terms and conditions supersede the terms and conditions in any
licensing agreement to the extent that such terms and conditions conflict
with those set forth herein.
This file is part of the DITA Open Toolkit project hosted on Sourceforge.net.
See the accompanying license.txt file for applicable licenses.
*/
public class ProcessException
extends Exception {
public ProcessException() {
}
public ProcessException(String message) {
super(message);
}
}
dita-ot-1.5.3/demo/fo/src/com/idiominc/ws/opentopic/fo/index2/configuration/ 0000775 0000000 0000000 00000000000 11671002146 0026644 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/fo/src/com/idiominc/ws/opentopic/fo/index2/configuration/CharRange.java 0000664 0000000 0000000 00000001152 11671002146 0031340 0 ustar 00root root 0000000 0000000 package com.idiominc.ws.opentopic.fo.index2.configuration;
import com.idiominc.ws.opentopic.fo.index2.IndexCollator;
/**
* Created by IntelliJ IDEA.
* User: BlackSide
* Date: 30/8/2007
* Time: 18:34:32
* To change this template use File | Settings | File Templates.
*/
public class CharRange {
private String start;
private String end;
public CharRange(String theStart, String theEnd) {
start = theStart;
end = theEnd;
}
public boolean isInRange(String value, IndexCollator collator){
return (collator.compare(value,start) > 0) && (collator.compare(value,end) < 0);
}
}
dita-ot-1.5.3/demo/fo/src/com/idiominc/ws/opentopic/fo/index2/configuration/ConfigEntry.java 0000664 0000000 0000000 00000004561 11671002146 0031744 0 ustar 00root root 0000000 0000000 package com.idiominc.ws.opentopic.fo.index2.configuration;
import com.idiominc.ws.opentopic.fo.index2.IndexCollator;
/*
Copyright � 2004-2006 by Idiom Technologies, Inc. All rights reserved.
IDIOM is a registered trademark of Idiom Technologies, Inc. and WORLDSERVER
and WORLDSTART are trademarks of Idiom Technologies, Inc. All other
trademarks are the property of their respective owners.
IDIOM TECHNOLOGIES, INC. IS DELIVERING THE SOFTWARE "AS IS," WITH
ABSOLUTELY NO WARRANTIES WHATSOEVER, WHETHER EXPRESS OR IMPLIED, AND IDIOM
TECHNOLOGIES, INC. DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE AND WARRANTY OF NON-INFRINGEMENT. IDIOM TECHNOLOGIES, INC. SHALL NOT
BE LIABLE FOR INDIRECT, INCIDENTAL, SPECIAL, COVER, PUNITIVE, EXEMPLARY,
RELIANCE, OR CONSEQUENTIAL DAMAGES (INCLUDING BUT NOT LIMITED TO LOSS OF
ANTICIPATED PROFIT), ARISING FROM ANY CAUSE UNDER OR RELATED TO OR ARISING
OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE, EVEN IF IDIOM
TECHNOLOGIES, INC. HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Idiom Technologies, Inc. and its licensors shall not be liable for any
damages suffered by any person as a result of using and/or modifying the
Software or its derivatives. In no event shall Idiom Technologies, Inc.'s
liability for any damages hereunder exceed the amounts received by Idiom
Technologies, Inc. as a result of this transaction.
These terms and conditions supersede the terms and conditions in any
licensing agreement to the extent that such terms and conditions conflict
with those set forth herein.
This file is part of the DITA Open Toolkit project hosted on Sourceforge.net.
See the accompanying license.txt file for applicable licenses.
*/public interface ConfigEntry {
/**
* @return group label
*/
String getLabel();
/**
* @return group key. this key is being used to check if some string belongs to this group by comparing it with
* two keys of near by config entries
*/
String getKey();
/**
* @return specifies group member characters. The meaning of these characters is that if some string starts with the
* character from this array then it(string) belongs to this group
*/
String[] getGroupMembers();
boolean isInRange(String value, IndexCollator collator);
}
dita-ot-1.5.3/demo/fo/src/com/idiominc/ws/opentopic/fo/index2/configuration/ConfigEntryImpl.java 0000664 0000000 0000000 00000006101 11671002146 0032556 0 ustar 00root root 0000000 0000000 package com.idiominc.ws.opentopic.fo.index2.configuration;
import com.idiominc.ws.opentopic.fo.index2.IndexCollator;
import java.util.ArrayList;
/*
Copyright � 2004-2006 by Idiom Technologies, Inc. All rights reserved.
IDIOM is a registered trademark of Idiom Technologies, Inc. and WORLDSERVER
and WORLDSTART are trademarks of Idiom Technologies, Inc. All other
trademarks are the property of their respective owners.
IDIOM TECHNOLOGIES, INC. IS DELIVERING THE SOFTWARE "AS IS," WITH
ABSOLUTELY NO WARRANTIES WHATSOEVER, WHETHER EXPRESS OR IMPLIED, AND IDIOM
TECHNOLOGIES, INC. DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE AND WARRANTY OF NON-INFRINGEMENT. IDIOM TECHNOLOGIES, INC. SHALL NOT
BE LIABLE FOR INDIRECT, INCIDENTAL, SPECIAL, COVER, PUNITIVE, EXEMPLARY,
RELIANCE, OR CONSEQUENTIAL DAMAGES (INCLUDING BUT NOT LIMITED TO LOSS OF
ANTICIPATED PROFIT), ARISING FROM ANY CAUSE UNDER OR RELATED TO OR ARISING
OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE, EVEN IF IDIOM
TECHNOLOGIES, INC. HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Idiom Technologies, Inc. and its licensors shall not be liable for any
damages suffered by any person as a result of using and/or modifying the
Software or its derivatives. In no event shall Idiom Technologies, Inc.'s
liability for any damages hereunder exceed the amounts received by Idiom
Technologies, Inc. as a result of this transaction.
These terms and conditions supersede the terms and conditions in any
licensing agreement to the extent that such terms and conditions conflict
with those set forth herein.
This file is part of the DITA Open Toolkit project hosted on Sourceforge.net.
See the accompanying license.txt file for applicable licenses.
*/class ConfigEntryImpl
implements ConfigEntry {
private String label;
private String key;
private String[] members;
private CharRange[] ranges = new CharRange[0];
public ConfigEntryImpl(String theLabel, String theKey, String[] theMembers) {
this.label = theLabel;
this.key = theKey;
this.members = theMembers;
}
public void addRange(CharRange range) {
ArrayList rangeList = new ArrayList();
for (int i = 0; i 0) {
for (int i = 0; i < members.length; i++) {
if (value.startsWith(members[i]) || members[i].startsWith(value)) {
return true;
}
}
for (int i = 0; i < ranges.length; i++) {
if (ranges[i].isInRange(value, collator)) {
return true;
}
}
}
return false; //To change body of implemented methods use File | Settings | File Templates.
}
}
dita-ot-1.5.3/demo/fo/src/com/idiominc/ws/opentopic/fo/index2/configuration/IndexConfiguration.java 0000664 0000000 0000000 00000014143 11671002146 0033311 0 ustar 00root root 0000000 0000000 package com.idiominc.ws.opentopic.fo.index2.configuration;
import org.w3c.dom.Document;
import org.w3c.dom.Node;
import org.w3c.dom.NodeList;
import java.util.ArrayList;
import java.util.List;
/*
Copyright � 2004-2006 by Idiom Technologies, Inc. All rights reserved.
IDIOM is a registered trademark of Idiom Technologies, Inc. and WORLDSERVER
and WORLDSTART are trademarks of Idiom Technologies, Inc. All other
trademarks are the property of their respective owners.
IDIOM TECHNOLOGIES, INC. IS DELIVERING THE SOFTWARE "AS IS," WITH
ABSOLUTELY NO WARRANTIES WHATSOEVER, WHETHER EXPRESS OR IMPLIED, AND IDIOM
TECHNOLOGIES, INC. DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE AND WARRANTY OF NON-INFRINGEMENT. IDIOM TECHNOLOGIES, INC. SHALL NOT
BE LIABLE FOR INDIRECT, INCIDENTAL, SPECIAL, COVER, PUNITIVE, EXEMPLARY,
RELIANCE, OR CONSEQUENTIAL DAMAGES (INCLUDING BUT NOT LIMITED TO LOSS OF
ANTICIPATED PROFIT), ARISING FROM ANY CAUSE UNDER OR RELATED TO OR ARISING
OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE, EVEN IF IDIOM
TECHNOLOGIES, INC. HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Idiom Technologies, Inc. and its licensors shall not be liable for any
damages suffered by any person as a result of using and/or modifying the
Software or its derivatives. In no event shall Idiom Technologies, Inc.'s
liability for any damages hereunder exceed the amounts received by Idiom
Technologies, Inc. as a result of this transaction.
These terms and conditions supersede the terms and conditions in any
licensing agreement to the extent that such terms and conditions conflict
with those set forth herein.
This file is part of the DITA Open Toolkit project hosted on Sourceforge.net.
See the accompanying license.txt file for applicable licenses.
*/
public class IndexConfiguration {
private List entries = new ArrayList();
private static String message;
public IndexConfiguration() {
}
public ConfigEntry[] getEntries() {
return (ConfigEntry[]) entries.toArray(new ConfigEntry[entries.size()]);
}
public void addEntry(ConfigEntry theEntry) {
this.entries.add(theEntry);
}
public static IndexConfiguration parse(Document theDocument)
throws ParseException {
message = "Invalid configuration format";
final IndexConfiguration indexConfiguration = new IndexConfiguration();
final NodeList indexConfigurationSet = theDocument.getElementsByTagName("index.configuration.set");
if (indexConfigurationSet.getLength() != 1) {
throw new ParseException(message);
}
final Node indexConfigurationSetNode = indexConfigurationSet.item(0);
if (indexConfigurationSetNode == null) throw new ParseException(message);
final Node indexConf = getNodeByName("index.configuration", indexConfigurationSetNode.getChildNodes());
if (indexConf == null) throw new ParseException(message);
final Node indexGroups = getNodeByName("index.groups", indexConf.getChildNodes());
if (indexGroups == null) throw new ParseException(message);
final NodeList indexGroupChilds = indexGroups.getChildNodes();
for (int i = 0; i < indexGroupChilds.getLength(); i++) {
final Node node = indexGroupChilds.item(i);
if ("index.group".equals(node.getNodeName())) {
final Node key = getNodeByName("group.key", node.getChildNodes());
final Node label = getNodeByName("group.label", node.getChildNodes());
final Node members = getNodeByName("group.members", node.getChildNodes());
final String keyValue = getNodeValue(key);
final String labelValue = getNodeValue(label);
String[] groupMembers = new String[0];
ArrayList rangeList = new ArrayList();
if (null != members && members.getChildNodes().getLength() > 0) {
ArrayList nodeValues = new ArrayList();
final NodeList membersChilds = members.getChildNodes();
for (int j = 0; j < membersChilds.getLength(); j++) {
final Node membersChild = membersChilds.item(j);
if ("char.set".equals(membersChild.getNodeName())) {
if (membersChild.hasAttributes() && membersChild.getAttributes() != null) {
final Node startRange = membersChild.getAttributes().getNamedItem("start-range");
final Node endRange = membersChild.getAttributes().getNamedItem("end-range");
String startRangeText = getNodeValue(startRange);
String endRangeText = getNodeValue(endRange);
if (startRange != null && startRangeText.length() > 0 &&
endRange != null && endRangeText.length() > 0) {
CharRange range = new CharRange(startRangeText, endRangeText);
rangeList.add(range);
nodeValues.add(startRangeText);
}
}
final String nodeValue = getNodeValue(membersChild);
if (nodeValue.length() > 0) {
nodeValues.add(nodeValue);
}
}
}
groupMembers = (String[])nodeValues.toArray(new String[nodeValues.size()]);
}
final ConfigEntryImpl configEntry = new ConfigEntryImpl(labelValue, keyValue, groupMembers);
for(int j = 0; j -1 && textValue.indexOf(sortEnd) > -1 && sortString.length() == 0) {
if (textValue.indexOf(sortStart) < textValue.indexOf(sortEnd)) {
sortString = textValue.substring(textValue.indexOf(sortStart)+1,textValue.indexOf(sortEnd));
textValue = textValue.substring(0,textValue.indexOf(sortStart));
}
}
IndexEntry result = createIndexEntry(textValue,sortString);
if (result.getValue().length() > 0 || endRange || startRange) {
result.setStartRange(startRange);
result.setEndsRange(endRange);
if (startRange) {
result.addRefID(theNode.getAttributes().getNamedItem(elIndexRangeStartName).getNodeValue());
} else if (endRange) {
result.addRefID(theNode.getAttributes().getNamedItem(elIndexRangeEndName).getNodeValue());
} else result.addRefID(normalizeTextValue(theParentValue + textValue + ":"));
if (!seeEntry.isEmpty()) {
for (int j = 0; j < seeEntry.size(); j++) {
IndexEntry seeIndexEntry = (IndexEntry) seeEntry.get(j);
result.addSeeChild(seeIndexEntry);
}
result.setSuppressesThePageNumber(true);
}
if (!seeAlsoEntry.isEmpty()) {
for (int j = 0; j < seeAlsoEntry.size(); j++) {
IndexEntry seeAlsoIndexEntry = (IndexEntry) seeAlsoEntry.get(j);
result.addSeeAlsoChild(seeAlsoIndexEntry);
}
}
for (int i = 0; i < childEntrys.size(); i++) {
IndexEntry child = (IndexEntry) childEntrys.get(i);
result.addChild(child);
}
IndexEntry[] resultArray = new IndexEntry[1];
resultArray[0] = result;
return resultArray;
} else return (IndexEntry[]) childEntrys.toArray(new IndexEntry[childEntrys.size()]);
}
private static IndexEntry createIndexEntry(String theValue, String theSortString) {
String soString;
int soIdxOf = theValue.indexOf(SO);
if (soIdxOf > 0) {
soString = theValue.substring(soIdxOf + SO.length());
theValue = theValue.substring(0, soIdxOf);
} else {
soString = null;
}
String strippedFormatting = stripFormatting(theValue);
IndexEntryImpl indexEntry = new IndexEntryImpl(strippedFormatting, soString, theSortString, theValue);
if (!theSortString.equals("")) indexEntry.setSortString(theSortString);
else indexEntry.setSortString(null);
return indexEntry;
}
private static String stripFormatting(String theValue) {
int ltPos = theValue.indexOf(LT);
int gtPos = theValue.indexOf(GT);
if ((ltPos == -1) && (gtPos == -1)) {
return theValue;
} else if (ltPos == -1 || gtPos == -1 || (ltPos > gtPos)) {
System.err.println("Possibly bad formatting in string \"" + theValue + "\"");
return theValue;
}
String value = theValue.substring(0, ltPos) + theValue.substring(gtPos + 1);
return stripFormatting(value);
}
public static String normalizeTextValue(final String theString) {
if (null != theString && theString.length() > 0) {
String res = theString.replaceAll("[\\s\\n]+", " ");
res = res.replaceAll("[\\s]+$", ""); //replace in the end of string
res = res.replaceAll("[\\s]+:", ":"); //replace spaces before ':'
return res.replaceAll(":[\\s]+", ":"); //replace spaces after ':'
}
return theString;
}
}
dita-ot-1.5.3/demo/fo/src/com/idiominc/ws/opentopic/fo/index2/util/IndexEntryImpl.java 0000664 0000000 0000000 00000022552 11671002146 0030536 0 ustar 00root root 0000000 0000000 package com.idiominc.ws.opentopic.fo.index2.util;
import com.idiominc.ws.opentopic.fo.index2.IndexEntry;
import java.util.ArrayList;
import java.util.Collection;
import java.util.HashMap;
/*
Copyright � 2004-2006 by Idiom Technologies, Inc. All rights reserved.
IDIOM is a registered trademark of Idiom Technologies, Inc. and WORLDSERVER
and WORLDSTART are trademarks of Idiom Technologies, Inc. All other
trademarks are the property of their respective owners.
IDIOM TECHNOLOGIES, INC. IS DELIVERING THE SOFTWARE "AS IS," WITH
ABSOLUTELY NO WARRANTIES WHATSOEVER, WHETHER EXPRESS OR IMPLIED, AND IDIOM
TECHNOLOGIES, INC. DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE AND WARRANTY OF NON-INFRINGEMENT. IDIOM TECHNOLOGIES, INC. SHALL NOT
BE LIABLE FOR INDIRECT, INCIDENTAL, SPECIAL, COVER, PUNITIVE, EXEMPLARY,
RELIANCE, OR CONSEQUENTIAL DAMAGES (INCLUDING BUT NOT LIMITED TO LOSS OF
ANTICIPATED PROFIT), ARISING FROM ANY CAUSE UNDER OR RELATED TO OR ARISING
OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE, EVEN IF IDIOM
TECHNOLOGIES, INC. HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Idiom Technologies, Inc. and its licensors shall not be liable for any
damages suffered by any person as a result of using and/or modifying the
Software or its derivatives. In no event shall Idiom Technologies, Inc.'s
liability for any damages hereunder exceed the amounts received by Idiom
Technologies, Inc. as a result of this transaction.
These terms and conditions supersede the terms and conditions in any
licensing agreement to the extent that such terms and conditions conflict
with those set forth herein.
This file is part of the DITA Open Toolkit project hosted on Sourceforge.net.
See the accompanying license.txt file for applicable licenses.
*/
class IndexEntryImpl
implements IndexEntry {
private String value;
private String formattedString;
private String soString;
private String sortString;
private HashMap childs = new HashMap();
private HashMap seeChilds = new HashMap();
private HashMap seeAlsoChilds = new HashMap();
private boolean startRange = false;
private boolean endsRange = false;
private boolean suppressesThePageNumber = false;
private boolean restoresPageNumber = false;
private ArrayList refIDs = new ArrayList();
public IndexEntryImpl(String theValue, String theSoString, String theSortString, String theFormattedString) {
this.value = theValue;
this.soString = theSoString;
this.sortString = theSortString;
this.formattedString = theFormattedString;
}
public String[] getRefIDs() {
return (String[]) refIDs.toArray(new String[refIDs.size()]);
}
public String getValue() {
return this.value;
}
public String getSoValue() {
return this.soString;
}
public String getFormattedString() {
return this.formattedString;
}
public String getSortString() {
return this.sortString;
}
public IndexEntry[] getChildIndexEntries() {
Collection collection = childs.values();
return (IndexEntry[]) collection.toArray(new IndexEntry[collection.size()]);
}
public boolean isStartingRange() {
return this.startRange;
}
public boolean isEndingRange() {
return this.endsRange;
}
public boolean isSuppressesThePageNumber() {
return this.suppressesThePageNumber;
}
public boolean isRestoresPageNumber() {
return this.restoresPageNumber;
}
public void addRefID(final String theID) {
if (!this.refIDs.contains(theID)) {
this.refIDs.add(theID);
}
}
public void addSeeChild(IndexEntry theEntry) {
final String entryValue = theEntry.getValue();
if (!this.seeChilds.containsKey(entryValue)) {
this.seeChilds.put(entryValue, theEntry);
return;
}
//The index with same value already exists
//Add seeChilds of given entry to existing entry
final IndexEntry existingEntry = (IndexEntry) this.seeChilds.get(entryValue);
final IndexEntry[] childIndexEntries = theEntry.getChildIndexEntries();
for (int i = 0; i < childIndexEntries.length; i++) {
IndexEntry childIndexEntry = childIndexEntries[i];
existingEntry.addChild(childIndexEntry);
}
//supress some attributes of given entry to the existing one
if (theEntry.isRestoresPageNumber()) {
existingEntry.setRestoresPageNumber(true);
}
if (!theEntry.isSuppressesThePageNumber()) {
existingEntry.setSuppressesThePageNumber(false);
}
if (theEntry.isStartingRange()) {
existingEntry.setStartRange(true);
}
if (theEntry.getSortString() != null) {
existingEntry.setSortString(theEntry.getSortString());
}
if (theEntry.getSoValue() != null) {
existingEntry.setSoValue(theEntry.getSoValue());
}
}
public void addSeeAlsoChild(IndexEntry theEntry) {
final String entryValue = theEntry.getValue();
if (!this.seeAlsoChilds.containsKey(entryValue)) {
this.seeAlsoChilds.put(entryValue, theEntry);
return;
}
//The index with same value already exists
//Add seeAlsoChilds of given entry to existing entry
final IndexEntry existingEntry = (IndexEntry) this.seeAlsoChilds.get(entryValue);
final IndexEntry[] childIndexEntries = theEntry.getChildIndexEntries();
for (int i = 0; i < childIndexEntries.length; i++) {
IndexEntry childIndexEntry = childIndexEntries[i];
existingEntry.addChild(childIndexEntry);
}
//supress some attributes of given entry to the existing one
if (theEntry.isRestoresPageNumber()) {
existingEntry.setRestoresPageNumber(true);
}
if (!theEntry.isSuppressesThePageNumber()) {
existingEntry.setSuppressesThePageNumber(false);
}
if (theEntry.isStartingRange()) {
existingEntry.setStartRange(true);
}
if (theEntry.getSortString() != null) {
existingEntry.setSortString(theEntry.getSortString());
}
if (theEntry.getSoValue() != null) {
existingEntry.setSoValue(theEntry.getSoValue());
}
}
public void addChild(IndexEntry theEntry) {
final String entryValue = theEntry.getValue();
if (!this.childs.containsKey(entryValue)) {
this.childs.put(entryValue, theEntry);
return;
}
//The index with same value already exists
//Add childs of given entry to existing entry
final IndexEntry existingEntry = (IndexEntry) this.childs.get(entryValue);
final IndexEntry[] childIndexEntries = theEntry.getChildIndexEntries();
for (int i = 0; i < childIndexEntries.length; i++) {
IndexEntry childIndexEntry = childIndexEntries[i];
existingEntry.addChild(childIndexEntry);
}
//supress some attributes of given entry to the existing one
if (theEntry.isRestoresPageNumber()) {
existingEntry.setRestoresPageNumber(true);
}
if (!theEntry.isSuppressesThePageNumber()) {
existingEntry.setSuppressesThePageNumber(false);
}
if (theEntry.isStartingRange()) {
existingEntry.setStartRange(true);
}
if (theEntry.getSortString() != null) {
existingEntry.setSortString(theEntry.getSortString());
}
if (theEntry.getSoValue() != null) {
existingEntry.setSoValue(theEntry.getSoValue());
}
}
public void setSortString(String theSortString) {
this.sortString = theSortString;
}
public void setSoValue(String theSoValue) {
this.soString = theSoValue;
}
public void setStartRange(boolean theStartRange) {
if (theStartRange && this.endsRange) {
this.endsRange = false;
}
this.startRange = theStartRange;
}
public void setEndsRange(boolean theEndsRange) {
if (theEndsRange && this.startRange) {
this.startRange = false;
}
this.endsRange = theEndsRange;
}
public void setSuppressesThePageNumber(boolean theSuppressesThePageNumber) {
if (theSuppressesThePageNumber && this.restoresPageNumber) {
this.restoresPageNumber = false;
}
this.suppressesThePageNumber = theSuppressesThePageNumber;
}
public void setRestoresPageNumber(boolean theRestoresPageNumber) {
if (theRestoresPageNumber && this.suppressesThePageNumber) {
this.suppressesThePageNumber = false;
}
this.restoresPageNumber = theRestoresPageNumber;
}
public IndexEntry[] getSeeChildIndexEntries() {
if (!seeChilds.isEmpty()) {
Collection collection = seeChilds.values();
return (IndexEntry[]) collection.toArray(new IndexEntry[collection.size()]);
} else return null;
}
public IndexEntry[] getSeeAlsoChildIndexEntries() {
if (!seeAlsoChilds.isEmpty()) {
Collection collection = seeAlsoChilds.values();
return (IndexEntry[]) collection.toArray(new IndexEntry[collection.size()]);
} else return null;
}
public String toString() {
String result = "";
result+=getValue();
if (this.getSoValue() != null && this.getSoValue().length() > 0) {
result+=""+getSoValue();
}
if (this.isSuppressesThePageNumber()) {
result+="<$nopage>";
}
if (this.isRestoresPageNumber()) {
result+="<$singlepage>";
}
if (this.isStartingRange()) {
result+="<$startrange>";
}
if (this.isEndingRange()) {
result+="<$endrange>";
}
if (this.getSortString() != null && this.getSortString().length() > 0) {
result+="["+getSortString()+"]";
}
return result;
}
}
dita-ot-1.5.3/demo/fo/src/com/idiominc/ws/opentopic/fo/index2/util/IndexStringProcessor.java 0000664 0000000 0000000 00000021515 11671002146 0031757 0 ustar 00root root 0000000 0000000 package com.idiominc.ws.opentopic.fo.index2.util;
import com.idiominc.ws.opentopic.fo.index2.IndexEntry;
import java.util.ArrayList;
import java.util.List;
import java.util.StringTokenizer;
/*
Copyright � 2004-2006 by Idiom Technologies, Inc. All rights reserved.
IDIOM is a registered trademark of Idiom Technologies, Inc. and WORLDSERVER
and WORLDSTART are trademarks of Idiom Technologies, Inc. All other
trademarks are the property of their respective owners.
IDIOM TECHNOLOGIES, INC. IS DELIVERING THE SOFTWARE "AS IS," WITH
ABSOLUTELY NO WARRANTIES WHATSOEVER, WHETHER EXPRESS OR IMPLIED, AND IDIOM
TECHNOLOGIES, INC. DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE AND WARRANTY OF NON-INFRINGEMENT. IDIOM TECHNOLOGIES, INC. SHALL NOT
BE LIABLE FOR INDIRECT, INCIDENTAL, SPECIAL, COVER, PUNITIVE, EXEMPLARY,
RELIANCE, OR CONSEQUENTIAL DAMAGES (INCLUDING BUT NOT LIMITED TO LOSS OF
ANTICIPATED PROFIT), ARISING FROM ANY CAUSE UNDER OR RELATED TO OR ARISING
OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE, EVEN IF IDIOM
TECHNOLOGIES, INC. HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Idiom Technologies, Inc. and its licensors shall not be liable for any
damages suffered by any person as a result of using and/or modifying the
Software or its derivatives. In no event shall Idiom Technologies, Inc.'s
liability for any damages hereunder exceed the amounts received by Idiom
Technologies, Inc. as a result of this transaction.
These terms and conditions supersede the terms and conditions in any
licensing agreement to the extent that such terms and conditions conflict
with those set forth herein.
This file is part of the DITA Open Toolkit project hosted on Sourceforge.net.
See the accompanying license.txt file for applicable licenses.
*/
public abstract class IndexStringProcessor {
private static final String COLON = ":";
private static final String SEMICOLON = ";";
private static final String STARTRANGE = "<$startrange>";
private static final String ENDRANGE = "<$endrange>";
private static final String NOPAGE = "<$nopage>";
private static final String SINGLEPAGE = "<$singlepage>";
private static final String SORT_START_BRAKET = "[";
private static final String SORT_END_BRAKET = "]";
private static final String SO = "";
private static final String LT = "<";
private static final String GT = ">";
/**
* Parse the index marker string and create IndexEntry object from one
*
* @param theIndexMarkerString index marker string
* @return IndexEntry objects created from the index string
* @see "Adobe Framemaker 7.1" help, topic "Adding index markers" (page is "1_15_8_0.html") for syntax details
*/
public static IndexEntry[] processIndexString(final String theIndexMarkerString) {
List resList = new ArrayList();
StringTokenizer stringTokenizer = new StringTokenizer(normalizeTextValue(theIndexMarkerString), SEMICOLON);
while (stringTokenizer.hasMoreTokens()) {
// string may contain multiple index entries. split and process each separately
String entry = stringTokenizer.nextToken().trim();
if (entry.length() > 0) {
//Split index string and sort string
String sortString = null;
int sortStartIdx = entry.indexOf(SORT_START_BRAKET);
if (sortStartIdx > 0) {
//there is a sort string
int sortEndIdx = entry.indexOf(SORT_END_BRAKET);
if (sortEndIdx > 0 && sortEndIdx > sortStartIdx) {
sortString = entry.substring(sortStartIdx + SORT_START_BRAKET.length(), sortEndIdx);
entry = entry.substring(0, sortStartIdx);
}
}
// process index string and add it to result list
IndexEntry indexEntry = processEntry(entry, sortString);
if (null != indexEntry) {
resList.add(indexEntry);
}
}
}
return (IndexEntry[]) resList.toArray(new IndexEntry[resList.size()]);
}
private static IndexEntry processEntry(final String theEntry, final String theSortString) {
IndexEntry res = null;
IndexEntry parent = null;
String sortString = (null != theSortString) ? theSortString : "";
StringTokenizer entryColonTokenizer = new StringTokenizer(theEntry, COLON);
StringTokenizer sortStringColonTokenizer = new StringTokenizer(sortString, COLON);
StringBuffer referenceIDBuf = new StringBuffer();
while (entryColonTokenizer.hasMoreTokens()) {
String s = entryColonTokenizer.nextToken();
boolean isLastToken = !entryColonTokenizer.hasMoreTokens();
IndexEntryImpl indexEntry;
String currSortString = null;
if (sortString.length() > 0) {
if (sortStringColonTokenizer.hasMoreTokens()) {
currSortString = sortStringColonTokenizer.nextToken();
} else {
System.err.println("Possibly invalid sort string \"" + theSortString + "\" for the index entry \"" + theEntry + "\"!");
}
}
final boolean parentSuppressesThePageNumber = (null != parent) ? parent.isSuppressesThePageNumber() : false;
indexEntry = createIndexEntry(s, currSortString, parentSuppressesThePageNumber);
referenceIDBuf.append(indexEntry.getValue());
referenceIDBuf.append(':');
if (!indexEntry.isSuppressesThePageNumber()) {
indexEntry.addRefID(referenceIDBuf.toString());
}
if (null != parent) {
parent.addChild(indexEntry);
}
parent = indexEntry;
if (null == res) {
res = parent;
}
if (isLastToken) {
/*
Start and end range flags should be set for the last child only
but because of framemaker's syntax the first level entry contains it.
That is why I took flags from the first (root) entry and set these flags
to the last parsed entry.
*/
final boolean startingRange = res.isStartingRange();
final boolean endsRange = res.isEndingRange();
res.setStartRange(false);
res.setEndsRange(false);
indexEntry.setStartRange(startingRange);
indexEntry.setEndsRange(endsRange);
}
}
return res;
}
/**
* Method equals to the normalize-space xslt function
*
* @param theString string to normalize
* @return normalized string
*/
public static String normalizeTextValue(final String theString) {
if (null != theString && theString.length() > 0) {
String res = theString.replaceAll("[\\s\\n]+", " ");
res = res.replaceAll("[\\s]+:", ":"); //replace spaces before ':'
return res.replaceAll(":[\\s]+", ":"); //replace spaces after ':'
}
return theString;
}
private static IndexEntryImpl createIndexEntry(String theValue, String theSortString, boolean theIsParentNoPage) {
String soString;
int soIdxOf = theValue.indexOf(SO);
if (soIdxOf > 0) {
soString = theValue.substring(soIdxOf + SO.length());
theValue = theValue.substring(0, soIdxOf);
} else {
soString = null;
}
boolean suppressesThePageNumber = theIsParentNoPage;
int nopageIdx = theValue.indexOf(NOPAGE);
if (nopageIdx == 0) {
suppressesThePageNumber = true;
theValue = theValue.substring(NOPAGE.length());
}
boolean restoresPageNumber = false;
int singlepageIdx = theValue.indexOf(SINGLEPAGE);
if (singlepageIdx == 0) {
restoresPageNumber = true;
suppressesThePageNumber = false;
theValue = theValue.substring(SINGLEPAGE.length());
}
boolean startsRange = false;
int startsRangeIdx = theValue.indexOf(STARTRANGE);
if (startsRangeIdx == 0) {
startsRange = true;
theValue = theValue.substring(STARTRANGE.length());
}
boolean endsRange = false;
int endsRangeIdx = theValue.indexOf(ENDRANGE);
if (endsRangeIdx == 0) {
endsRange = true;
theValue = theValue.substring(ENDRANGE.length());
}
String strippedFormatting = stripFormatting(theValue);
IndexEntryImpl indexEntry = new IndexEntryImpl(strippedFormatting, soString, theSortString, theValue);
indexEntry.setSuppressesThePageNumber(suppressesThePageNumber);
indexEntry.setRestoresPageNumber(restoresPageNumber);
indexEntry.setStartRange(startsRange);
indexEntry.setEndsRange(endsRange);
indexEntry.setSortString(theSortString);
return indexEntry;
}
/**
* Strips Adobe Framemaker index string formatting from string
* See "Adobe Framemaker 7.1" help, topic "Adding index markers" (page is "1_15_8_0.html") for details
*
* @param theValue formatted string
* @return string without formatting
*/
private static String stripFormatting(String theValue) {
int ltPos = theValue.indexOf(LT);
int gtPos = theValue.indexOf(GT);
if ((ltPos == -1) && (gtPos == -1)) {
return theValue;
} else if (ltPos == -1 || gtPos == -1 || (ltPos > gtPos)) {
System.err.println("Possibly bad formatting in string \"" + theValue + "\"");
return theValue;
}
String value = theValue.substring(0, ltPos) + theValue.substring(gtPos + 1);
return stripFormatting(value);
}
}
dita-ot-1.5.3/demo/fo/src/com/idiominc/ws/opentopic/fo/xep/ 0000775 0000000 0000000 00000000000 11671002146 0023400 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/fo/src/com/idiominc/ws/opentopic/fo/xep/Logger.java 0000664 0000000 0000000 00000005140 11671002146 0025462 0 ustar 00root root 0000000 0000000 package com.idiominc.ws.opentopic.fo.xep;
/*
Copyright (c) 2004-2006 by Idiom Technologies, Inc. All rights reserved.
IDIOM is a registered trademark of Idiom Technologies, Inc. and WORLDSERVER
and WORLDSTART are trademarks of Idiom Technologies, Inc. All other
trademarks are the property of their respective owners.
IDIOM TECHNOLOGIES, INC. IS DELIVERING THE SOFTWARE "AS IS," WITH
ABSOLUTELY NO WARRANTIES WHATSOEVER, WHETHER EXPRESS OR IMPLIED, AND IDIOM
TECHNOLOGIES, INC. DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE AND WARRANTY OF NON-INFRINGEMENT. IDIOM TECHNOLOGIES, INC. SHALL NOT
BE LIABLE FOR INDIRECT, INCIDENTAL, SPECIAL, COVER, PUNITIVE, EXEMPLARY,
RELIANCE, OR CONSEQUENTIAL DAMAGES (INCLUDING BUT NOT LIMITED TO LOSS OF
ANTICIPATED PROFIT), ARISING FROM ANY CAUSE UNDER OR RELATED TO OR ARISING
OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE, EVEN IF IDIOM
TECHNOLOGIES, INC. HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Idiom Technologies, Inc. and its licensors shall not be liable for any
damages suffered by any person as a result of using and/or modifying the
Software or its derivatives. In no event shall Idiom Technologies, Inc.'s
liability for any damages hereunder exceed the amounts received by Idiom
Technologies, Inc. as a result of this transaction.
These terms and conditions supersede the terms and conditions in any
licensing agreement to the extent that such terms and conditions conflict
with those set forth herein.
This file is part of the DITA Open Toolkit project hosted on Sourceforge.net.
See the accompanying license.txt file for applicable licenses.
*/
public class Logger implements com.renderx.xep.lib.Logger {
private Runner runner;
public Logger(Runner runner) {
this.runner = runner;
}
public void openDocument() {
}
public void closeDocument() {
}
public void event(String name, String message) {
}
public void openState(String name) {
}
public void closeState(String name) {
}
public void info(String message) {
}
public void warning(String message) {
this.runner.fail();
System.out.println("WARNING: " + message);
}
public void error(String message) {
this.runner.fail();
System.out.println("ERROR: " + message);
}
public void exception(String message, java.lang.Exception except) {
this.runner.fail();
System.out.println("EXCEPTION: " + message);
}
}
dita-ot-1.5.3/demo/fo/src/com/idiominc/ws/opentopic/fo/xep/Runner.java 0000664 0000000 0000000 00000012117 11671002146 0025516 0 ustar 00root root 0000000 0000000 package com.idiominc.ws.opentopic.fo.xep;
import com.renderx.xep.FOTarget;
import com.renderx.xep.FormatterImpl;
import org.xml.sax.InputSource;
import javax.xml.transform.sax.SAXSource;
import java.io.BufferedOutputStream;
import java.io.File;
import java.io.FileOutputStream;
import java.io.OutputStream;
/*
Copyright (c) 2004-2006 by Idiom Technologies, Inc. All rights reserved.
IDIOM is a registered trademark of Idiom Technologies, Inc. and WORLDSERVER
and WORLDSTART are trademarks of Idiom Technologies, Inc. All other
trademarks are the property of their respective owners.
IDIOM TECHNOLOGIES, INC. IS DELIVERING THE SOFTWARE "AS IS," WITH
ABSOLUTELY NO WARRANTIES WHATSOEVER, WHETHER EXPRESS OR IMPLIED, AND IDIOM
TECHNOLOGIES, INC. DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE AND WARRANTY OF NON-INFRINGEMENT. IDIOM TECHNOLOGIES, INC. SHALL NOT
BE LIABLE FOR INDIRECT, INCIDENTAL, SPECIAL, COVER, PUNITIVE, EXEMPLARY,
RELIANCE, OR CONSEQUENTIAL DAMAGES (INCLUDING BUT NOT LIMITED TO LOSS OF
ANTICIPATED PROFIT), ARISING FROM ANY CAUSE UNDER OR RELATED TO OR ARISING
OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE, EVEN IF IDIOM
TECHNOLOGIES, INC. HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Idiom Technologies, Inc. and its licensors shall not be liable for any
damages suffered by any person as a result of using and/or modifying the
Software or its derivatives. In no event shall Idiom Technologies, Inc.'s
liability for any damages hereunder exceed the amounts received by Idiom
Technologies, Inc. as a result of this transaction.
These terms and conditions supersede the terms and conditions in any
licensing agreement to the extent that such terms and conditions conflict
with those set forth herein.
This file is part of the DITA Open Toolkit project hosted on Sourceforge.net.
See the accompanying license.txt file for applicable licenses.
*/
public class Runner {
private boolean failed;
private static boolean failOnError = true;
public static void main(String[] args) {
if (args.length < 2) {
System.out.println("Invalid number of parameters. " +
"This class should not be executed outside of publising output build script");
System.exit(1);
}
if (args.length >= 3 && args[2].equals("failOnError=false"))
{
failOnError = false;
}
boolean failed = new Runner().run(args);
if (failed && failOnError) {
System.exit(1);
} else {
System.exit(0);
}
}
public void fail()
{
this.failed = true;
}
/**
* @return true if transformation failed
*/
private boolean run(String[] args) {
FormatterImpl xep = null;
try {
xep = new FormatterImpl();
} catch (Exception e) {
System.out.println("Could not create XEP formatter: " + e.toString());
return true;
}
String outputFormat = "PDF";
for (int i = 2; i < args.length; i++) {
if (args[i].startsWith("-")) {
outputFormat = args[i].substring(1);
}
}
try {
SAXSource source = createSAXSource(args);
OutputStream out = createOutputStream(args);
Logger logger = createCustomLogger(this);
try {
try {
xep.render(source, new FOTarget(out, outputFormat), logger);
} finally {
out.close();
}
} catch (Exception e) {
System.out.println("Rendering failed: " + e.getMessage());
return true;
}
} finally {
xep.cleanup();
}
return this.failed;
}
private static SAXSource createSAXSource(String[] args) {
SAXSource source = null;
try {
File in = new File(args[0]);
InputSource saxsrc = new InputSource(in.toURL().toString());
source = new SAXSource(saxsrc);
} catch (Exception e) {
System.out.println("Source creation failed: " + e.getMessage());
System.exit(1);
}
return source;
}
private static OutputStream createOutputStream(String[] args) {
OutputStream out = null;
try {
out = new BufferedOutputStream(new FileOutputStream(args[1]));
} catch (Exception e) {
System.out.println("Could not open output file: " + e.getMessage());
System.exit(1);
}
return out;
}
private static Logger createCustomLogger(Runner runner) {
Logger logger = null;
try {
logger = new Logger(runner);
} catch (Exception e) {
System.out.println("Log handler creation failed: " + e.getMessage());
System.exit(1);
}
return logger;
}
}
dita-ot-1.5.3/demo/fo/src/com/idiominc/ws/opentopic/xsl/ 0000775 0000000 0000000 00000000000 11671002146 0023006 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/fo/src/com/idiominc/ws/opentopic/xsl/extension/ 0000775 0000000 0000000 00000000000 11671002146 0025022 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/fo/src/com/idiominc/ws/opentopic/xsl/extension/CompareStrings.java 0000664 0000000 0000000 00000004343 11671002146 0030631 0 ustar 00root root 0000000 0000000 package com.idiominc.ws.opentopic.xsl.extension;
import java.util.Locale;
import com.ibm.icu.text.Collator;
/*
Copyright (c) 2004-2006 by Idiom Technologies, Inc. All rights reserved.
IDIOM is a registered trademark of Idiom Technologies, Inc. and WORLDSERVER
and WORLDSTART are trademarks of Idiom Technologies, Inc. All other
trademarks are the property of their respective owners.
IDIOM TECHNOLOGIES, INC. IS DELIVERING THE SOFTWARE "AS IS," WITH
ABSOLUTELY NO WARRANTIES WHATSOEVER, WHETHER EXPRESS OR IMPLIED, AND IDIOM
TECHNOLOGIES, INC. DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE AND WARRANTY OF NON-INFRINGEMENT. IDIOM TECHNOLOGIES, INC. SHALL NOT
BE LIABLE FOR INDIRECT, INCIDENTAL, SPECIAL, COVER, PUNITIVE, EXEMPLARY,
RELIANCE, OR CONSEQUENTIAL DAMAGES (INCLUDING BUT NOT LIMITED TO LOSS OF
ANTICIPATED PROFIT), ARISING FROM ANY CAUSE UNDER OR RELATED TO OR ARISING
OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE, EVEN IF IDIOM
TECHNOLOGIES, INC. HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Idiom Technologies, Inc. and its licensors shall not be liable for any
damages suffered by any person as a result of using and/or modifying the
Software or its derivatives. In no event shall Idiom Technologies, Inc.'s
liability for any damages hereunder exceed the amounts received by Idiom
Technologies, Inc. as a result of this transaction.
These terms and conditions supersede the terms and conditions in any
licensing agreement to the extent that such terms and conditions conflict
with those set forth herein.
This file is part of the DITA Open Toolkit project hosted on Sourceforge.net.
See the accompanying license.txt file for applicable licenses.
*/
public class CompareStrings {
public static Integer compare(String theS1, String theS2, String theLanguage, String theCountry) {
Collator collator = Collator.getInstance(new Locale(theLanguage, theCountry));
return new Integer(collator.compare(theS1, theS2));
}
public static Integer compare(String theS1, String theS2, String theLanguage) {
return compare(theS1, theS2, theLanguage, "");
}
}
dita-ot-1.5.3/demo/fo/src/com/idiominc/ws/opentopic/xsl/extension/DitaVersion.java 0000664 0000000 0000000 00000011670 11671002146 0030121 0 ustar 00root root 0000000 0000000 package com.idiominc.ws.opentopic.xsl.extension;
import org.xml.sax.SAXException;
import org.xml.sax.Attributes;
import org.xml.sax.helpers.DefaultHandler;
import javax.xml.parsers.SAXParser;
import javax.xml.parsers.SAXParserFactory;
import java.io.File;
import org.apache.tools.ant.Task;
import org.apache.tools.ant.Project;
/*
Copyright (c) 2004-2006 by Idiom Technologies, Inc. All rights reserved.
IDIOM is a registered trademark of Idiom Technologies, Inc. and WORLDSERVER
and WORLDSTART are trademarks of Idiom Technologies, Inc. All other
trademarks are the property of their respective owners.
IDIOM TECHNOLOGIES, INC. IS DELIVERING THE SOFTWARE "AS IS," WITH
ABSOLUTELY NO WARRANTIES WHATSOEVER, WHETHER EXPRESS OR IMPLIED, AND IDIOM
TECHNOLOGIES, INC. DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE AND WARRANTY OF NON-INFRINGEMENT. IDIOM TECHNOLOGIES, INC. SHALL NOT
BE LIABLE FOR INDIRECT, INCIDENTAL, SPECIAL, COVER, PUNITIVE, EXEMPLARY,
RELIANCE, OR CONSEQUENTIAL DAMAGES (INCLUDING BUT NOT LIMITED TO LOSS OF
ANTICIPATED PROFIT), ARISING FROM ANY CAUSE UNDER OR RELATED TO OR ARISING
OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE, EVEN IF IDIOM
TECHNOLOGIES, INC. HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Idiom Technologies, Inc. and its licensors shall not be liable for any
damages suffered by any person as a result of using and/or modifying the
Software or its derivatives. In no event shall Idiom Technologies, Inc.'s
liability for any damages hereunder exceed the amounts received by Idiom
Technologies, Inc. as a result of this transaction.
These terms and conditions supersede the terms and conditions in any
licensing agreement to the extent that such terms and conditions conflict
with those set forth herein.
This file is part of the DITA Open Toolkit project hosted on Sourceforge.net.
See the accompanying license.txt file for applicable licenses.
Parts copyright by Suite Solutions, released under the same terms as the DITA-OT.
*/
public class DitaVersion extends Task {
private String documentPath;
/**
* Sets the path to the _MERGED file which will be parsed.
*
* @param path The path to set
*/
public void setDocumentPath(String path) {
this.documentPath = path;
}
/**
* Executes the Ant task.
*/
public void execute() {
try {
documentPath = documentPath.replace(File.separatorChar, '/');
File file = documentPath.startsWith("file:") ?
new File(new java.net.URI(documentPath)) :
new File(documentPath);
if (!file.exists()) {
throw new Exception("File does not exist");
}
if (!file.canRead()) {
throw new Exception("Can't read input file");
}
SAXParserFactory saxParserFactory = SAXParserFactory.newInstance();
SAXParser saxParser = saxParserFactory.newSAXParser();
saxParser.parse(file, new DefaultHandlerImpl());
} catch (Exception e) {
/* Since an exception is used to stop parsing when the search
* is successful, catch the exception.
*/
if (e.getMessage() != null &&
e.getMessage().equals("Search finished")) {
System.out.println("Search finished");
} else {
e.printStackTrace();
}
}
}
private class DefaultHandlerImpl
extends DefaultHandler {
public void startElement(String uri, String localName, String qName, Attributes attributes) throws SAXException {
String classAttr = attributes.getValue("class");
if(classAttr != null) {
if ((classAttr.indexOf(" map/map ") > -1) ||
(classAttr.indexOf(" topic/topic ") > -1)) {
if (attributes.getIndex("ditaarch:DITAArchVersion") > -1)
setActiveProjectProperty("ws.runtime.publishing.map.dita.version",attributes.getValue("ditaarch:DITAArchVersion"));
else
setActiveProjectProperty("ws.runtime.publishing.map.dita.version","132");
/* Successfully found ditaarch, so stop parsing. */
throw new SAXException("Search finished");
}
}
}
}
/**
* Sets property in active ant project with name specified inpropertyName,
* and value specified in propertyValue parameter
*/
private void setActiveProjectProperty(String propertyName, String propertyValue) {
Project activeProject = getProject();
if (activeProject != null) {
activeProject.setProperty(propertyName, propertyValue);
}
}
}
dita-ot-1.5.3/demo/fo/src/com/suite/ 0000775 0000000 0000000 00000000000 11671002146 0017105 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/fo/src/com/suite/sol/ 0000775 0000000 0000000 00000000000 11671002146 0017702 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/fo/src/com/suite/sol/ditaot/ 0000775 0000000 0000000 00000000000 11671002146 0021166 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/fo/src/com/suite/sol/ditaot/DetectLang.java 0000664 0000000 0000000 00000014227 11671002146 0024051 0 ustar 00root root 0000000 0000000 package com.suite.sol.ditaot;
import org.xml.sax.SAXException;
import org.xml.sax.Attributes;
import org.xml.sax.helpers.DefaultHandler;
import javax.xml.parsers.SAXParser;
import javax.xml.parsers.SAXParserFactory;
import org.apache.tools.ant.BuildException;
import java.io.File;
import org.apache.tools.ant.Task;
import org.apache.tools.ant.Project;
/*
Copyright (c) 2004-2006 by Idiom Technologies, Inc. All rights reserved.
IDIOM is a registered trademark of Idiom Technologies, Inc. and WORLDSERVER
and WORLDSTART are trademarks of Idiom Technologies, Inc. All other
trademarks are the property of their respective owners.
IDIOM TECHNOLOGIES, INC. IS DELIVERING THE SOFTWARE "AS IS," WITH
ABSOLUTELY NO WARRANTIES WHATSOEVER, WHETHER EXPRESS OR IMPLIED, AND IDIOM
TECHNOLOGIES, INC. DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE AND WARRANTY OF NON-INFRINGEMENT. IDIOM TECHNOLOGIES, INC. SHALL NOT
BE LIABLE FOR INDIRECT, INCIDENTAL, SPECIAL, COVER, PUNITIVE, EXEMPLARY,
RELIANCE, OR CONSEQUENTIAL DAMAGES (INCLUDING BUT NOT LIMITED TO LOSS OF
ANTICIPATED PROFIT), ARISING FROM ANY CAUSE UNDER OR RELATED TO OR ARISING
OUT OF THE USE OF OR INABILITY TO USE THE SOFTWARE, EVEN IF IDIOM
TECHNOLOGIES, INC. HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Idiom Technologies, Inc. and its licensors shall not be liable for any
damages suffered by any person as a result of using and/or modifying the
Software or its derivatives. In no event shall Idiom Technologies, Inc.'s
liability for any damages hereunder exceed the amounts received by Idiom
Technologies, Inc. as a result of this transaction.
These terms and conditions supersede the terms and conditions in any
licensing agreement to the extent that such terms and conditions conflict
with those set forth herein.
This file is part of the DITA Open Toolkit project hosted on Sourceforge.net.
See the accompanying license.txt file for applicable licenses.
Parts copyright by Suite Solutions, released under the same terms as the DITA-OT.
*/
public class DetectLang extends Task {
private String documentPath;
/**
* Sets the path to the _MERGED file which will be parsed.
*
* @param path The path to set
*/
public void setDocumentPath(String path) {
this.documentPath = path;
}
/**
* Executes the Ant task.
*/
public void execute() throws BuildException {
if (getProject() == null) {
throw new BuildException(new IllegalStateException("Project not available"));
}
if (getProject().getProperty("document.locale") == null) {
try {
documentPath = documentPath.replace(File.separatorChar, '/');
File file = documentPath.startsWith("file:") ?
new File(new java.net.URI(documentPath)) :
new File(documentPath);
if (!file.exists()) {
throw new Exception("File does not exist");
}
if (!file.canRead()) {
throw new Exception("Can't read input file");
}
SAXParserFactory saxParserFactory = SAXParserFactory.newInstance();
SAXParser saxParser = saxParserFactory.newSAXParser();
saxParser.parse(file, new DefaultHandlerImpl());
} catch (Exception e) {
/* Since an exception is used to stop parsing when the search
* is successful, catch the exception.
*/
if (e.getMessage() != null &&
e.getMessage().equals("Search finished")) {
System.out.println("Lang search finished");
} else {
e.printStackTrace();
}
}
}
final String locale = getProject().getProperty("document.locale");
if (locale != null && getProject().getProperty("document.language") == null) {
setActiveProjectProperty("document.language",
locale.substring(0, locale.length() < 2 ? locale.length(): 2));
}
}
private class DefaultHandlerImpl
extends DefaultHandler {
public void startElement(String uri, String localName, String qName, Attributes attributes) throws SAXException {
String processedString;
String classAttr = attributes.getValue("class");
String langAttr = attributes.getValue("xml:lang");
if(classAttr != null && langAttr != null) {
if ((classAttr.indexOf(" map/map ") > -1) ||
(classAttr.indexOf(" topic/topic ") > -1)) {
String partProcessedString = langAttr.replace('-','_')
.toLowerCase();
int length;
if ((length = partProcessedString.length()) > 4) {
processedString
= partProcessedString.substring(0, length - 2)
+ partProcessedString.substring(length - 2, length).toUpperCase();
}
else {
processedString = partProcessedString;
}
setActiveProjectProperty("document.locale",
processedString);
/* Successfully found xml:lang, so stop parsing. */
throw new SAXException("Search finished");
}
}
}
}
/**
* Sets property in active ant project with name specified inpropertyName,
* and value specified in propertyValue parameter
*/
private void setActiveProjectProperty(String propertyName, String propertyValue) {
Project activeProject = getProject();
if (activeProject != null) {
activeProject.setProperty(propertyName, propertyValue);
}
}
}
dita-ot-1.5.3/demo/fo/xsl/ 0000775 0000000 0000000 00000000000 11671002146 0015215 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/fo/xsl/common/ 0000775 0000000 0000000 00000000000 11671002146 0016505 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/fo/xsl/common/attr-set-reflection.xsl 0000664 0000000 0000000 00000045643 11671002146 0023144 0 ustar 00root root 0000000 0000000
Warning: processAttrSetReflection can't handle xsl elements:
dita-ot-1.5.3/demo/fo/xsl/common/select-by-type.xsl 0000664 0000000 0000000 00000006746 11671002146 0022120 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/fo/xsl/common/topicmerge.xsl 0000664 0000000 0000000 00000000634 11671002146 0021376 0 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/fo/xsl/common/topicmergeImpl.xsl 0000664 0000000 0000000 00000040116 11671002146 0022217 0 ustar 00root root 0000000 0000000
<xsl:choose>
<xsl:when test="*[contains(@class,' map/topicmeta ')]/*[contains(@class,' topic/navtitle ')]">
<xsl:copy-of select="*[contains(@class,' map/topicmeta ')]/*[contains(@class,' topic/navtitle ')]/text()|
*[contains(@class,' map/topicmeta ')]/*[contains(@class,' topic/navtitle ')]/*"/>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="@navtitle"/>
</xsl:otherwise>
</xsl:choose>
#/_Connect_42__Connect_42__
dita-ot-1.5.3/demo/fo/xsl/common/topicmerge_template.xsl 0000664 0000000 0000000 00000001102 11671002146 0023260 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/fo/xsl/common/vars.xsl 0000664 0000000 0000000 00000014727 11671002146 0020223 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/fo/xsl/fo/ 0000775 0000000 0000000 00000000000 11671002146 0015621 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/fo/xsl/fo/artwork-preprocessor.xsl 0000664 0000000 0000000 00000013545 11671002146 0022576 0 ustar 00root root 0000000 0000000
Image info not found for file ''
1in,1in
200152 dita-ot-1.5.3/demo/fo/xsl/fo/bookmarks.xsl 0000664 0000000 0000000 00000014035 11671002146 0020344 0 ustar 00root root 0000000 0000000
hidehidehide
dita-ot-1.5.3/demo/fo/xsl/fo/bookmarks_1.0.xsl 0000664 0000000 0000000 00000021011 11671002146 0020712 0 ustar 00root root 0000000 0000000
hidehidehide dita-ot-1.5.3/demo/fo/xsl/fo/commons.xsl 0000664 0000000 0000000 00000310623 11671002146 0020031 0 ustar 00root root 0000000 0000000
topicSimpletopicSimpletopicChaptertopicAppendixtopicPrefacetopicParttopicAbstract
<xsl:apply-templates/>
SM™®Error in tm type. concept/concept : : yesyesyesno5[]: “” __border__top __border__bot __border__sides __border__all : : =
Disposition:
/
Status:
():
dita-ot-1.5.3/demo/fo/xsl/fo/commons_1.0.xsl 0000664 0000000 0000000 00000031547 11671002146 0020414 0 ustar 00root root 0000000 0000000
topicSimpletopicSimpletopicChaptertopicAppendixtopicPrefacetopicParttopicAbbrevListtopicBiblioListtopicBookListtopicFigureListtopicIndexListtopicTocListtopicGlossaryListtopicTradeMarkListtopicNoticestopicSimple dita-ot-1.5.3/demo/fo/xsl/fo/flag-rules.xsl 0000664 0000000 0000000 00000055732 11671002146 0020426 0 ustar 00root root 0000000 0000000
,
dita-ot-1.5.3/demo/fo/xsl/fo/flagging-preprocess.xsl 0000664 0000000 0000000 00000061644 11671002146 0022325 0 ustar 00root root 0000000 0000000
DOTXfile://file:/startflagging-insideendstartendstartendstartflagging-insideendstartflagging-insideendstartflagging-insideendborder-style:solid;border-width:1pt;border-color:color:border-style:solid;border-width:3pt;border-color:background-color:054W;;;;font-weight:font-style:text-decoration:underlineitalic;
dita-ot-1.5.3/demo/fo/xsl/fo/flagging.xsl 0000664 0000000 0000000 00000037204 11671002146 0020135 0 ustar 00root root 0000000 0000000
dvdv
dita-ot-1.5.3/demo/fo/xsl/fo/front-matter.xsl 0000664 0000000 0000000 00000020576 11671002146 0021005 0 ustar 00root root 0000000 0000000
3pt solid black1.4pc dita-ot-1.5.3/demo/fo/xsl/fo/front-matter_1.0.xsl 0000664 0000000 0000000 00000022371 11671002146 0021356 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/fo/xsl/fo/glossary.xsl 0000664 0000000 0000000 00000003755 11671002146 0020226 0 ustar 00root root 0000000 0000000 
dita-ot-1.5.3/demo/fo/xsl/fo/hi-domain.xsl 0000664 0000000 0000000 00000006371 11671002146 0020225 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/fo/xsl/fo/i18n-postprocess.xsl 0000664 0000000 0000000 00000020617 11671002146 0021520 0 ustar 00root root 0000000 0000000
[WARN] Font definition not found for the logical name or alias ''!
currFontFam =
physFontFam = disregard-shiftsdisregard-shifts[WARN] Font definition not found for the logical name or alias ''!
currFontFam =
physFontFam =
dita-ot-1.5.3/demo/fo/xsl/fo/index.xsl 0000664 0000000 0000000 00000071730 11671002146 0017470 0 ustar 00root root 0000000 0000000
[WARNING] There is no index entry found which closing range for ID=""[WARNING] There are multiple index entry found which is opening range for ID="" but there is only one which close it or ranges are overlapping.
[WARNING] There is no index entry found which opening range for ID=""[WARNING] There are multiple index entry found which closing range for ID=""alwaysalwaystrue alwaysalways dita-ot-1.5.3/demo/fo/xsl/fo/index_1.0.xsl 0000664 0000000 0000000 00000011263 11671002146 0020041 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/fo/xsl/fo/index_axf.xsl 0000664 0000000 0000000 00000033621 11671002146 0020323 0 ustar 00root root 0000000 0000000
Antenna House Index support[WARNING] There is no index entry found which closing range for ID=""[WARNING] There are multiple index entry found which is opening range for ID="" but there is only one which close it or ranges are overlapping.
[WARNING] There is no index entry found which opening range for ID=""[WARNING] There are multiple index entry found which closing range for ID=""alwaysalwaysalways
dita-ot-1.5.3/demo/fo/xsl/fo/links.xsl 0000664 0000000 0000000 00000136035 11671002146 0017501 0 ustar 00root root 0000000 0000000
DOTX#none##none#
<xsl:apply-templates select="*[contains(@class, ' topic/title ')]" mode="insert-text"/>
<xsl:apply-templates select="*[contains(@class, ' topic/title ')]" mode="insert-text"/>
#none#063W%1=
dita-ot-1.5.3/demo/fo/xsl/fo/lists.xsl 0000664 0000000 0000000 00000015326 11671002146 0017516 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/fo/xsl/fo/lot-lof.xsl 0000664 0000000 0000000 00000017373 11671002146 0017740 0 ustar 00root root 0000000 0000000
<xsl:apply-templates select="./*[contains(@class, ' topic/title ')]" mode="insert-text"/>
<xsl:apply-templates select="./*[contains(@class, ' topic/title ')]" mode="insert-text"/>
dita-ot-1.5.3/demo/fo/xsl/fo/otdita2fo_frontend.xsl 0000664 0000000 0000000 00000004545 11671002146 0022153 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/fo/xsl/fo/pr-domain.xsl 0000664 0000000 0000000 00000034132 11671002146 0020242 0 ustar 00root root 0000000 0000000
[]
* | []
<>
| [{}] dita-ot-1.5.3/demo/fo/xsl/fo/preface.xsl 0000664 0000000 0000000 00000014004 11671002146 0017755 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/fo/xsl/fo/root-processing.xsl 0000664 0000000 0000000 00000014315 11671002146 0021512 0 ustar 00root root 0000000 0000000
[ERROR] Empty href was specified for some topic reference ![ERROR] Please correct your ditamap or bookmap file.[ERROR] Topic reference (href : ) not found ![ERROR] Reference may be incorrect. Please correct your ditamap or bookmap file.Layout masters = dita-ot-1.5.3/demo/fo/xsl/fo/static-content.xsl 0000664 0000000 0000000 00000110427 11671002146 0021315 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/fo/xsl/fo/sw-domain.xsl 0000664 0000000 0000000 00000007526 11671002146 0020261 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/fo/xsl/fo/tables.xsl 0000664 0000000 0000000 00000316625 11671002146 0017640 0 ustar 00root root 0000000 0000000
0:111111*1*proportional-column-width(1.00)proportional-column-width()proportional-column-width(1.00)pcpt0110::
<xsl:apply-templates/>
ERROR: Number of columns must be specified.00auto1beforecenterafter1:0:0:021321OptionsDescription1*proportional-column-width(1)pcpt
dita-ot-1.5.3/demo/fo/xsl/fo/tables_1.0.xsl 0000664 0000000 0000000 00000105336 11671002146 0020211 0 ustar 00root root 0000000 0000000
<xsl:apply-templates/>
ERROR: Number of columns must be specified.00auto501*proportional-column-width(1.00)proportional-column-width()1*proportional-column-width(1.00)pcptfrom-table-column()
dita-ot-1.5.3/demo/fo/xsl/fo/task-elements.xsl 0000664 0000000 0000000 00000037273 11671002146 0021141 0 ustar 00root root 0000000 0000000
NO
dita-ot-1.5.3/demo/fo/xsl/fo/toc.xsl 0000664 0000000 0000000 00000032221 11671002146 0017136 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/fo/xsl/fo/toc_1.0.xsl 0000664 0000000 0000000 00000020541 11671002146 0017516 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/fo/xsl/fo/topic2fo.xsl 0000664 0000000 0000000 00000012575 11671002146 0020110 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/fo/xsl/fo/topic2fo_1.0.xsl 0000664 0000000 0000000 00000013404 11671002146 0020456 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/fo/xsl/fo/topic2fo_shell.xsl 0000664 0000000 0000000 00000003703 11671002146 0021270 0 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/fo/xsl/fo/topic2fo_shell_1.0.xsl 0000664 0000000 0000000 00000003724 11671002146 0021651 0 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/fo/xsl/fo/topic2fo_shell_1.0_axf.xsl 0000664 0000000 0000000 00000001516 11671002146 0022504 0 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/fo/xsl/fo/topic2fo_shell_1.0_axf_template.xsl 0000664 0000000 0000000 00000001664 11671002146 0024403 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/fo/xsl/fo/topic2fo_shell_1.0_template.xsl 0000664 0000000 0000000 00000004141 11671002146 0023536 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/fo/xsl/fo/topic2fo_shell_1.0_xep.xsl 0000664 0000000 0000000 00000001262 11671002146 0022520 0 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/fo/xsl/fo/topic2fo_shell_1.0_xep_template.xsl 0000664 0000000 0000000 00000001440 11671002146 0024411 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/fo/xsl/fo/topic2fo_shell_axf.xsl 0000664 0000000 0000000 00000001627 11671002146 0022131 0 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/fo/xsl/fo/topic2fo_shell_axf_template.xsl 0000664 0000000 0000000 00000001763 11671002146 0024025 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/fo/xsl/fo/topic2fo_shell_template.xsl 0000664 0000000 0000000 00000004120 11671002146 0023155 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/fo/xsl/fo/topic2fo_shell_xep.xsl 0000664 0000000 0000000 00000001140 11671002146 0022135 0 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/fo/xsl/fo/topic2fo_shell_xep_template.xsl 0000664 0000000 0000000 00000001331 11671002146 0024032 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/fo/xsl/fo/ui-domain.xsl 0000664 0000000 0000000 00000010661 11671002146 0020237 0 ustar 00root root 0000000 0000000
>
dita-ot-1.5.3/demo/h2d/ 0000775 0000000 0000000 00000000000 11671002146 0014460 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/h2d/build.xml 0000664 0000000 0000000 00000013751 11671002146 0016310 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/h2d/catalog.xml 0000664 0000000 0000000 00000001642 11671002146 0016617 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/h2d/dtd/ 0000775 0000000 0000000 00000000000 11671002146 0015233 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/h2d/dtd/xhtml-lat1.ent 0000664 0000000 0000000 00000027303 11671002146 0017743 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/h2d/dtd/xhtml-special.ent 0000664 0000000 0000000 00000010163 11671002146 0020516 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/h2d/dtd/xhtml-symbol.ent 0000664 0000000 0000000 00000033405 11671002146 0020407 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/h2d/dtd/xhtml1-frameset.dtd 0000664 0000000 0000000 00000102614 11671002146 0020755 0 ustar 00root root 0000000 0000000
%HTMLlat1;
%HTMLsymbol;
%HTMLspecial;
dita-ot-1.5.3/demo/h2d/dtd/xhtml1-strict.dtd 0000664 0000000 0000000 00000063526 11671002146 0020467 0 ustar 00root root 0000000 0000000
%HTMLlat1;
%HTMLsymbol;
%HTMLspecial;
dita-ot-1.5.3/demo/h2d/dtd/xhtml1-transitional.dtd 0000664 0000000 0000000 00000101044 11671002146 0021652 0 ustar 00root root 0000000 0000000
%HTMLlat1;
%HTMLsymbol;
%HTMLspecial;
dita-ot-1.5.3/demo/h2d/h2d.xsl 0000664 0000000 0000000 00000277137 11671002146 0015706 0 ustar 00root root 0000000 0000000
topic../dtd/concept.dtd../dtd/task.dtd../dtd/reference.dtd../dtd/topic.dtd-//OASIS//DTD DITA Concept//EN-//OASIS//DTD DITA Task//EN-//OASIS//DTD DITA Reference//EN-//OASIS//DTD DITA Topic//EN.ditaen-ush1h2h3h4h5h6h1stepsubstepCollected linksexternalpdfhtml#/pdfhtmlexternalA heading could not be converted into DITA.
The heading has been placed in a required-cleanup element.
[deprecated heading ]:
<xsl:apply-templates select="@class"/><xsl:apply-templates select="*|comment()|text()"/>A heading could not be converted into DITA.
The heading has been placed in a required-cleanup element.<xsl:apply-templates select="@class"/><xsl:apply-templates select="*|text()|comment()"/><xsl:apply-templates select="@class"/><xsl:apply-templates select="*|text()|comment()"/>A heading was mapped to an empty section.
Move any content that belongs with that heading into the section.
<xsl:choose>
<xsl:when test="$main-head-level='h1'"><xsl:value-of select=".//h1[1]"/></xsl:when>
<xsl:when test="$main-head-level='h2'"><xsl:value-of select=".//h2[1]"/></xsl:when>
<xsl:when test="$main-head-level='h3'"><xsl:value-of select=".//h3[1]"/></xsl:when>
<xsl:when test="$main-head-level='h4'"><xsl:value-of select=".//h4[1]"/></xsl:when>
<xsl:when test="$main-head-level='h5'"><xsl:value-of select=".//h5[1]"/></xsl:when>
<xsl:when test="$main-head-level='h6'"><xsl:value-of select=".//h6[1]"/></xsl:when>
</xsl:choose>
NONONONONONONOYESyesfalsefalsetruefalsetrueCLEANUP ACTION: Determine the original intent for a BR tag.A BR tag was used here in the original source.break ===================== horizontal rule =====================
Removed anchor point Removed anchor point
11The summary attribute on tables cannot be converted to DITA.
The attribute's contents were placed in a comment before the table.
span.}[b][i][u][tt][normal]span.}CLEANUP ACTION: provide a better phrase markup for a SPAN tag.
The element's contents have been placed in a phrase element.
There is a comment next to the phrase with the span's class value.Original: <span @class=>, =CLEANUP ACTION: provide a better phrase markup for a SPAN tag.
The element's contents have been placed in a phrase element.
There is a comment next to the phrase with the span's class value.Original: <span @class=>
CLEANUP ACTION: provide a better phrase markup for a BIG or SMALL tag.
The element's contents have been placed in a required-cleanup element.CLEANUP ACTION: provide a better phrase markup for a strikethrough tag.
The element's contents have been placed in a required-cleanup element.
CLEANUP ACTION: no DITA equivalent for HTML element ''.
The element has been placed in a required-cleanup element.'' is an invalid infotype, use 'topic' as the default infotype.'' is an invalid dita extension, please use '.dita' or '.xml' as the dita extension.The parameter FILENAME should ends with '.htm' or '.html'.
dita-ot-1.5.3/demo/h2d/plugin.xml 0000664 0000000 0000000 00000000650 11671002146 0016501 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/h2d/preprocess.xsl 0000664 0000000 0000000 00000002034 11671002146 0017374 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/h2d/samples/ 0000775 0000000 0000000 00000000000 11671002146 0016124 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/h2d/samples/concept.html 0000664 0000000 0000000 00000001356 11671002146 0020452 0 ustar 00root root 0000000 0000000
A concept topic
A concept topic
Introductory block text.
The first section
Section block text.
The second section
Section block text.
dita-ot-1.5.3/demo/h2d/samples/content.html 0000664 0000000 0000000 00000004110 11671002146 0020460 0 ustar 00root root 0000000 0000000
A topic with content examples
dita-ot-1.5.3/demo/tocjs/basefiles/treeview.js 0000664 0000000 0000000 00000143201 11671002146 0021253 0 ustar 00root root 0000000 0000000 /*
This file is part of the DITA Open Toolkit project hosted on
Sourceforge.net. See the accompanying license.txt file for
applicable licenses.
Copyright (c) 2006, Yahoo! Inc. All rights reserved.
Code licensed under the BSD License:
http://developer.yahoo.net/yui/license.txt
version: 0.10.0
*/
/* Copyright (c) 2006 Yahoo! Inc. All rights reserved. */
/**
* Contains the tree view state data and the root node. This is an
* ordered tree; child nodes will be displayed in the order created, and
* there currently is no way to change this.
*
* @constructor
* @todo graft (appendBefore, appendAfter)
* @param {string} id The id of the element that the tree will be inserted
* into.
*/
YAHOO.widget.TreeView = function(id) {
if (id) { this.init(id); }
};
/**
* Count of all nodes in all trees
* @type int
*/
YAHOO.widget.TreeView.nodeCount = 0;
YAHOO.widget.TreeView.prototype = {
/**
* The id of tree container element
*
* @type String
*/
id: null,
/**
* Flat collection of all nodes in this tree
*
* @type Node[]
* @private
*/
_nodes: null,
/**
* We lock the tree control while waiting for the dynamic loader to return
*
* @type boolean
*/
locked: false,
/**
* The animation to use for expanding children, if any
*
* @type string
* @private
*/
_expandAnim: null,
/**
* The animation to use for collapsing children, if any
*
* @type string
* @private
*/
_collapseAnim: null,
/**
* The current number of animations that are executing
*
* @type int
* @private
*/
_animCount: 0,
/**
* The maximum number of animations to run at one time.
*
* @type int
*/
maxAnim: 2,
/**
* Sets up the animation for expanding children
*
* @param {string} the type of animation (acceptable constants in YAHOO.widget.TVAnim)
*/
setExpandAnim: function(type) {
if (YAHOO.widget.TVAnim.isValid(type)) {
this._expandAnim = type;
}
},
/**
* Sets up the animation for collapsing children
*
* @param {string} the type of animation (acceptable constants in YAHOO.widget.TVAnim)
*/
setCollapseAnim: function(type) {
if (YAHOO.widget.TVAnim.isValid(type)) {
this._collapseAnim = type;
}
},
/**
* Perform the expand animation if configured, or just show the
* element if not configured or too many animations are in progress
*
* @param el {HTMLElement} the element to animate
* @return {boolean} true if animation could be invoked, false otherwise
*/
animateExpand: function(el) {
if (this._expandAnim && this._animCount < this.maxAnim) {
// this.locked = true;
var tree = this;
var a = YAHOO.widget.TVAnim.getAnim(this._expandAnim, el,
function() { tree.expandComplete(); });
if (a) {
++this._animCount;
a.animate();
}
return true;
}
return false;
},
/**
* Perform the collapse animation if configured, or just show the
* element if not configured or too many animations are in progress
*
* @param el {HTMLElement} the element to animate
* @return {boolean} true if animation could be invoked, false otherwise
*/
animateCollapse: function(el) {
if (this._collapseAnim && this._animCount < this.maxAnim) {
// this.locked = true;
var tree = this;
var a = YAHOO.widget.TVAnim.getAnim(this._collapseAnim, el,
function() { tree.collapseComplete(); });
if (a) {
++this._animCount;
a.animate();
}
return true;
}
return false;
},
/**
* Function executed when the expand animation completes
*/
expandComplete: function() {
--this._animCount;
// this.locked = false;
},
/**
* Function executed when the collapse animation completes
*/
collapseComplete: function() {
--this._animCount;
// this.locked = false;
},
/**
* Initializes the tree
*
* @parm {string} id the id of the element that will hold the tree
* @private
*/
init: function(id) {
this.id = id;
this._nodes = [];
// store a global reference
YAHOO.widget.TreeView.trees[id] = this;
// Set up the root node
this.root = new YAHOO.widget.RootNode(this);
},
/**
* Renders the tree boilerplate and visible nodes
*/
draw: function() {
var html = this.root.getHtml();
if(document.getElementById(this.id))
document.getElementById(this.id).innerHTML = html;
/*document.getElementById(this.id).innerHTML = html;*/
this.firstDraw = false;
},
/**
* Nodes register themselves with the tree instance when they are created.
*
* @param node {Node} the node to register
* @private
*/
regNode: function(node) {
this._nodes[node.index] = node;
},
/**
* Returns the root node of this tree
*
* @return {Node} the root node
*/
getRoot: function() {
return this.root;
},
/**
* Configures this tree to dynamically load all child data
*
* @param {function} fnDataLoader the function that will be called to get the data
* @param iconMode {int} configures the icon that is displayed when a dynamic
* load node is expanded the first time without children. By default, the
* "collapse" icon will be used. If set to 1, the leaf node icon will be
* displayed.
*/
setDynamicLoad: function(fnDataLoader, iconMode) {
this.root.setDynamicLoad(fnDataLoader, iconMode);
},
/**
* Expands all child nodes. Note: this conflicts with the "multiExpand"
* node property. If expand all is called in a tree with nodes that
* do not allow multiple siblings to be displayed, only the last sibling
* will be expanded.
*/
expandAll: function() {
if (!this.locked) {
this.root.expandAll();
}
},
/**
* Collapses all expanded child nodes in the entire tree.
*/
collapseAll: function() {
if (!this.locked) {
this.root.collapseAll();
}
},
/**
* Returns a node in the tree that has the specified index (this index
* is created internally, so this function probably will only be used
* in html generated for a given node.)
*
* @param {int} nodeIndex the index of the node wanted
* @return {Node} the node with index=nodeIndex, null if no match
*/
getNodeByIndex: function(nodeIndex) {
var n = this._nodes[nodeIndex];
return (n) ? n : null;
},
/**
* Returns a node that has a matching property and value in the data
* object that was passed into its constructor. Provides a flexible
* way for the implementer to get a particular node.
*
* @param {object} property the property to search (usually a string)
* @param {object} value the value we want to find (usuall an int or string)
* @return {Node} the matching node, null if no match
*/
getNodeByProperty: function(property, value) {
for (var i in this._nodes) {
var n = this._nodes[i];
if (n.data && value == n.data[property]) {
return n;
}
}
return null;
},
/**
* Removes the node and its children, and optionally refreshes the branch
* of the tree that was affected.
* @param {Node} The node to remove
* @param {boolean} autoRefresh automatically refreshes branch if true
* @return {boolean} False is there was a problem, true otherwise.
*/
removeNode: function(node, autoRefresh) {
// Don't delete the root node
if (node.isRoot()) {
return false;
}
// Get the branch that we may need to refresh
var p = node.parent;
if (p.parent) {
p = p.parent;
}
// Delete the node and its children
this._deleteNode(node);
// Refresh the parent of the parent
if (autoRefresh && p && p.childrenRendered) {
p.refresh();
}
return true;
},
/**
* Deletes this nodes child collection, recursively. Also collapses
* the node, and resets the dynamic load flag. The primary use for
* this method is to purge a node and allow it to fetch its data
* dynamically again.
* @param {Node} node the node to purge
*/
removeChildren: function(node) {
for (var i=0, len=node.children.length;i ';
}
var f = document.createElement("div");
var s = f.style;
s.position = "absolute";
s.top = "-1000px";
s.left = "-1000px";
f.innerHTML = sb.join("");
document.body.appendChild(f);
};
YAHOO.widget.TreeView.addHandler(window,
"load", YAHOO.widget.TreeView.preload);
/* Copyright (c) 2006 Yahoo! Inc. All rights reserved. */
/**
* The base class for all tree nodes. The node's presentation and behavior in
* response to mouse events is handled in Node subclasses.
*
* @param oData {object} a string or object containing the data that will
* be used to render this node
* @param oParent {Node} this node's parent node
* @param expanded {boolean} the initial expanded/collapsed state
* @constructor
*/
YAHOO.widget.Node = function(oData, oParent, expanded) {
if (oParent) { this.init(oData, oParent, expanded); }
};
YAHOO.widget.Node.prototype = {
/**
* The index for this instance obtained from global counter in YAHOO.widget.TreeView.
*
* @type int
*/
index: 0,
/**
* This node's child node collection.
*
* @type Node[]
*/
children: null,
/**
* Tree instance this node is part of
*
* @type TreeView
*/
tree: null,
/**
* The data linked to this node. This can be any object or primitive
* value, and the data can be used in getNodeHtml().
*
* @type object
*/
data: null,
/**
* Parent node
*
* @type Node
*/
parent: null,
/**
* The depth of this node. We start at -1 for the root node.
*
* @type int
*/
depth: -1,
/**
* The href for the node's label. If one is not specified, the href will
* be set so that it toggles the node.
*
* @type string
*/
href: null,
/**
* The label href target, defaults to current window
*
* @type string
*/
target: "_self",
/**
* The node's expanded/collapsed state
*
* @type boolean
*/
expanded: false,
/**
* Can multiple children be expanded at once?
*
* @type boolean
*/
multiExpand: true,
/**
* Should we render children for a collapsed node? It is possible that the
* implementer will want to render the hidden data... @todo verify that we
* need this, and implement it if we do.
*
* @type boolean
*/
renderHidden: false,
/**
* This flag is set to true when the html is generated for this node's
* children, and set to false when new children are added.
* @type boolean
*/
childrenRendered: false,
/**
* Dynamically loaded nodes only fetch the data the first time they are
* expanded. This flag is set to true once the data has been fetched.
* @type boolean
*/
dynamicLoadComplete: false,
/**
* This node's previous sibling
*
* @type Node
*/
previousSibling: null,
/**
* This node's next sibling
*
* @type Node
*/
nextSibling: null,
/**
* We can set the node up to call an external method to get the child
* data dynamically.
*
* @type boolean
* @private
*/
_dynLoad: false,
/**
* Function to execute when we need to get this node's child data.
*
* @type function
*/
dataLoader: null,
/**
* This is true for dynamically loading nodes while waiting for the
* callback to return.
*
* @type boolean
*/
isLoading: false,
/**
* The toggle/branch icon will not show if this is set to false. This
* could be useful if the implementer wants to have the child contain
* extra info about the parent, rather than an actual node.
*
* @type boolean
*/
hasIcon: true,
/**
* Used to configure what happens when a dynamic load node is expanded
* and we discover that it does not have children. By default, it is
* treated as if it still could have children (plus/minus icon). Set
* iconMode to have it display like a leaf node instead.
* @type int
*/
iconMode: 0,
/**
* The node type
* @private
*/
_type: "Node",
/*
spacerPath: "http://us.i1.yimg.com/us.yimg.com/i/space.gif",
expandedText: "Expanded",
collapsedText: "Collapsed",
loadingText: "Loading",
*/
/**
* Initializes this node, gets some of the properties from the parent
*
* @param oData {object} a string or object containing the data that will
* be used to render this node
* @param oParent {Node} this node's parent node
* @param expanded {boolean} the initial expanded/collapsed state
*/
init: function(oData, oParent, expanded) {
this.data = oData;
this.children = [];
this.index = YAHOO.widget.TreeView.nodeCount;
++YAHOO.widget.TreeView.nodeCount;
this.expanded = expanded;
// oParent should never be null except when we create the root node.
if (oParent) {
this.tree = oParent.tree;
this.parent = oParent;
this.href = "javascript:" + this.getToggleLink();
this.depth = oParent.depth + 1;
this.multiExpand = oParent.multiExpand;
oParent.appendChild(this);
}
},
/**
* Appends a node to the child collection.
*
* @param node {Node} the new node
* @return {Node} the child node
* @private
* @TODO insertBefore, insertAfter
*/
appendChild: function(node) {
if (this.hasChildren()) {
var sib = this.children[this.children.length - 1];
sib.nextSibling = node;
node.previousSibling = sib;
}
this.tree.regNode(node);
this.children[this.children.length] = node;
this.childrenRendered = false;
return node;
},
/**
* Returns a node array of this node's siblings, null if none.
*
* @return Node[]
*/
getSiblings: function() {
return this.parent.children;
},
/**
* Shows this node's children
*/
showChildren: function() {
if (!this.tree.animateExpand(this.getChildrenEl())) {
if (this.hasChildren()) {
this.getChildrenEl().style.display = "";
}
}
},
/**
* Hides this node's children
*/
hideChildren: function() {
if (!this.tree.animateCollapse(this.getChildrenEl())) {
this.getChildrenEl().style.display = "none";
}
},
/**
* Returns the id for this node's container div
*
* @return {string} the element id
*/
getElId: function() {
return "ygtv" + this.index;
},
/**
* Returns the id for this node's children div
*
* @return {string} the element id for this node's children div
*/
getChildrenElId: function() {
return "ygtvc" + this.index;
},
/**
* Returns the id for this node's toggle element
*
* @return {string} the toggel element id
*/
getToggleElId: function() {
return "ygtvt" + this.index;
},
/**
* Returns the id for this node's spacer image. The spacer is positioned
* over the toggle and provides feedback for screen readers.
* @return {string} the id for the spacer image
*/
/*
getSpacerId: function() {
return "ygtvspacer" + this.index;
},
*/
/**
* Returns this node's container html element
* @return {HTMLElement} the container html element
*/
getEl: function() {
return document.getElementById(this.getElId());
},
/**
* Returns the div that was generated for this node's children
* @return {HTMLElement} this node's children div
*/
getChildrenEl: function() {
return document.getElementById(this.getChildrenElId());
},
/**
* Returns the element that is being used for this node's toggle.
* @return {HTMLElement} this node's toggle html element
*/
getToggleEl: function() {
return document.getElementById(this.getToggleElId());
},
/**
* Returns the element that is being used for this node's spacer.
* @return {HTMLElement} this node's spacer html element
*/
/*
getSpacer: function() {
return document.getElementById( this.getSpacerId() ) || {};
},
*/
/*
getStateText: function() {
if (this.isLoading) {
return this.loadingText;
} else if (this.hasChildren(true)) {
if (this.expanded) {
return this.expandedText;
} else {
return this.collapsedText;
}
} else {
return "";
}
},
*/
/**
* Generates the link that will invoke this node's toggle method
* @return {string} the javascript url for toggling this node
*/
getToggleLink: function() {
return "YAHOO.widget.TreeView.getNode(\'" + this.tree.id + "\'," +
this.index + ").toggle()";
},
/**
* Hides this nodes children (creating them if necessary), changes the
* toggle style.
*/
collapse: function() {
// Only collapse if currently expanded
if (!this.expanded) { return; }
// fire the collapse event handler
var ret = this.tree.onCollapse(this);
if ("undefined" != typeof ret && !ret) {
return;
}
if (!this.getEl()) {
this.expanded = false;
return;
}
// hide the child div
this.hideChildren();
this.expanded = false;
if (this.hasIcon) {
this.getToggleEl().className = this.getStyle();
}
// this.getSpacer().title = this.getStateText();
},
/**
* Shows this nodes children (creating them if necessary), changes the
* toggle style, and collapses its siblings if multiExpand is not set.
*/
expand: function() {
// Only expand if currently collapsed.
if (this.expanded) { return; }
// fire the expand event handler
var ret = this.tree.onExpand(this);
if ("undefined" != typeof ret && !ret) {
return;
}
if (!this.getEl()) {
this.expanded = true;
return;
}
if (! this.childrenRendered) {
this.getChildrenEl().innerHTML = this.renderChildren();
} else {
}
this.expanded = true;
if (this.hasIcon) {
this.getToggleEl().className = this.getStyle();
}
// this.getSpacer().title = this.getStateText();
// We do an extra check for children here because the lazy
// load feature can expose nodes that have no children.
// if (!this.hasChildren()) {
if (this.isLoading) {
this.expanded = false;
return;
}
if (! this.multiExpand) {
var sibs = this.getSiblings();
for (var i=0; i 0 ||
(checkForLazyLoad && this.isDynamic() && !this.dynamicLoadComplete) );
},
/**
* Expands if node is collapsed, collapses otherwise.
*/
toggle: function() {
if (!this.tree.locked && ( this.hasChildren(true) || this.isDynamic()) ) {
if (this.expanded) { this.collapse(); } else { this.expand(); }
}
},
/**
* Returns the markup for this node and its children.
*
* @return {string} the markup for this node and its expanded children.
*/
getHtml: function() {
var sb = [];
sb[sb.length] = '
';
return sb.join("");
},
/**
* Called when first rendering the tree. We always build the div that will
* contain this nodes children, but we don't render the children themselves
* unless this node is expanded.
*
* @return {string} the children container div html and any expanded children
* @private
*/
getChildrenHtml: function() {
var sb = [];
sb[sb.length] = '
= this.depth || depth < 0) {
return null;
}
var p = this.parent;
while (p.depth > depth) {
p = p.parent;
}
return p;
},
/**
* Returns the css class for the spacer at the specified depth for
* this node. If this node's ancestor at the specified depth
* has a next sibling the presentation is different than if it
* does not have a next sibling
*
* @param {int} depth the depth of the ancestor.
* @return {string} the css class for the spacer
*/
getDepthStyle: function(depth) {
return (this.getAncestor(depth).nextSibling) ?
"ygtvdepthcell" : "ygtvblankdepthcell";
},
/**
* Get the markup for the node. This is designed to be overrided so that we can
* support different types of nodes.
*
* @return {string} The HTML that will render this node.
*/
getNodeHtml: function() {
return "";
},
/**
* Regenerates the html for this node and its children. To be used when the
* node is expanded and new children have been added.
*/
refresh: function() {
// this.loadComplete();
this.getChildrenEl().innerHTML = this.completeRender();
if (this.hasIcon) {
var el = this.getToggleEl();
if (el) {
el.className = this.getStyle();
}
}
}
};
/* Copyright (c) 2006 Yahoo! Inc. All rights reserved. */
/**
* A custom YAHOO.widget.Node that handles the unique nature of
* the virtual, presentationless root node.
*
* @extends YAHOO.widget.Node
* @constructor
*/
YAHOO.widget.RootNode = function(oTree) {
// Initialize the node with null params. The root node is a
// special case where the node has no presentation. So we have
// to alter the standard properties a bit.
this.init(null, null, true);
/**
* For the root node, we get the tree reference from as a param
* to the constructor instead of from the parent element.
*
* @type TreeView
*/
this.tree = oTree;
};
YAHOO.widget.RootNode.prototype = new YAHOO.widget.Node();
// overrides YAHOO.widget.Node
YAHOO.widget.RootNode.prototype.getNodeHtml = function() {
return "";
};
/* Copyright (c) 2006 Yahoo! Inc. All rights reserved. */
/**
* The default node presentation. The first parameter should be
* either a string that will be used as the node's label, or an object
* that has a string propery called label. By default, the clicking the
* label will toggle the expanded/collapsed state of the node. By
* changing the href property of the instance, this behavior can be
* changed so that the label will go to the specified href.
*
* @extends YAHOO.widget.Node
* @constructor
* @param oData {object} a string or object containing the data that will
* be used to render this node
* @param oParent {YAHOO.widget.Node} this node's parent node
* @param expanded {boolean} the initial expanded/collapsed state
*/
YAHOO.widget.TextNode = function(oData, oParent, expanded) {
this.type = "TextNode";
if (oParent) {
this.init(oData, oParent, expanded);
this.setUpLabel(oData);
}
};
YAHOO.widget.TextNode.prototype = new YAHOO.widget.Node();
/**
* The CSS class for the label href. Defaults to ygtvlabel, but can be
* overridden to provide a custom presentation for a specific node.
*
* @type string
*/
YAHOO.widget.TextNode.prototype.labelStyle = "ygtvlabel";
/**
* The derived element id of the label for this node
*
* @type string
*/
YAHOO.widget.TextNode.prototype.labelElId = null;
/**
* The text for the label. It is assumed that the oData parameter will
* either be a string that will be used as the label, or an object that
* has a property called "label" that we will use.
*
* @type string
*/
YAHOO.widget.TextNode.prototype.label = null;
/**
* Sets up the node label
*
* @param oData string containing the label, or an object with a label property
*/
YAHOO.widget.TextNode.prototype.setUpLabel = function(oData) {
if (typeof oData == "string") {
oData = { label: oData };
}
this.label = oData.label;
// update the link
if (oData.href) {
this.href = oData.href;
}
// set the target
if (oData.target) {
this.target = oData.target;
}
if (oData.style) {
this.labelStyle = oData.style;
}
this.labelElId = "ygtvlabelel" + this.index;
};
/**
* Returns the label element
*
* @return {object} the element
*/
YAHOO.widget.TextNode.prototype.getLabelEl = function() {
return document.getElementById(this.labelElId);
};
// overrides YAHOO.widget.Node
YAHOO.widget.TextNode.prototype.getNodeHtml = function() {
var sb = [];
sb[sb.length] = '
';
sb[sb.length] = '
';
for (i=0;i ';
}
var getNode = 'YAHOO.widget.TreeView.getNode(\'' +
this.tree.id + '\',' + this.index + ')';
sb[sb.length] = '';
/*
sb[sb.length] = ' ';
}
if (this.hasIcon) {
sb[sb.length] = '
dita-ot-1.5.3/demo/tocjs/integrator.xml 0000664 0000000 0000000 00000002251 11671002146 0020025 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/tocjs/license.txt 0000664 0000000 0000000 00000001343 11671002146 0017311 0 ustar 00root root 0000000 0000000 The DITA Open Toolkit is licensed for use, at the user's election, under the
Common Public License v1.0 or the Apache Software Foundation License v2.0.
If, at the time of use, the Project Management Committee has designated another
version of these licenses or another license as being applicable to the
DITA Open Toolkit, user may select to have its subsequent use of the
DITA Open Toolkit governed by such other designated license.
A copy of the Common Public License 1.0 is
available at
http://opensource.org/licenses/cpl.php
A copy of the Apache Software Foundation License 2.0 is available at
http://opensource.org/licenses/apache2.0.php
This statement must be included in any copies of DITA Open Toolkit code. dita-ot-1.5.3/demo/tocjs/plugin.xml 0000664 0000000 0000000 00000000650 11671002146 0017146 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/tocjs/sample/ 0000775 0000000 0000000 00000000000 11671002146 0016406 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/tocjs/sample/basefiles/ 0000775 0000000 0000000 00000000000 11671002146 0020343 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/tocjs/sample/basefiles/frameset.html 0000664 0000000 0000000 00000001016 11671002146 0023035 0 ustar 00root root 0000000 0000000
Documentation for TOCJS
dita-ot-1.5.3/demo/tocjs/sample/basefiles/sample.css 0000664 0000000 0000000 00000016621 11671002146 0022344 0 ustar 00root root 0000000 0000000
/*
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 Shawn McKenzie, 2007. All Rights Reserved.
*-->
*/
html,body {
margin:25;
padding:0px 0px 20px 0px;
background-color:#F2F4F4;
font-family: Arial, Helvetica, sans-serif;
font-size: 12px;
color:#494949;
}
a:link {text-decoration:underline; color:#015589;}
a:visited {text-decoration:underline; color:#015589;}
a:active {text-decoration:underline; color:#015589;}
a:hover {text-decoration:none; color:#799CD5;}
.menu {font-size: 11px; font-family: arial;}
.keyword {text-decoration: none; }
.taskintro {font-style: italic; }
/* class terms */
.relconcepts a { display: list-item; margin: 0px 20px 0px; list-style: url outside; list-style-image: url(ajtest/images/arw_subcat.gif); }
.reltasks a { display: list-item; margin: 0px 20px 0px; list-style: url outside; list-style-image: url(ajtest/images/arw_subcat.gif); }
.relinfo a { display: list-item; margin: 0px 20px 0px; list-style: url outside; list-style-image: url(ajtest/images/arw_subcat.gif); }
/*.term { display: list-item; margin: 0px 20px 0px; list-style: url outside; list-style-image: url(images/arw_subcat.gif); }*/
a.term { color: #015589; font-weight: normal; }
a.term:hover { color: #799CD5; font-weight: normal; }
.linklist a { display: list-item; margin: 0px 20px 0px; list-style: url outside; list-style-image: url(images/arw_subcat.gif); }
.ullinks { display: list-item; list-style: url outside; list-style-image: url(ajtest/images/arw_subcat.gif); }
/* class definitions */
.unresolved { background-color: skyblue; }
.noTemplate { background-color: yellow; }
.base { background-color: #ffffff; }
/* Add space for top level topics */
.nested0 { margin-top : 1em;}
/* div with class=p is used for paragraphs that contain blocks, to keep the XHTML valid */
.p {margin-top: 1em}
/* Default of italics to set apart figure captions */
.figcap { font-style: italic }
.figdesc { font-style: normal }
/* Use @frame to create frames on figures */
.figborder { border-style: solid; padding-left : 3px; border-width : 2px; padding-right : 3px; margin-top: 1em; border-color : Silver;}
.figsides { border-left : 2px solid; padding-left : 3px; border-right : 2px solid; padding-right : 3px; margin-top: 1em; border-color : Silver;}
.figtop { border-top : 2px solid; margin-top: 1em; border-color : Silver;}
.figbottom { border-bottom : 2px solid; border-color : Silver;}
.figtopbot { border-top : 2px solid; border-bottom : 2px solid; margin-top: 1em; border-color : Silver;}
/* Most link groups are created with
The tocjs plugin generates a Table of Contents for the DITA Open Toolkit's XHTML output that can expand and
collapse nodes. It is a more usable and visually pleasing option than the standard
index.html generated by the Open Toolkit's dita2html
transformation.
The JavaScript code used in this plugin is derived from the Yahoo YUI Treeview widget. This
plugin goes a long way to making DITA XHTML output slick and professional looking for a web site
or custom built help engine. But, you will need to customize several things to get it working
properly with your project.
All examples in this documentation assume a Unix style file separator. If you
are on a Windows machine, replace the '/' character with a '\'
character for all file paths.Yahoo! Treeview Widgethttp://developer.yahoo.com/yui/treeview/Sophos tocjs outputhttp://wsa.sophos.com/docs/ws1000/
dita-ot-1.5.3/demo/tocjs/sample/concepts/anttasks.xml 0000664 0000000 0000000 00000005421 11671002146 0022600 0 ustar 00root root 0000000 0000000
Ant tasks
The tocjs extension is meant to work with a project that generates HTML. For instance, assume you have an existing ant task:
<target name="myproj2html" depends="use-init">
<antcall target="dita2xhtml">
<param name="args.input"
value="projects${file.separator}myproject${file.separator}GettingStartedGuide.ditamap"/>
<param name="output.dir" value="output${file.separator}myproject"/>
<param name="args.css" value="testvalue.css"/>
</antcall>
</target>
To create tocjs JavaScript output and copy related topics into place, you could create the following
ant target.
<target name="myproj2tocjs" description="Generate tocjs javascript file">
<antcall target="dita2tocjs">
<param name="transtype" value="tocjs"/>
<param name="args.input"
value="projects${file.separator}myproject${file.separator}GettingStartedGuide.ditamap"/>
<param name="output.file"
value="output${file.separator}myproject${file.separator}myproject${file.separator}toctree.js"/>
</antcall>
<copy todir="output${file.separator}myproject${file.separator}myproject">
<fileset dir="${dita.dir}${file.separator}demo${file.separator}tocjs${file.separator}basefiles">
<include name="**/*"/></fileset>
</copy>
</target>
The above task generates tocjs output and copies the related files from the tocjs
basefiles directory. You will also need to maitan and copy into place a
frameset file. For an exaple of how this is done, take a look at the ant tasks in
demo/tocjs/buildsample.xml and the related basefiles
directories
For more examples of working ant tasks, check the
buildsample.xmlfile in the demo/tocjs directory.
dita-ot-1.5.3/demo/tocjs/sample/concepts/basefiles.xml 0000664 0000000 0000000 00000003267 11671002146 0022713 0 ustar 00root root 0000000 0000000
The <filepath>basefiles</filepath> directories
When you set up a project to build tocjs output, you will likely want to pull source files from
two separate locations. The tocjs plugin has a basefiles directory that
includes HTML, JavaScript, image and CSS files necessary for the tocjs plugin to work. The tocjs
transtype itself generates a JavaScript file (toctree.js) that is used in
conjunction with the files in this basefiles directory. As you can see in
the sample ant tasks in demo/tocjs/buildsample.xml.
You will likely want to maintain another basefiles directory along with
your DITA source files and copy these into your output as well. If you look in the
tocjs sample project there is a different basefiles
directory. This contains the CSS file related to the DITA content and the
frameset.html file. These are specific to the project, while the files in
demo/tocjs/basefiles are for any project using the tocjs plugin.
The tocjs plugin is designed to be integrated into the DITA Open Toolkit so that you have
tocjs as a registered transtype. This transtype can then be used in conjunction
with the XHTML output. This plugin has been tested (somewhat) on the 1.2.2 toolkit version, but
it works with the 1.3 versions as well. There are some known issues, and likely many unknown
issues. Please report any issues to smckenzie23@gmail.com. You may also be able to find people
who can help on the dita-users Yahoo! Group. You can also find the latest version of the tocjs
plugin in the files area of the dita-users Yahoo! group.
The topicref.xsl file hard codes contentwin into the code
to display content. This matches the supplied frameset.html file, but does
not support passing in a contenttarget parameter from the ant task.
The tocjs plugin includes original code and code from the Yahoo UI Library treeview widget.
Both are licensed under the BSD license, and distributed with the DITA Open Toolkit under both
the Common Public License 1.0 and the Apache License 2.0.
Conditions
Redistribution and use in source and binary forms, with or without modification, are permitted
provided that the following conditions are met:
Redistributions of source code must retain the above copyright notice, this list of
conditions and the following disclaimer.
Redistributions in binary form must reproduce the above copyright notice, this list of
conditions and the following disclaimer in the documentation and/or other materials provided
with the distribution.
Neither the name of the copyright holders nor the names of the contributors may be used to
endorse or promote products derived from this software without specific prior written
permission.
DISCLAIMER
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
The sample documents and related ant tasks work for a relatively simple directory structure.
They
assume that your content and output directory structure will be something like:
sample/
|-- basefiles
|-- concepts
`-- tasks
However, if your ditamap refers to content in other parallel project directories, your output
will have a deeper path to the same files. For instance, imagine your ditamap file is in the root of
the sample directory, but it includes a reference to a topic in
other such as:
<topicref href="concepts/foo.xml">
<topicref href="concepts/bar.xml"/>
<topicref href="../other/concepts/baz.xml"/>
</topicref>
Referencing content in this way will force a deeper nesting to the output directory. The
directory structure of your content in the output directory would now be:
sample/
|-- other
| `-- concepts
`-- sample
|-- concepts
`-- tasks
Note that there are now two sample directories in the output, the main one and one that is a
sibling to the other directory. The files are generated by the
Open Toolkit for the sample project now wind up in the deeper nested sample
directory.
To modify existing ant tasks to work with a project that shares content with a peer
project:
Modify the output.file parameter so that it will create
toctree.js in the deeper project output
directory.Modify the copy elements to copy the tocjs
basefiles files into the deeper project output
directory.Modify your frameset file so that the tocwin and
contentwin frames point to the correct files in the deeper
nested project directory.
dita-ot-1.5.3/demo/tocjs/sample/tasks/buildsample.xml 0000664 0000000 0000000 00000004154 11671002146 0022562 0 ustar 00root root 0000000 0000000
Build TOCJS sample output
This task will walk you through building the tocjs sample documentation. First, be
sure you have installed and integrated the tocjs plugin.
Change directories to the sample directory of the tocjs
plugin.This should be in the demotocjssample directory
Type ant -f buildtocjs.xml sample2htmlThe sample2html task generates XHTML, and tocjs output and copies
related JavaScript and a frameset.html file into outtocjs in your base DITA directory.
From your base DITA directory, open outtocjsframeset.html in a JavaScript-enabled browser.
dita-ot-1.5.3/demo/tocjs/sample/tasks/integrate.xml 0000664 0000000 0000000 00000004457 11671002146 0022251 0 ustar 00root root 0000000 0000000
Integrate and test
Once you have obtained the latest tocjs plugin, you need to install and integrate it
into the DITA Open Toolkit
Obtain the latest version of the tocjs plugin.Unzip the plugin in your demo directory.This should give you a tocjs
directory.From your base DITA directory, type:ant -f
integrator.xml.You should see output similar to the following message:
Buildfile: integrator.xml
BUILD SUCCESSFUL
Total time: 1 seconds
The tocjs transtype should be registered with the Open Toolkit.Type: ant -f demo/tocjs/buildsample.xml sample2tocjs.The end of the message output should say:
dita2tocjs:
BUILD SUCCESSFUL
Total time: 6 seconds
Open demo/tocjs/out/sample/frameset.html in a browser.This documentation should be displayed in a frameset that includes a
JavaScript TOC in the left pane.
dita-ot-1.5.3/demo/tocjs/sample/tocjs.ditamap 0000664 0000000 0000000 00000001724 11671002146 0021075 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/tocjs/xsl/ 0000775 0000000 0000000 00000000000 11671002146 0015733 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/demo/tocjs/xsl/gethref.xsl 0000664 0000000 0000000 00000003010 11671002146 0020101 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/demo/tocjs/xsl/jstext.xsl 0000664 0000000 0000000 00000004401 11671002146 0020003 0 ustar 00root root 0000000 0000000
',:><'\',\,:\:/>
dita-ot-1.5.3/demo/tocjs/xsl/tocjs.xsl 0000664 0000000 0000000 00000007163 11671002146 0017614 0 ustar 00root root 0000000 0000000
At slash, contentwin is
########################################################################
### ###
### The 'content.frame' property is not set in your tocjs ant task! ###
### Using 'contentwin' as a default. ###
### ###
########################################################################
########################################
### Your 'content.frame' property is set to '' ###
########################################
var tree;
function treeInit() {
tree = new YAHOO.widget.TreeView("treeDiv1");
var root = tree.getRoot();
tree.draw();
}
YAHOO.util.Event.addListener(window, "load", treeInit);
WARNING! navref not supported. WARNING! anchor not supported.
dita-ot-1.5.3/demo/tocjs/xsl/topichead.xsl 0000664 0000000 0000000 00000002752 11671002146 0020431 0 ustar 00root root 0000000 0000000
'
######################## IN TOPICHEAD! parent: self: var = new YAHOO.widget.TextNode("", , false);
dita-ot-1.5.3/demo/tocjs/xsl/topicref.xsl 0000664 0000000 0000000 00000016604 11671002146 0020305 0 ustar 00root root 0000000 0000000
'\',"\"var = { label: "", href:"", target:"" };
var = new YAHOO.widget.TextNode(, , false);var = new YAHOO.widget.TextNode("", , false);var = new YAHOO.widget.TextNode("", , false);
dita-ot-1.5.3/ditatargets.xml 0000664 0000000 0000000 00000057565 11671002146 0016136 0 ustar 00root root 0000000 0000000 dita-ot-1.5.3/doc/ 0000775 0000000 0000000 00000000000 11671002146 0013624 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/doc/DITA-OTDocs.ditamap 0000664 0000000 0000000 00000004476 11671002146 0017052 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/doc/DITA-OTProjectHome.xml 0000664 0000000 0000000 00000007522 11671002146 0017555 0 ustar 00root root 0000000 0000000
DITA Open Toolkit Project HomeThis document describes the DITA Open Toolkit project--what
the project is, and how to use the site.What is the DITA Open Toolkit?
The DITA
Open Toolkit, or DITA-OT for short, is a set of Java-based, open source
tools that provide processing for DITA maps and topic content. You
can download the OT and install it for free on your computer to get
started with topic-based writing and publishing. The DITA-OT is licensed
under the CPL
1.0 and Apache
2.0 open source licenses.
While the DITA Standard
itself is owned and developed by OASIS, the DITA Open Toolkit is an
independent, open source implementation of the standard
Key
output formats for the toolkit include:
XHTML
PDF (formerly known as PDF2)
ODT (Open Document Format)
Eclipse Help
HTML Help
Java Help
Eclipse Content (normalized DITA plus Eclipse project files)
Word RTF (with some limitations)
Docbook
Troff
Toolkit documentation
There are two primary
sources for documentation about the toolkit.
Stable documentation
about toolkit usage, parameters, and project management can be found
on this page, using the navigation panel on the left.
New information
about the latest toolkit builds, plans for the next release, and other
changing information can be found on the DITA-OT landing page at the
dita.xml.org site (link below). That site also contains the release
notes for all upcoming and previous releases.
Shortcuts to important information
Which package is for you? Find an explanation of the minimal,
standard, and "easy install" packages here: http://dita.xml.org/freelinking/DITA-OT Packages
Download the latest stable release: http://sourceforge.net/projects/dita-ot/files/DITA-OT
Stable Release/
Download the latest test build from the next release: http://sourceforge.net/projects/dita-ot/files/DITA-OT
Latest Test Build/
Description of parameters to the DITA Open Toolkit: see the Ant
Quick Start Guide in the navigation on the left.
Main DITA-OT page at dita.xml.orgInformation on the releaseExtending the toolkit with plug-ins
dita-ot-1.5.3/doc/admin/ 0000775 0000000 0000000 00000000000 11671002146 0014714 5 ustar 00root root 0000000 0000000 dita-ot-1.5.3/doc/admin/BugFixGuidelines-NoCLA.xml 0000664 0000000 0000000 00000004201 11671002146 0021522 0 ustar 00root root 0000000 0000000
Due Diligence for Submission of Bug Fixes and Patches from
Non-Committers
Before committing code from a bug fix or patch provided by a third party
who has not signed a current Common Public License to become a
Contributor to the project, the IBM committer should ask the following
questions and follow up as appropriate in order to ensure that the code
can be contributed to the project:
What is your name and who is your employer?
Did you write the code that you wish to contribute to the DITA Open
Toolkit project? (If the contributor says no, do not submit it as a
“Contribution†to the project. You may ask the contributor to identify
the complete details of the code’s source and of any licenses or
restrictions applicable to the code, but you should conspicuously mark
the work as “Submitted on behalf of a third-party: [name of
contributor]†when you submit it to the list.)
Do you have the right to grant the copyright and patent licenses for
the contribution that are set forth in the CPL version 1.0 license and
Apache License version 2.0?
Does your employer have any rights to code that you have written, for
example, through your contract for employment? If so, has your employer
given you permission to contribute the code on its behalf or waived its
rights in the code?
Are you aware of any third-party licenses or other restrictions (such
as related patents or trademarks) that could apply to your
contribution? If so, what are they?
The Contribution Questionnaire is the first step in initiating the due
diligence and approval process by the Project Manager (PM) for any
significant contribution of content to be committed to the project. Prior
to completing this Questionnaire, the Committer should have technical
agreement from the PM that the new code is required. Once the PM has
approved, the Committer, with the assistance of one or more of the
contributors, may begin the due diligence and approval process by
completing and submitting this questionnaire.
What is meant by a significant contribution?
Any initial code contribution used to kick off a new project. By
definition, this code has been written elsewhere and it needs to be
reviewed.
or
Any contribution authored by someone other than a committer which is
adding new functionality to the codebase. In most cases, bug fixes do not
add new functionality although it's not impossible.
or
Any contribution containing third-party code maintained by another open
source project, individual, group, or organization. In addition to
reviewing the contribution, if the license is not the Common Public
License (CPL) or Apache License 2.0, the PM will need to review and approve the third-party
license for compatibility with the CPL or Apache License 2.0.
How to send PM this form?
Please fill in this form and sign your name and get your employer's authorized signature, such as your manager's.
then fax to DITA open toolkit Project Manager Lian, Li. The fax number is +8621-53060504. If you have problem
sending international fax, please send a scanned copy to leelix@users.sourceforge.net
NOTE: A questionnaire and approval is not required for bug fixes or
minor enhancements. If you have any questions, please send an email to
the PM.
Your Info
Please provide your contact details:
Name:Organization:Address:Phone Number:E-mail:
Committer
Please provide contact details for the committer who will be
incorporating this contribution into the code base. If this is the same
as above, just put "same" in the Name field.
Name:Organization:Address:Phone Number:E-mail:
PM Approval
PM Approval is required for all significant contributions. Please
provide the contact info of the PM who has given approval for this
contribution:
Name:Phone Number:E-mail:
Contribution
Please provide details about the contribution:
Component/Module (if known): Contribution Name: Contribution Version: Contribution Size (in lines of code): Contribution Description: Does this contribution require any packages maintained by a
3rd party? Please list all pkgs required by the contribution which are
maintained by a 3rd party: (Please list one package per line e.g 3rd
party package name v1.0) Supporting Information: Do you agree to distribute the Contribution under Common Public License 1.0? Do you agree to distribute the Contribution under Apache License 2.0? Provide any additional information you may have regarding
intellectual property rights (patents, trademarks, etc.) related to
the Contribution. If there is more than one committer who worked on
this contribution, please list their name and email addresses.
Contributor
Note: All of the contributors should ensure that they possess the
necessary rights to make the contribution under the terms and conditions
set out in the Contribution
Policy.
Please provide contact details for the contributor or the primary
contributor if there is more than one:
Name: Organization: Phone Number: E-mail: % of content authored in the contribution:
If there are other contributors, please provide names, organizations,
e-mail, and percentage of content authored in the
contribution:Other
Contributors:
Cryptography
If the contribution deals in any way with cryptography, please provide
details:
Details:Identify the Cryptography algorithm used:
Contributor's signature
Name (Type or Print)TitleSignatureDate
Contributor employer's signature
Name (Type or Print)TitleSignatureDate dita-ot-1.5.3/doc/admin/ContributionPolicy.xml 0000664 0000000 0000000 00000016621 11671002146 0021303 0 ustar 00root root 0000000 0000000
DITA Open Toolkit Contribution PolicyThe purpose of the DITA Open Toolkit Contribution Policy is to set
forth the general principles under which the DITA Open Toolkit project
shall accept contributions, license contributions, license materials owned
by this project, and manage other intellectual property matters.Overview
Currently, IBM is the sole Committer for the DITA Open Toolkit
project. The Common Public License (CPL) and
Apache License 2.0, which are incorporated
herein by reference, will serve as the primary licenses under which the
Committer will accept contributions of software, documentation,
information (including, but not limited to, ideas, concepts, know-how
and techniques) and/or other materials (collectively
"Content") to the project from Contributors. A copy of the
CPL and Apache License 2.0 can be found at the root directory of the DITA Open Toolkit
deliverable package.
This Contribution Policy should at all times be interpreted in a
manner that is consistent with the Purposes of the this project as set
forth in the DITA Open Toolkit
Development Process goals and objectives. This Contribution
Policy shall serve as the basis for how non-Committers interact with
this project through participation in this project, web-sites owned,
controlled, published and/or managed under the auspices of the this
project, or otherwise.
The Common Public License and Apache License 2.0 shall serve as the primary licenses
under which the Committer(s) shall accept software, documentation,
information (including, but not limited to, ideas, concepts, know-how
and techniques) and/or other materials (collectively
"Content") from contributors including, but not limited to,
Contributors and Committers.
The DITA Open Toolkit project provides a process for accepting bug
fixes and contributions from parties who have not accepted the license
to be Contributors. See Due
Diligence for Submission of Bug Fixes and Patches from
Non-Committers
DUE DILIGENCE AND RECORD KEEPING
The Committer(s), shall be responsible for scrutinizing all Content
contributed to the DITA Open Toolkit project and help ensure that the
Contribution Policy licensing requirements set forth above are met.
Except as set forth below, the applicable Committer shall conduct the
following activities prior to uploading any Content into the repository
or otherwise making the Content available for distribution:
Contact the potential contributor of the Content through an
appropriate channel of communication and collect/confirm the
following:
Contributor's name, current address, phone
number and e-mail address;
Name and contact information of
the contributor's current employer, if any;
If the
contributor is not self-employed, the Committer must request and
receive a signed consent form (to be provided by the Committer) from
the contributor's employer confirming that the employer does not
object to the employee contributing the Content.
Determine
if the Content can be contributed under the terms of the CPL and
Apache License 2.0 or the
alternative terms and conditions supplied by the Contributor. This
can be done by asking the contributor questions such as;
Did
you develop all of the Content from scratch;
If not, what
materials did you use to develop the Content?
Did you
reference any confidential information of any third party?
If you referenced third party materials, under what terms did you
receive such materials?
If it is determined by
the Committer that the Content is not the original work of the
Contributor, collect the contact information of the copyright holder
of the original or underlying work. The copyright holder of the
Content or the underlying work may then need to be contacted to
collect additional information.
The was
"Committer(s)"Contributor(s) shall document
all information requested in (1) above and fill in Contribution
Questionnaire (to be provided by the Committer) and provide the
completed Contribution Questionnaire to the Committer.
The Committer shall also be responsible for running a scan tool to
help ensure that the Content does not include any code not identified
by the contributor.
Based on the information collected, the Committer shall use
his/her reasonable judgment to determine if the Content can be
contributed under terms and conditions that are consistent with the
licensing requirements of this IP Policy.
If the applicable Committer has any doubts about the ability to
distribute the Content under terms and conditions that are consistent
with the CPL and Apache License 2.0 or the proposed alternative terms and conditions, the
Committer may not upload the code to the repository or otherwise
distribute the Content. The Committer(s) shall be responsible for
filing/maintaining the information collected for future reference as
needed.
The above record keeping requirements shall not apply to
Minor modifications to Content previously contributed to and
accepted by the Committer(s).
Articles and White Papers
Information or minor Content modifications provided through bug
reports, mailing lists and news groups
While the record keeping requirements do not apply to the items listed
above, Committers must conduct reasonable due diligence to satisfy
themselves that proposed Contributions can be licensed under the terms
of the CPL and Apache License 2.0.
dita-ot-1.5.3/doc/admin/DITA-OTProjectGoals.xml 0000664 0000000 0000000 00000005177 11671002146 0021026 0 ustar 00root root 0000000 0000000
Goals and objectives of the DITA Open ToolkitThe long term goal of the DITA Open Toolkit is to provide
a high quality implementation for production level output of
DITA XML content, built in a professionally-managed project
environment by vetted contributors, and tested thoroughly for
each release.
The DITA-OT may be used in a variety of ways:
It may be integrated as one component in a larger end-to-end production
pipeline. Either the minimal or standard package may be the most suitable
for this use.
It may be used on its own as a complete DITA production system.
Users looking for this will most likely use the Full Easy Install
package.
It may be integrated into vendor tools such as editors or content
management systems, to provide an easy DITA production system. The
minimal package is designed for this type of use.
Project objectives
The project
will be managed similarly to any commercial software development
project, with requirements gathering, plan validation with
stakeholders, scheduled activities, tests, reviews, and builds,
with an emphasis on quality.
The project will
emplace a process for tracking all contributions. Any individual
or any organization can contribute, but the spirit of the
community is personal contribution. IBM as Committer is desirous
that all major contributors get appropriate recognition in
press releases, etc..
The DITA Open Toolkit
project will track and fix bugs reported against its products,
and issue patches based on urgency.
The DITA Open Toolkit
project will track to major version updates of the DTDs/Schemas
by the OASIS DITA TC.
The DITA Open Toolkit project will
track to bug fixes of the DTDs/Schemas by the OASIS DITA
TC as necessary (such fixes tend to have little impact to
tools).
The project agrees with the Open Source motto
of "Release early and often" to get wide consensus
on issues. The project works with an Agile development process, releasing
test builds approximately every three weeks, and encourages feedback
on test builds while function is being development.
dita-ot-1.5.3/doc/admin/DevelopmentProcess.xml 0000664 0000000 0000000 00000015276 11671002146 0021272 0 ustar 00root root 0000000 0000000
DITA Open Toolkit Development ProcessThe DITA Open Toolkit development process is modelled after other
popular and successful Open Source projects, notably the Eclipse
development process (for definitions and process statements).Revision 1.0
Last updated on February 27, 2005
Purpose and scope
This document describes the development process of DITA Open Toolkit
(DITA-OT) project.
Roles and Resposibilities
There are several roles in the DITA Open Toolkit open source project.
Each has different rights and obligations.
Project Manager (PM)
An individual responsible for managing this open source project.
The PM is expected to ensure that
All Projects operate
effectively by providing leadership to guide this project's
overall direction and by removing obstacles, solving problems, and
resolving conflicts.
All Project plans, technical
documents and reports are publicly available.
All Projects
operate using open source rules of engagement: meritocracy,
transparency, and open participation. These principles work
together. Anyone can participate in this project. This open
interaction, from answering questions to reporting bugs to making
code contributions to creating designs, enables everyone to
recognize and utilize the contributions.
It is
anticipated that the PM scope may be enlarged to head of a
leadership committee as the project grows.
Committer
A developer who is expected to influence the Project's
development and has the write access to the source code repository.
This position reflects a track record of high quality
contributions. At the initiation of this project, the PM nominates
one Committer who will oversee the quality and originality of all
contributions.
Contributor
An individual who contributes code, fixes, tests, documentation,
or other work that is part of this project. A Contributor does not
have write access to the source code repository.
Process life cycle
To ensure transparency and predictability, this project sequences
through a series of Phases, with well-defined Phase Transition Reviews:
Plan phase
Plan phase is mainly to determine what to implement in
each release. The Project Manager will collect requirements and
feature requests (enhancements) from all the members at large. Then
all the requirements will be prioritized. After discussion with the
Committer(s) and other developers, top requirements will be put into.
The schedule of this release and planned release dates will also
be determined. Exit criteria for this release will be set to ensure
high quality of all the releases.
Design phase
For all the requirements determined to be
implemented in the current release, developers will perform high
level design and create a prototype if necessary.
Implementation phase
Developers will implement the requirements
for this release and perform testing before formal release. The
Committer(s) will cooperate with contributors to ensure high quality
of the code before implementation phase ends.
Release
Source and binary code of this release will be put into
SourceForge and the next release planning phase begins.
ProceduresManage requirements/features
Throughout the project lifecycle, requirements or features will be
collected using the SourceForge requirements tracking tool. The PM
will have periodic reviews with the Committer(s), Contributors, and
interested parties to assess the existing requirements, prioritize
them and make decisions. Usually some requirements will be marked as
candidates for next release and will be reviewed in the planning
phase for next release (or in some cases for interim updates).
Fix bugs
Anyone can submit bug reports in SourceForge bug tracking system.
The Committer will determine the owner of the relevant components and
assign the bug for validation and disposition. Bugs have different
severities. Higher severity bugs will be responded to first, usually
worked to closure within one week.
Contribute code/bug fixes
Contributors can submit new code and bug fixes using the SourceForge
facilities. The Committer(s) who owns the relevant components will
first do due diligence to check code originality and licensing
according to the Contribution
Policy document. After due diligence, the Committer(s) will
use his/her own judgment on whether to accept the code or bug fixes
and merge them back to the original code base. Usually within a week
after submitting the contribution, contributors will receive a
response as to whether the contribution will be accepted or if more
time is needed to check the contribution.
Learn more about DITA in these developerWorks
articles:
Introduction to the Darwin Information Typing Architecture
Specializing topic types in DITA
Specializing domains in DITA
Frequently Asked Questions about the Darwin Information
Typing Architecture
Why use DITA to produce HTML deliverables?
Design patterns for information architecture with
DITA map domains
Migrating HTML to DITA, Part 1: Simple steps to move
from HTML to DITA
Migrating HTML to DITA, Part 2: Extend the migration
for more robust results
Transform Eclipse navigation files to DITA navigation
files
dita-ot-1.5.3/doc/articles/DITA-domains.xml 0000664 0000000 0000000 00000101703 11671002146 0020327 0 ustar 00root root 0000000 0000000
Specializing domains in DITAIn current approaches, DTDs are static. As a result, DTD designers try to cover every contingency and, when this effort fails, users have to force their information to fit existing types. DITA changes this situation by giving information architects and developers the power to extend a base DTD to cover their domains.Erik Hennum; IBM Corporation; ehennum@us.ibm.com. Erik Hennum works on the design and implementation of User Assistance for the IBM Storage Systems Group.
The Darwin Information Typing Architecture (DITA) is an XML architecture for extensible technical information. A domain extends DITA with a set of elements whose names and content models are unique to an organization or field of knowledge. Architects and authors can combine elements from any number of domains, leading to great flexibility and precision in capturing the semantics and structure of their information. In this overview, you learn how to define your own domains.
Introducing domain specialization
In DITA, the topic is the basic unit of processable content. The topic provides the title, metadata, and structure for the content. Some topic types provide very simple content structures. For example, the concept topic has a single concept body for all of the concept content. By contrast, a task topic articulates a structure that distinguishes pieces of the task content, such as the prerequisites, steps, and results.
In most cases, these topic structures contain content elements that are not specific to the topic type. For example, both the concept body and the task prerequisites permit common block elements such as p paragraphs and ul unordered lists.
Domain specialization lets you define new types of content elements independently of topic type. That is, you can derive new phrase or block elements from the existing phrase and block elements. You can use a specialized content element within any topic structure where its base element is allowed. For instance, because a p paragraph can appear within a concept body or task prerequisite, a specialized paragraph could appear there, too.
Here's an analogy from the kitchen. You might think of topics as types of containers for preparing food in different ways, such as a basic frying pan, blender, and baking dish. The content elements are like the ingredients that go into these containers, such as spices, flour, and eggs. The domain resembles a specialty grocer who provides ingredients for a particular cuisine. Your pot might contain chorizo from the carnicerÃa when you're cooking TexMex or risotto when you're cooking Italian. Similarly, your topics can contain elements from the programming domain when you're writing about a programming language or elements from the UI domain when you're writing about a GUI application.
DITA has broad tastes, so you can mix domains as needed. If you're describing how to program GUI applications, your topics can draw on elements from both the programming and UI domains. You can also create new domains for your content. For instance, a new domain could provide elements for describing hardware devices. You can also reuse new domains created by others, expanding the variety of what you can cook up.
In a more formal definition, topic specialization starts with the containing element and works from the top down. Domain specialization, on the other hand, starts with the contained element and works from the bottom up.
Understanding the base domains
A DITA domain collects a set of specialized content elements for some purpose. In effect, a domain provides a specialized vocabulary. With the base DITA package, you receive the following domains:
DomainPurposehighlightTo highlight text with styles such as bold, italic, and monospaceprogrammingTo define the syntax and give examples of programming languagessoftwareTo describe the operation of a software programUITo describe the user interface of a software program
In most domains, a specialized element adds semantics to the base element. For example, the apiname element of the programming domain extends the basic keyword element with the semantic of a name within an API.
The highlight domain is a special case. The elements in this domain provide styled presentation instead of semantic or structural markup. The highlight styles give authors a practical way to mark up phrases for which a semantic has not been defined.
Providing such highlight styles through a domain resolves a long-standing dispute for publication DTDs. Purists can omit the highlight domain to enforce documents that should be strictly semantic. Pragmatists can include the highlight domain to provide expressive flexibility for real-world authoring. A semipragmatist could even include the highlight domain in conceptual documents to support expressive authoring but omit the highlight domain from reference documents to enforce strict semantic tagging.
More generally, you can define documents with any combination of domains and topics. As we'll see in , the resulting documents can still be exchanged.
Combining an existing topic and domain
The DITA package provides a DTD for each topic type and an omnibus DTD (ditabase.dtd) that defines all of the topic types. Each of these DTDs includes all of the predefined DITA domains. Thus, topics written against one of the supplied DTDs can use all of the predefined domain specializations.
Behind the scenes, a DITA DTD is just a shell. Elements are actually defined in other modules, which are included in the DTD. Through these modules, DITA provides you with the building blocks to create new combinations of topic types and domains.
When you add a domain to your DITA installation, the new domain provides you with additional modules. You can use the additional modules to incorporate the domain into the existing DTDs or to create new DTDs.
In particular, each domain is implemented with two files:
A file that declares the entities for the domain. This file has the .ent extension.
A file that declares the elements for the domain. This file has the .mod extension.
As an example, let's say we're authoring the reference topics for a programming language. We're purists about presentation, so we want to exclude the highlight domain. We also have no need for the software or UI domains in this reference. We could address this scenario by defining a new shell DTD that combines the reference topic with the programming domain, excluding the other domains.
A shell DTD has a consistent design pattern with a few well-defined sections. The instructions in these sections perform the following actions:
Declare the entities for the domains.
In the scenario, this section would include the programming domain entities:
<!ENTITY % pr-d-dec PUBLIC "-//IBM//ENTITIES DITA Programming Domain//EN" "programming-domain.ent">
%pr-d-dec;
Redefine the entities for the base content elements to add the specialized content elements from the domains.
This section is crucial for domain specialization. Here, the design pattern makes use of two kinds of entities. Each base content element has an element entity to identify itself and its specializations. Each domain provides a separate domain specialization entity to list the specializations that it provides for a base element. By combining the two kinds of entities, the shell DTD allows the specialized content elements to be used in the same contexts as the base element.
In the scenario, the pre element entity identifies the pre element (which, as in HTML, contains preformatted text) and its specializations. The programming domain provides the pr-d-pre domain specialization entity to list the specializations for the pre base element. The same pattern is used for the other base elements specialized by the programming domain:
To learn which content elements are specialized by a domain, you can look at the entity declaration file for the domain.
Define the domains attribute of the topic elements to declare the domains represented in the document.
Like the class attribute, the domains attribute identifies dependencies. Where the class attribute identifies base elements, the domains attribute identifies the domains available within a topic. Each domain provides a domain identification entity to identify itself in the domains attribute.
In the scenario, the only topic is the reference topic. The only domain is the programming domain, which is identified by the pr-d-att domain identification entity:
<!ATTLIST reference domains CDATA "&pr-d-att;">
Redefine the infotypes entity to specify the topic types that can be nested within a topic.
In the scenario, this section would declare the reference topic:
<!ENTITY % info-types "reference">
Define the elements for the topic type, including the base topics.
In the scenario, this section would include the base topic and reference topic modules:
<!ENTITY % topic-type PUBLIC "-//IBM//ELEMENTS DITA Topic//EN" "topic.mod">
%topic-type;
<!ENTITY % reference-typemod PUBLIC "-//IBM//ELEMENTS DITA Reference//EN" "reference.mod">
%reference-typemod;
Define the elements for the domains.
In the scenario, this section would include the programming domain definition module:
<!ENTITY % pr-d-def PUBLIC "-//IBM//ELEMENTS DITA Programming Domain//EN" "programming-domain.mod">
%pr-d-def;
Often, it would be easiest to work by copying an existing DTD and adding or removing topics or domains. In the scenario, it would be easiest to start with reference.dtd and remove the highlight, software, and UI domains as shown with the underlined text below.
<!--vocabulary declarations-->
<!ENTITY % ui-d-dec PUBLIC "-//IBM//ENTITIES DITA User Interface Domain//EN" "ui-domain.ent">
%ui-d-dec;
<!ENTITY % hi-d-dec PUBLIC "-//IBM//ENTITIES DITA Highlight Domain//EN" "highlight-domain.ent">
%hi-d-dec;
<!ENTITY % pr-d-dec PUBLIC "-//IBM//ENTITIES DITA Programming Domain//EN" "programming-domain.ent">
%pr-d-dec;
<!ENTITY % sw-d-dec PUBLIC "-//IBM//ENTITIES DITA Software Domain//EN" "software-domain.ent">
%sw-d-dec;
<!--vocabulary substitution-->
<!ENTITY % pre "pre | %pr-d-pre; | %sw-d-pre;">
<!ENTITY % keyword "keyword | %pr-d-keyword; | %sw-d-keyword; | %ui-d-keyword;">
<!ENTITY % ph "ph | %pr-d-ph; | %sw-d-ph; | %hi-d-ph; | %ui-d-ph;">
<!ENTITY % fig "fig | %pr-d-fig;">
<!ENTITY % dl "dl | %pr-d-dl;">
<!--vocabulary attributes-->
<!ATTLIST reference domains CDATA "&ui-d-att; &hi-d-att; &pr-d-att; &sw-d-att;">
<!--Redefine the infotype entity to exclude other topic types-->
<!ENTITY % info-types "reference">
<!--Embed topic to get generic elements -->
<!ENTITY % topic-type PUBLIC "-//IBM//ELEMENTS DITA Topic//EN" "topic.mod">
%topic-type;
<!--Embed reference to get specific elements -->
<!ENTITY % reference-typemod PUBLIC "-//IBM//ELEMENTS DITA Reference//EN" "reference.mod">
%reference-typemod;
<!--vocabulary definitions-->
<!ENTITY % ui-d-def PUBLIC "-//IBM//ELEMENTS DITA User Interface Domain//EN" "ui-domain.mod">
%ui-d-def;
<!ENTITY % hi-d-def PUBLIC "-//IBM//ELEMENTS DITA Highlight Domain//EN" "highlight-domain.mod">
%hi-d-def;
<!ENTITY % pr-d-def PUBLIC "-//IBM//ELEMENTS DITA Programming Domain//EN" "programming-domain.mod">
%pr-d-def;
<!ENTITY % sw-d-def PUBLIC "-//IBM//ELEMENTS DITA Software Domain//EN" "software-domain.mod">
%sw-d-def;Creating a domain specialization
For some documents, you may need new types of content elements. In a common scenario, you need to mark up phrases that have special semantics. You can handle such requirements by creating new specializations of existing content elements and providing a domain to reuse the new content elements within topic structures.
As an example, let's say we're writing the documentation for a class library. We intend to write processes that will index the documentation by class, field, and method. To support this processing, we need to mark up the names of classes, fields, and methods within the topic content, as in the following sample:
<p>The <classname>String</classname> class provides
the <fieldname>length</fieldname> field and
the <methodname>concatenate()</methodname> method.
</p>
We must define new content elements for these names. Because the names are special types of names within an API, we can specialize the new elements from the apiname element provided by the programming domain.
The design pattern for a domain requires an abbreviation to represent the domain. A sensible abbreviation for the class library domain might be cl. The identifier for a domain consists of the abbreviation followed by -d (for domain).
As noted in , the domain requires an entity declaration file and an element definition file.
Writing the entity declaration file
The entity declaration file has sections that perform the following actions:
Define the domain specialization entities.
A domain specialization entity lists the specialized elements provided by the domain for a base element. For clarity, the entity name is composed of the domain identifier and the base element name. The domain provides domain specialization entities for ancestor elements as well as base elements.
In the scenario, the domain defines a domain specialization entity for the apiname base element as well as the keyword ancestor element (which is the base element for apiname):
The domain identification entity lists the topic type as well as the domain and other domains for which the current domain has dependencies. Each domain is identified by its domain identifier. The list is enclosed in parentheses. For clarity, the entity name is composed of the domain identifier and -att.
In the scenario, the class library domain has a dependency on the programming domain, which provides the apiname element:
<!ENTITY cl-d-att "(topic pr-d cl-d)">
The complete entity declaration file would look as follows:
The element definition file has sections that perform the following actions:
Define the content element entities for the elements introduced by the domain.
These entities permit other domains to specialize from the elements of the current domain.
In the scenario, the class library domain follows this practice so that additional domains can be added in the future. The domain defines entities for the three new elements:
The specialized content model must be consistent with the content model for the base element. That is, any possible contents of the specialized element must be generalizable to valid contents for the base element. Within that limitation, considerable variation is possible. Specialized elements can be substituted for elements in the base content model. Optional elements can be omitted or required. An element with multiple occurrences can be replaced with a list of specializations of that element, and so on.
The specialized content model should always identify elements through the element entity rather than directly by name. This practice lets other domains merge their specializations into the current domain.
In the scenario, the elements have simple character content:
Define the specialization hierarchy for the element with class attribute.
For a domain element, the value of the attribute must start with a plus sign. Elements provided by domains should be qualified by the domain identifier.
In the scenario, specialization hierarchies include the keyword ancestor element provided by the base topic and the apiname element provided by the programming domain:
<!ATTLIST classname class CDATA "+ topic/keyword pr-d/apiname cl-d/classname ">
<!ATTLIST fieldname class CDATA "+ topic/keyword pr-d/apiname cl-d/fieldname ">
<!ATTLIST methodname class CDATA "+ topic/keyword pr-d/apiname cl-d/methodname ">
The complete element definition file would look as follows:
After creating the domain files, you can write shell DTDs to combine the domain with topics and other domains. The shell DTD must include all domain dependencies.
In the scenario, the shell DTD combines the class library domain with the concept, reference, and task topics and the programming domain. The portions specific to the class library domain are highlighted below in bold:
<!--vocabulary declarations-->
<!ENTITY % pr-d-dec PUBLIC "-//IBM//ENTITIES DITA Programming Domain//EN" "programming-domain.ent">
%pr-d-dec;
<!ENTITY % cl-d-dec SYSTEM "classlib-domain.ent"> %cl-d-dec;
<!--vocabulary substitution-->
<!ENTITY % pre "pre | %pr-d-pre;">
<!ENTITY % keyword "keyword | %pr-d-keyword; | %cl-d-apiname;">
<!ENTITY % ph "ph | %pr-d-ph;">
<!ENTITY % fig "fig | %pr-d-fig;">
<!ENTITY % dl "dl | %pr-d-dl;">
<!ENTITY % apiname "apiname | %cl-d-apiname;">
<!--vocabulary attributes-->
<!ATTLIST concept domains CDATA "&pr-d-att; &cl-d-att;">
<!ATTLIST reference domains CDATA "&pr-d-att; &cl-d-att;">
<!ATTLIST task domains CDATA "&pr-d-att; &cl-d-att;">
<!--Redefine the infotype entity to exclude other topic types-->
<!ENTITY % info-types "concept | reference | task">
<!--Embed topic to get generic elements -->
<!ENTITY % topic-type PUBLIC "-//IBM//ELEMENTS DITA Topic//EN" "topic.mod">
%topic-type;
<!--Embed topic types to get specific topic structures-->
<!ENTITY % concept-typemod PUBLIC "-//IBM//ELEMENTS DITA Concept//EN" "concept.mod">
%concept-typemod;
<!ENTITY % reference-typemod PUBLIC "-//IBM//ELEMENTS DITA Reference//EN" "reference.mod">
%reference-typemod;
<!ENTITY % task-typemod PUBLIC "-//IBM//ELEMENTS DITA Task//EN" "task.mod">
%task-typemod;
<!--vocabulary definitions-->
<!ENTITY % pr-d-def PUBLIC "-//IBM//ELEMENTS DITA Programming Domain//EN" "programming-domain.mod">
%pr-d-def;
<!ENTITY % cl-d-def SYSTEM "classlib-domain.mod"> %cl-d-def;
Notice that the class library phrases are added to the element entity for keyword as well as for apiname. This addition makes the class library phrases available within topic structures that allow keywords and not just in topic structures that explicitly allow API names. In fact, the structures of the reference topic specify only keywords, but it's good practice to add the domain specialization entities to all ancestor elements.
Considerations for domain specialization
When you define new types of topics or domain elements, remember that the hierarchies for topic specialization and domain specialization must be distinct. A specialized topic cannot use a domain element in a content model. Similarly, a domain element can specialize only from an element in the base topic or in another domain. That is, a topic and domain cannot have dependencies. To combine topics and domains, use a shell DTD.
When specializing elements with internal structure including the ul, ol, and dl lists as well as table and simpletable, you should specialize the entire content element. Creating special types of pieces of the internal structure independently of the whole content structure usually doesn't make much sense. For example, you usually want to create a special type of list instead of a special type of li list item for ordinary ul and ol lists.
You should never specialize from the elements of the highlight domain. These style elements do not have a specific semantic. Although the formatting of the highlight styles might seem convenient, you might find you need to change the formatting later.
As noted previously, you should use element entities instead of literal element names in content models. The element entities are necessary to permit domain specialization.
The content model should allow for the possibility that the element entity might expand to a list. When applying a modifier to the element entity, you should enclose the element entity in parentheses. Otherwise, the modifier will apply only to the last element if the entity expands to a list. Similar issues affect an element entity in a sequence:
The parentheses aren't needed if the element entity is already in a list.
Generalizing a domain
As with topics, a specialized content element can be generalized to one of its ancestor elements. In the previous scenario, a classname can generalize to apiname or even keyword. As a result, documents using different domains but the same topics can be exchanged or merged without having to generalize the topics.
To return to the highlight style controversy mentioned in , a pragmatic document authored with highlight domain will contain phrases like the following:
... the <b>important</b> point is ...
When the document is generalized to the same topic but without the highlight domain, the pragmatic b element becomes a purist ph element, indicating that the phrase is special without introducing presentation:
... the <ph class="+ topic/ph hi-d/b ">important</ph> point is ...
In the previous scenario, the class library authors could send their topics to another DITA shop without the class library domain. The recipients would generalize the class library topics, converting the classname elements to apiname base elements. After generalization, the recipients could edit and process the class, field, and method names in the same way as any other API names. That is, the situation would be the same as if the senders had decided not to distinguish class, field, and method names and, instead, had marked up these names as generic API names.
As an alternative, the recipients could decide to add the class library domain to their definitions. In this approach, the senders would provide not only their topics but also the entity declaration and element definition files for the domain. The recipients would add the class library domain to their shell DTD. The recipients could then work with classname elements without having to generalize.
The recipients can use additional domains with no impact on interoperability. That is, the shell DTD for the recipients could use more domains than the shell DTD for the senders without creating any need to modify the topics.
When defining specializations, you should avoid introducing a dependency on special processing that lacks a graceful fallback to the processing for the base element. In the scenario, special processing for the classname element might generate a literal class label in the output to save some typing and produce consistent labels. After automated generalization, however, the label would not be supplied by the base processing for the apiname element. Thus, the dependency would require a special generalization transform to append the literal class label to classname elements in the source file.Summary
Through topic specialization and domains, DITA provides the following benefits:
Simpler topic design.
The document designer can focus on the structure of the topic without having to foresee every variety of content used within the structure.
Simpler topic hierarchies.
The document designer can add new types of content without having to add new types of topics.
Extensible content for existing topics.
The document designer can reuse existing types of topics with new types of content.
Semantic precision.
Content elements with more specific semantics can be derived from existing elements and used freely within documents.
Simpler element lists for authors.
The document designer can select domains to minimize the element set. Authors can learn the elements that are appropriate for the document instead of learning to disregard unneeded elements.
In short, the DITA domain feature provides for great flexibility in extending and reusing information types. The highlight, programming, and UI domains provided with the base DITA release are only the beginning of what can be accomplished.
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.
dita-ot-1.5.3/doc/articles/DITA-dsf.xml 0000664 0000000 0000000 00000144662 11671002146 0017464 0 ustar 00root root 0000000 0000000
Specializing topic types in DITAThe Darwin Information Typing Architecture (DITA) provides a way for documentation authors and architects to create collections of typed topics that can be easily assembled into various delivery contexts. Topic specialization is the process by which authors and architects can define topic types, while maintaining compatibility with existing style sheets, transforms, and processes. The new topic types are defined as an extension, or delta, relative to an existing topic type, thereby reducing the work necessary to define and maintain the new type.Michael Priestley; IBM Corporation; Toronto, Canada; mpriestl@ca.ibm.com; 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.GeneralDITAXMLtopicinformation architecturearchitectural formsspecializationinformation typedocument typeDTDdocument metadatadocumentationtechnical writinguser assistancehelps
The point of the XML-based Darwin Information Typing Architecture (DITA) is to create modular technical documents that are easy to reuse with varied display and delivery mechanisms, such as helpsets, manuals, hierarchical summaries for small-screen devices, and so on. This article explains how to put the DITA principles into practice with regards to the creation of a DTD and transforms that will support your particular information types, rather than just using the base DITA set of concept, task, and reference.
Topic specialization is the process by which authors and architects define new topic types, while maintaining compatibility with existing style sheets, transforms, and processes. The new topic types are defined as an extension, or delta, relative to an existing topic type, thereby reducing the work necessary to define and maintain the new type.
The examples used in this paper use XML DTD syntax and XSLT; if you need background on these subjects, see Resources.
Architectural context
In SGML, architectural forms are a classic way to provide mappings from one document type to another. Specialization is an architectural-forms-like solution to a more constrained problem: providing mappings from a more specific topic type to a more general topic type. Because the specific topic type is developed with the general topic type in mind, specialization can ignore many of the thornier problems that architectural forms address. This constrained domain makes specialization processes relatively easy to implement and maintain. Specialization also provides support for multi-level or hierarchical specializations, which allow more general topic types to serve as the common denominator for different specialized types.
The specialization process was created to work with DITA, although its principles and processes apply to other domains as well. This will make more sense if you consider an example: Given specialization and a generic DTD such as HTML, you can create a new document type (call it MyHTML). In MyHTML you could enforce site standards for your company, including specific rules about forms layout, heading levels, and use of font and blink tags. In addition, you could provide more specific structures for product and ordering information, to enable search engines and other applications to use the data more effectively.
Specialization lets MyHTML be defined as an extension of the HTML DTD, declaring new element types only as necessary and referencing HTML's DTD for shared elements. Wherever MyHTML declares a new element, it includes a mapping back to an existing HTML element. This mapping allows the creation of style sheets and transforms for HTML that operate equally well on MyHTML documents. When you want to handle a structure differently (for example, to format product information in a particular way), you can define a new style sheet or transform that holds the extending behavior, and then import the standard style sheet or transform to handle the rest. In other words, new behavior is added as extensions to the original style sheet, in the same way that new constraints were added as extensions to the original DTD or schema.
Specializing information types
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 of the separation of information types 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.
Specialization example: Reference topic
Consider the specialization hierarchy for a reference topic:
Table 1 expresses the relationship between the general elements in topic and the specific elements in reference. Within the table, the columns, rows, and cells indicate information types, element mappings, and elements. Table 2 explains the relationships in detail to help you interpret Table 1.
Relationships between topic and a specialization based on it Topic Reference(topic.mod) (reference.mod) topic reference title body refbody simpletableproperties section refsyn
StructureAssociations
Columns
The Topic column shows basic topic structure, which comprises a title and body with optional sections, as declared in a DTD module called topic.mod . The Reference column shows a more specialized structure, with reference replacing topic, refbody replacing body, and refsyn replacing section; these new elements are declared in a DTD module called reference.mod .
Rows
Each row represents a mapping between the elements in that row. The elements in the Reference column specialize the elements in the Topic column. Each general element also serves as a category for more specialized elements in the same row. For example, reference's refsyn is a kind of section.
Cells
Each cell in a column represents the following possibilities in relation to the cell to its left:
A blank cell: The element in the cell to the left is reused as-is. For example, a referencetitle is the same as a topictitle, and topic's declaration of the title element can be used by reference.
A full cell: An element that is specific to the current type replaces the more general element to the left. For example, in reference , refbody replaces the more general body.
A split row with a blank cell: The new specializations are in addition to the more general element, which remains available in the specialized type. For example, reference adds properties as a special type of simpletable ( dl), but the general kind of simpletable remains available in reference.
The reference type module
Listing 1 illustrates not the actual reference.mod content, but a simplified version based on Table 1. The use of entities in the content models support domain specialization, as described in the domain specialization article.
Most of the content models declared here depend on elements or entities declared in topic.mod. Therefore, if topic's structure is enhanced or changed, most of the changes will be picked up by reference automatically. Also the definition of reference remains simple: it doesn't have to redeclare any of the content that it shares with topic.
Adding specialization attributes
To expose the element mappings, we add an attribute to each element that shows its mappings to more general types.
<!ATTLIST reference class CDATA "- topic/topic reference/reference ">
<!ATTLIST refbody class CDATA "- topic/body reference/refbody ">
<!ATTLIST properties class CDATA "- topic/simpletable reference/properties ">
<!ATTLIST refsyn class CDATA "- topic/section reference/refsyn ">
Later on, we'll talk about how to take advantage of these attributes when you write an XSL transform. See the appendix for a more in-depth description of the class attribute.
Creating an authoring DTD
Now that we've defined the type module (which declares the newly typed elements and their attributes) and added specialization attributes (which map the new type to its ancestors), we can assemble an authoring DTD.
<!--Redefine the infotype entity to exclude other topic types-->
<!ENTITY % info-types "reftopic">
<!--Embed topic to get generic elements -->
<!ENTITY % topic-type SYSTEM "topic.mod">
%topic-type;
<!--Embed reference to get specific elements -->
<!ENTITY % reference-type SYSTEM "reference.mod">
%reference-type;
Specialization example: API description
Now let's create a more specialized information type: API descriptions, which are a kind of (and therefore specialization of) reference topic:
A more specialized information type, API description
Table 3 shows part of the specialization for an information type called APIdesc, for API description. As before, each column represents an information type, with specialization occurring from left to right. That is, each information type is a specialization of its neighbor to the left. Each row represents a set of mapped elements, with more specific elements to the right mapping to more general equivalents to the left.
As before, each cell specializes the contents of the cell to its left:
A blank cell: The element to the left is picked up by the new type unchanged. For example, simpletable and refsyn are available in an API description.
A full cell: The element to the left is replaced by a more specific one. For example, APIname replaces title.
A split row with a blank cell: New elements are added to the elements on the left. For example, the API description adds a usage section as a peer of the refsyn and section elements.
Summary of APIdesc specialization Topic Reference APIdesc (topic.mod) (reference.mod) (APIdesc.mod) topic reference APIdesc title APIname body refbody APIbody simpletablepropertiesparameters section refsynusage
The APIdesc module
Here you can see that the content for an API description is actually much more restricted than the content of a general reference topic. The sequence of syntax, then usage, then parameters is now imposed, followed by optional additional sections. This sequence is a subset of the allowable structures in a reference topic, which allows any sequence of syntax, properties, and sections. In addition, the label for the usage section is now fixed as Usage, taking advantage of the spectitle attribute of section (which is there for exactly this kind of usage): with the spectitle attribute providing the section title, we can also get rid of the title element in usage's content model, making use of the predefined section.notitle.cnt entity.
Note that APIname explicitly identifies its equivalent in both reference and topic, even though they are the same (title) in both cases. In the same way, usage explicitly maps to section in both reference and topic. This explicit identification makes it easier for processes to keep track of complex mappings. Even if you had a specialization hierarchy 10 levels deep or more, the attributes would still allow unambiguous mappings to each ancestor information type.
Authoring DTDs
Now that we've defined the type module (which declares the newly typed elements and their attributes) and added specialization attributes (which map the new type to its ancestors), we can assemble an authoring DTD.
<!--Redefine the infotype entity to exclude other topic types-->
<!ENTITY % info-types "APIdesc">
<!--Embed topic to get generic elements -->
<!ENTITY % topic-type SYSTEM "topic.mod">
%topic-type;
<!--Embed reference to get more specific elements -->
<!ENTITY % reference-type SYSTEM "reference.mod">
%reftopic-type;
<!--Embed APIdesc to get most specific elements -->
<!ENTITY % APIdesc-type SYSTEM "APIdesc.mod">
%APIdesc-type;
Working with specialization
After a specialized type has been defined the necessary attributes have been declared, they can provide the basis for the following operations:
Applying a general style sheet or transform to a specialized topic type
Generalizing a topic of a specialized type (transforming it into a more generic topic type)
Specializing a topic of a general type (transforming it into a more specific topic type - to be used only when a topic was originally authored in specialized form, and has gone through a general stage without breaking the constraints of its original form)
Applying general style sheets or transforms
Because content written in a new information type (such as APIdesc) has mappings to equivalent or less restrictive structures in preexisting information types (such as reference and topic), the preexisting transforms and processes can be safely applied to the new content. By default, each specialized element in the new information type will be treated as an instance of its general equivalent. For example, in APIdesc the <usage> element will be treated as a topic <section> element that happens to have the fixed label "Usage".
To override this default behavior, an author can simply create a new, more specific rule for that element type, and then import the default style sheet or transform, thus extending the behavior without directly editing the original style sheet or transform. This reuse by reference reduces maintenance costs (each site maintains only the rules it uniquely requires) and increases consistency (because the core transform rules can be centrally maintained, and changes to the core rules will be reflected in all other tranforms that import them). Control over reuse has moved from the author of the transform to the reuser of the transform.
The rest of this section assumes knowledge of XSLT, the XSL Transformations language.
Requirements
This process works only if the general transforms have been enabled to handle specialized elements, and if the specialized elements include enough information for the general transform to handle them.
Requirement 1: mapping attributes
To provide the specialization information, you need to add specialization attributes, as outlined previously. After you include the attributes in your documents, they are ready to be processed by specialization-aware transforms.
Requirement 2: specialization-aware transforms
For the transform, you need template rules that check for a match against both the element name and the attribute value.
<xsl:template match="*[contains(@class," topic/simpletable "]">
<!--matches any element that has a class attribute that mentions
topic/simpletable-->
<!--do something-->
</xsl:template>
Example: overriding a transform
To override the general transform for a specific element, the author of a new information type can create a transform that declares the new behavior for the specific element and imports the general transform to provide default behavior for the other elements.
For example, an APIdesc specialized transform could allow default handling for all specialized elements except parameters:
Both the preexisting referenceproperties template rule and the new parameters template rule match when they encounter a parameters element (because the parameters element is a specialized type of referenceproperties element), and its class attribute contains both values). However, because the parameters template is in the importing style sheet, the new template takes precedence.
Generalizing a topic
Because a specialized information type is also an instance of its ancestor types (an APIdesc is a reference topic is a topic), you can safely transform a specialized topic to one of its more generic ancestors. This upward compatibility is useful when you want to combine sets of documentation from two sources, each of which has specialized differently. The ancestor type provides a common denominator that both can be safely transformed to. This compatibility may also be useful when you have to feed topics through processes that are not specialization-aware. For example, a publication center that charges per document type or uses non-DTD-aware processes could be sent a generalized set of documents, so that they only support one document type or set of markup. However, wherever possible, you should use specialization-aware processes and transforms, so that you can avoid generalizing and process your documents in their more descriptive, specialized form.
To safely generalize a topic, you need a way to map from your information type to the target information type. You also need a way to preserve the original type in case you need round-tripping later.
The class attribute that was introduced previously serves two purposes. It provices:
The information needed to map.
A way to preserve the information to allow round-tripping.
Each level of specialization has its own set of class attributes, which in the end provide the full specialization hierarchy for all specialized elements.
Consider the APIdesc topic in Listing 11:
<APIdesc>
<APIname>AnAPI</APIname>
<APIbody>
<refsyn>AnAPI (parm1, parm2)</refsyn>
<usage spectitle="Usage">Use AnAPI to pass parameters to your process.
</usage>
<parameters >
...
</parameters>
</APIbody>
</APIdesc>
With the class attributes exposed (all values are provided as defaults by the DTD):
From here, a single template rule can transform the entire APIdesc topic to either a reference or a generic topic. The template rule simply looks in the class attribute for the ancestor element name, and renames the current element to match.
After a transform to topic, it should look something like Listing 13:
Even after generalization, specialization-aware transforms can continue to treat the topic as an APIdesc, because the transforms can look in the class attribute for information about the element type hierarchy.
From here, it is possible to round-trip by reversing the transformation (looking in the class attribute for the specializing element name, and renaming the current element to match). Whenever the class attribute doesn't list the target (the first section has no APIdesc value), the element is changed to the last value listed (so the first section becomes, accurately, a refsyn).
However, if anyone changes the structure of the content while it is a generic topic (as by changing the order of sections), the result might not be valid anymore under the specialized information type (which in theAPIdesc case enforces a particular sequence of information in the APIbody). So although mapping to a more general type is always safe, mapping back to a specialized type can be problematic: The specialized type has more rules, which make the content specialized. But those rules aren't enforced while the content is encoded more generally.
Specializing a topic
It is relatively trivial to specialize a general topic if the content was originally authored as a specialized type. However, a more complex case can result if you have authored content at a general level that you now want to type more precisely.
For example, suppose that you create a set of reference topics. Then, having analyzed your content, you realize that you have a consistent pattern. Now you want to enforce this pattern and describe it with a specialized information type (for example, API descriptions). In order to specialize, you need to first create the target DTD and then add enough information to your content to allow it to be migrated.
You can put the specializing information in either of two places:
Add it to the class attribute. You need to be careful to get the order correct, and include all ancestor type values.
Or give the name of the target element in an outputclass attribute, migrate based on that value, and add the class attribute values afterward.
In either case, before migration you can run a validation transform that looks for the appropriate attribute, then checks that the content of the element will be valid under the specialized content model. You can use a tool like Schematron to generate both the validating transform and the migrating transform, or you can migrate first and use the specialized DTD to validate that the migration was successful.
Specializing with schemas
Like the XML DTD syntax, the XML Schema language is a way of defining a vocabulary (elements and attributes) and a set of constraints on that vocabulary (such as content models, or fixed vs. implied attributes). It has a built-in specialization mechanism, which includes the capability to restrict allowable specializations. Using the XML Schema language instead of DTDs would make it much easier to validate that specialized information types represent valid subsets of generic types, which ensures smooth processing by generic translation and publishing transforms.
Unlike DTDs, XML schemas are expressed as XML documents. As a result, they can be processed in ways that DTDs cannot. For example, we can maintain a single XML schema and then use XSL to generate two versions:
An authoring version of it that eliminates any fixed attributes and any overridden elements
A processor-ready version of it that includes the class attributes that drive the translation and publishing transforms
However, XML schemas are not yet popular enough to adopt wholeheartedly. The main problems are a lack of authoring tools, and incompatibilities between the implementations of an evolving standard. These problems should be remedied by the industry over the next year or so, as the standard is finalized and schemas become more widely adopted and supported.
Summary
You can create a specialized information type by using this general procedure:
Identify the elements that you need.
Identify the mapping to elements of a more general type.
Verify that the content models of specialized elements are more restrictive than their general equivalents.
Create a type module file that holds your specialized element and attribute declarations (including the class attribute).
Create an authoring DTD file that imports the appropriate type modules.
You can create specialized XSL transforms by using this general procedure:
Create a new transform for your information type.
Import the existing transform that you want to extend.
Identify the elements that you need to treat specially.
Add template rules that match those elements, based on their class attribute content.
Appendix: Rules for specialization
Although you could create a new element equivalent for any tag in a general DTD, this work is useless to you as an author unless the content models that would include the tag are also specialized. In the APIdesc example, the parameters element is not valid content anywhere in topic or reference. For it to be used, you need to create valid contexts for parameters, all the way up to the topic-level container. To expose the parameters element to your authors, you need to specialize the following parts:
A body element, to allow parameters as valid content (giving us APIbody)
A topic element, to allow the specialized body (giving us APIdesc)
This domino effect can be avoided by using domain specialization. If you truly just want to add some new variant structures to an existing information type, use domain specialization instead of topic specialization (see Specializing domains in DITA).
To ensure that the specialized elements are more constrained than their general equivalents (that is, that they allow a proper subset of the structures that the general equivalent allows), you need to look at the content model of the general element. You can safely change the content model of your specialized element as shown in Table A:
Summary of specialization rules Content typeAllowed specializationExample (Special specializing General)RequiredRename only
<!ELEMENT General(a)>
<!ELEMENT Special(a.1)>
Optional (?)Rename, make required, or delete
<!ELEMENT General(a?)>
<!ELEMENT Special(a.1?)>
<!ELEMENT Special(a.1)>
<!ELEMENT Special EMPTY>
One or more (+)Rename, make required, split into a required element plus others, split into one or more elements plus others.
Zero or more (*)Rename, make required, make optional, split into a required element plus others, split into an optional element plus others, split into one-or-more plus others, split into zero-or-more plus others, or delete
<!ELEMENT Special (a.1|b.1)>
<!ELEMENT Special (a.1)>
Extended example
You have a general element General, with the content model (a,b?,(c|d+)). This definition means that a General always contains element a, optionally followed by element b, and always ends with either c or one or more d's.
<!ELEMENT General (a,b?,(c|d+))>
When you specialize General to create Special, its content model must be the same or more restrictive: It cannot allow more things than General did, or you will not be able to map upward, or guarantee the correct behavior of general processes, transforms, or style sheets.
Leaving aside renaming (which is always allowed, and simply means that you are also specializing some of the elements that Special can contain), here are some valid changes that you could make to the content model of Special, resulting in the same or more restrictive content rules:
<!ELEMENT Special (a,b,(c|d))>
Special now requires b to be present, instead of optional, and allows only one d. It safely maps to General.
<!ELEMENT Special (a,b?,c)>
Special now requires c to be present, and no longer allows d. It safely maps to General.
<!ELEMENT Special (a,b?,d1,d2,d3)>
Special now requires three specializations of d to be present, and does not allow c. It safely maps to General.
Details of the class attribute
Every element must have a class attribute. The class attribute starts and ends with white space, and contains a list of blank-delimited values. Each value has two parts: the first part identifies a topic type, and the second part (after a /) identifies an element type. The class attribute value should be declared as a default attribute value in the DTD. Generally, it should not be modified by the author.
When a specialized type declares new elements, it must provide a class attribute for the new element. The class attribute must include a mapping for every topic type in the specialized type's ancestry, even those in which no element renaming occurred. The mapping should start with topic, and finish with the current element type.
This is necessary so that generalizing and specializing transforms can map values simply and accurately. For example, if task/kwd was missing as a value, and I decided to map this bctask up to a task topic, then the transform would have to guess whether to map to kwd (appropriate if task is more general, which it is) or leave as appname (appropriate if task were more specialized, which it isn't). By always providing mappings for more general values, we can then apply the simple rule that missing mappings must by default be to more specialized values, which means the last value in the list is appropriate. While this example is trivial, more complicated hierarchies (say, five levels deep, with renaming occurring at two and four only) make this kind of mapping essential.
A specialized type does not need to change the class attribute for elements that it does not specialize, but simply reuses by reference from more generic levels. For example, since task and bctask use the p element without specializing it, they don't need to declare mappings for it.
A specialized type only declares class attributes for the elements that it uniquely declares. It does not need to declare class attributes for elements that it reuses or inherits.
Using the class attribute
Applying an XSLT template based on class attribute values allows a transform to be applied to whole branches of element types, instead of just a single element type.
Wherever you would check for element name (any XPath statement that contains an element name value), you need to enhance this to instead check the contents of the element's class attribute. Even if the element is unrecognized, the class attribute can let the transform know that the element belongs to a class of known elements, and can be safely treated according to their rules.
Example:
<xsl:template match="*[contains(@class,' topic/li ')]">
This match statement will work on any li element it encounters. It will also work on step and appstep elements, even though it doesn't know what they are specifically, because the class attribute tells the template what they are generally.
<xsl:template match="*[contains(@class,' task/step ')]">
This match statement won't work on generic li elements, but it will work on both step elements and appstep elements; even though it doesn't know what an appstep is, it knows to treat it like a step.
Be sure to include a leading and trailing blank in your class attribute string check. Otherwise you could get false matches (without the blanks, 'task/step' would match on 'notatask/stepaway', when it shouldn't).
The class attribute in domains specialization
When you create a domains specialization, the new elements still need a class attribute, but should start with a "+" instead of a "-". This signals any generalization transforms to treat the element differently: a domains-aware generalization transform may have different logic for handling domains than for handling topic specializations.
Domain specializations should be derived either from topic (the root topic type), or from another domain specialization. Do not create a domain by specializing an already specialized topic type: this can result in unpredictable generalization behavior, and is not currently supported by the architecture.
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.
dita-ot-1.5.3/doc/articles/DITA-mapdomains.xml 0000664 0000000 0000000 00000051103 11671002146 0021023 0 ustar 00root root 0000000 0000000
How to define a formal information architecture with DITA map domainsThe benefits of formal information typing are well known for the content of topics, but collections of topics also benefit from formal organizing structure. Such formal structures guide authors while they assemble collections of topics and ensure consistent large-scale patterns of information for the user. Using DITA map domains, a designer can define a formal information architecture that can be reused in many deliverables.
This article explains the design technique for creating DITA map domains. As an example, the article walks through the definition for assembling a set of topics as a how-to. Such a how-to could be one reusable design component within an information architecture.
Formal information architecture
Information architecture can be summarized as the design discipline that organizes information and its navigation so an audience can acquire knowledge easily and efficiently. For instance, the information architecture of a web site often provides a hierarchy of web pages for drilling down from general to detailed information, different types of web pages for different purposes such as news and documentation, and so on.
An information architecture is subliminal when it works well. The lack of information architecture is glaring when it works poorly. The user cannot find information or, even worse, cannot recognize or assimilate information when by chance it is encountered. You probably have experience with websites that are poorly organized or uneven in their approach, so that conventions learned in part of the website have no application elsewhere. Extracting knowledge from such information resources is exhausting, and you quickly abandon the effort and seek the information elsewhere.
Currently, information architects work by defining the architecture through guidelines and instructions to the writer. A better approach is to formalize the architecture through an XML design that is validated by the XML editor or parser. This formal approach has the following benefits:
Authors receive guidance from the markup while working.
Information with the same purpose is consistent across deliverables.
Information for a purpose is complete.
Processing can rely on the structure of the information and operate on the declared semantics of the information.
The following drawings illustrate the gain in clarity and consistency by applying a design to produce a formal information architecture:
In short, the formal design acts as a kind of blueprint to be fullfilled by the writer.
Specializing topics and maps
DITA supports the definition of a formal information architecture through topics and map types. The topic type defines the information architecture within topics (the micro level) while the map type defines the information architecture across topics (the macro level).
The base topic and map types are general and flexible so they can accomodate a wide variety of readable information. You specialize these general types to define the restricted types required for your information architecture.
Topic
The topic type mandates the structure for the content of a topic. For instance, the DITA distribution includes a task type that mandates a list of steps as part of the topic content. This specialized topic type provides guidance to the author and ensures the consistency of all task topics. Processing can rely on this consistency and semantic precision. For instance, the processing for the task type could format the task steps as checkable boxes.
Map
The map type mandates the structure for a collection of topics. A map can define the navigation hierarchy for a help system or the sequence and nesting of topics in a book. For instance, the DITA distribution includes a bookmap demo that mandates a sequence of preface, chapter, and appendix roles for the top-level topics. This specialized map type ensures that the collection of topics conforms to a basic book structure.
Without formal types, the information architecture is defined only through editorial guidelines. Different authors may interpret or conform to the guidelines in varying degrees, resulting in inconsistency and impredictability. By contrast, the formal types ensure that the design that can be repeated for many deliverables.
The how-to collection
One typical purpose for a collection of topics is explain how to accomplish a specific goal. A how-to assembles the relevant topics and arranges them in a typical sequence for one way to reach that goal. A standard design pattern for the how-to collection might consist of an introduction topic, some background concepts, some task and example topics, and a summary.
A help system or book might have several how-tos, for instance, on setting up web authentication, reading a database from a web application, and so on. Or, a web provider might publish an ongoing series of how-to articles on technical subjects. Thus, designing a formal how-to pattern would be useful so that all how-tos are consistent regardless of the writer.
Note that formalizing a collection doesn't prevent topic reuse but, instead, guides topic reuse so that appropriate types of topics are used at positions within the collection. For example, in the how-to, concept topics will appear only as background before the tasks rather than in the middle of the how-to.
Map specialization
Among the many capabilities added to maps by DITA 1.3 is specialization through map domains. Instead of packaging specializations of elements for topic content, however, you specialize elements for map content, typically thetopicref. The specialized topicrefelement lets authors specify semantics or constraints on collections of topics. By packaging the topicref specializations as a map domain rather than as a map type, you can reuse the formal collection design in many different map types.
A specialized topicrefcan be used for the following purposes:
To restrict the references to topics of a specialized type. For instance, a conceptref refers only to concept topics (including specialized concepts).
To assign a topic a topic to a role within a collection. For instance, the topic identified by a summaryref could provide the concluding explanation for a collection.
To restrict the contents of the collection, requiring specific topic types or requiring topics to act in specific roles at specified positions within the collection.
Drawing on all of these capabilities, we can define a formal structure for a how-to collection.
Implementing a map domain
A map domain uses the same DTD design pattern as a topic domain. See specializing domains for the details on the domain design pattern, which aren't repeated here. Instead, this article summarizes the application of the domain DTD design pattern to maps.
Create a domain entities file to declare the elements extending the topicref element.Create a domain definition module to define the elements including their element entities, content and attribute definitions, and the architectural class attribute.Create a shell DTD that assembles the base map module and the domain entities file and definition module.Create map collections from the shell DTD. Declaring the map domain entities
The entities file for the how-to domain defines the howto, conceptref, taskref, and exampleref extensions for the topicref element and defines the how-to domain declaration for the domain attributes entity:
The definition module for the how-to domain starts with the element entities so the new elements could, in turn, be extended by subsequent specializations. Of these new elements, only howto has been declared in the entities file because the other new elements should only appear in the child list of the howto element. (In fact, reference typing elements such as conceptref and taskref might also be defined in the entities file for reuse in other specialized child lists.)
The definition module goes on to define the elements. The definition for the howto element restricts the content list for the collection to the metadata for the topic, references to any number of concept topics, references to task topics and optional example topics, and a topic acting in the role of a concluding summary. In addition, the howto element refers to the topic that provides an overview of the contents.
The conceptref and taskref elements have a restricted type, meaning that validating processing is obligated to report an error if the referenced topic doesn't have the declared type (or a specialization from the declared type):
The exampleref and summaryref elements don't restrict the type but, instead, assign roles to the referenced topics. Because the content list of the howto collection topic allows a topic to act as an example and requires a topic to act as a summary, the author is prompted to create topics in those roles, and the roles can be used in processing, for instance, to add a lead-in word to the emitted topic titles.
On closer investigation, either or both of these particular roles may turn out to reflect a persistent topic structure or semantic, in which case it would be appropriate to define topic types and limit the corresponding topicref specialization to topics of those types. The general technique, however, of assigning a role to a topic in the context of a collection remains valid.
Finally, the definition module sets the class attribute to declare that the new elements derive from topicref and are provided by the howto package:
<!ATTLIST howto %global-atts;
class CDATA "- map/topicref howto/howto ">
<!ATTLIST conceptref %global-atts;
class CDATA "- map/topicref howto/conceptref ">
...Assembling the shell DTD
As with topic domains, a shell DTD assembles the base map module with the entities file and definition module for the how-to domain:
<!--vocabulary declarations-->
<!ENTITY % howto-d-dec PUBLIC "-//IBM//ENTITIES DITA How To Map Domain//EN" "howto.ent">
%howto-d-dec;
...
<!--vocabulary substitution (one for each extended base element,
with the names of the domains in which the extension was declared)-->
<!ENTITY % topicref "topicref | %mapgroup-d-topicref; | %howto-d-topicref;">
<!--vocabulary attributes (must be declared ahead of the default definition) -->
<!ENTITY included-domains "&mapgroup-d-att; &howto-d-att;">
<!--Embed map to get generic elements -->
<!ENTITY % map-type PUBLIC "-//IBM//Elements DITA Map//EN" "../../dtd/map.mod">
%map-type;
<!--vocabulary definitions-->
...
<!ENTITY % howto-d-def PUBLIC "-//IBM//ELEMENTS DITA How To Map Domain//EN" "howto.mod">
%howto-d-def;Creating a collection with the domain
Using the shell DTD, a map could include one or more how-to collections, as in the following example:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE map PUBLIC "-//IBM//DTD DITA How To Map//EN"
"howtomap.dtd">
<map>
<!-- how-to clusters can appear anywhere in a map hierarchy but always
follow a consistent information pattern within the how to -->
<howto href="dita-mapdomains.xml">
<conceptref href="informationArchitecture.xml"/>
<conceptref href="mapBackground.xml"/>
<conceptref href="formalCollection.xml"/>
<conceptref href="mapSpecialization.xml"/>
<taskref href="implementDomain.xml"/>
<exampleref href="declareEntities.xml"/>
<exampleref href="domainModule.xml"/>
<exampleref href="assembleDTD.xml"/>
<exampleref href="domainInstance.xml"/>
<summaryref href="summary.xml"/>
</howto>
</map>
In fact, this example is the map for the article that you're reading right now. That is, as you may well have noticed, this article conforms to the formal pattern for a how-to collection. Here's the list of topics in this how-to article but with the addition of the topic type or role and title:
howto: How to define a formal information architecture with DITA map domains
concept: Formal information architecture
concept: Specializing topics and maps
concept: The how-to collection
concept: Map specialization
task: Implementing a map domain
example: Declaring the map domain entities
example: Defining the map domain module
example: Assembling the shell DTD
example: Creating a collection with the domain (this topic)
summary: Summary
While this article contains only a how-to collection, a how-to collection could be part of a larger deliverable. For instance, a help system could include multiple how-tos as part of a navigation hierarchy. Similarly, how-to collections could be used in books by creating a new shell DTD that combines the bookmap map type with the how-to map domain.
As you explore collection types, you'll find that, in addition to topics, a collection can aggregate smaller collections. For instance, you could create domains for a how-to collection, a case study collection, and a reference set collection. A product information collection could then require a product summary topic and at least one of each of these subordinate collections in that order.
You'll also find that, to represent a high-level relationship with a collection, you can create a relationship to the root topic for the collection branch. As the introduction and entry point for the collection, the root topic should provide the most statement of the content of the collection. That is, you can treat the set of topics as a collective content object, using the root topic to represent the collection as a whole for navigation and cross references.
Summary
In this article, you've learned how to specialize the topicref element to mandate a specific collection of topics. For complete, single-purpose collections such as functional specifications and quick reference guides, you might package these specialized topicref elements with a new map type. For building-block collections (such as how-tos or case studies) that can appear within a large deliverable, especially when different designers might create different collection types, you might want to package the specialized topicref elements as a map domain.
By specializing a DITA map in this way, you can implement a formal information architecture not just at the micro level within topics but at the macro level across topics. By defining such large-scale collective content objects, you can provide guidance to authors and declare semantics for processors with the end result that users have consistent and complete information deliverables.
dita-ot-1.5.3/doc/articles/DITA-rm.xml 0000664 0000000 0000000 00000110465 11671002146 0017320 0 ustar 00root root 0000000 0000000
Introduction to the Darwin Information Typing ArchitecturePathway to the futureThis 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... Don R. DayMichael PriestleyDave A SchellDarwin Information Typing ArchitectureDITAXMLtopicinformation architecturearchitectural formsspecializationinformation typedocument metadatadocumentation technical writinguser assistancehelpsExecutive summary
The Darwin Information Typing Architecture (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.
At the heart of DITA (), 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.
Background
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.
Information interchange, tools management, and extensibility
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.
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 universal DTD have ended up either unused or unfinished. The ideal for information interchange is to share the semantics and the transformational rules for this information with other data-owning communities.
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 universal tool set also proves futile. The ideal for tools management 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.
Third, most attempts to formalize a document description vocabulary (DTD or schema) have been done as information modelling exercises to capture the current business practices of data owners. This approach tends to encode legacy practices into the resulting DTDs or vocabularies. The ideal for future extensibility 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.
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.
Main features of the DITA architecture
As the "Architecture" part of DITA's name suggests, DITA has unifying features that serve to organize and integrate information:
Topic orientation. 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.
Reuse. 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:
Topic reuse. 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.
Content reuse. 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.
Specialization. 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.
Topic specialization. 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.
Domain specialization. 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.
Property-based processing. 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.
Extensive metadata to make topics easier to find. 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.
Universal properties. 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).
Taking advantage of existing tags and tools. 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.
Leveraging popular language subsets. 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.
Leveraging popular and well-supported tools. 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.
Topic as the basic architectural unit
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 specialization 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 delivery context 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."
Benefits of the DITA architecture
Through topic granularity and topic type specialization, DITA brings the following benefits of the object-oriented model to information sets:
Encapsulation. 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.
Polymorphism. Special topic types can be treated as more generic topic types for common processing.
Message passing. 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.
DITA can be considered object-oriented in that:
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).
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.
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.
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.
DITA overview
The Darwin Information Typing Architecture defines a set of relationships between the document parts, processors, and communities of users of the information.
The Darwin Information Typing Architecture has the following layers that relate to specific design points expressed in its core DTD, topic.
Layers in the Darwin Information Typing Architecture
Delivery contextshelpsetaggregate printingWeb site; information portal
Typed topic structurestopicconcepttaskreference
Specialized vocabularies (domains) across information typesTyped topic:concepttaskreferenceIncluded domains:highlighting
software
programming
user interface
Common structuresmetadataOASIS (CALS) table
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.
DITA delivery contexts
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.
delivery contextshelpsetaggregate printingWeb site; information portal
The typed topics represent the fundamental structuring layer for DITA topic-oriented content. The basis of the architecture is the topic structure, from which the concept, task, and reference structures are specialized. Extensibility to other typed topics is possible by further specialization.
typed topic structurestopicconcepttaskreference
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.
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.
DITA vocabulary specialization (domains)
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.
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 elementsIn 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:
new vocabulary could not be added without increasing the size of the core DTD
certain domain-specific vocabulary could not be prohibited for DTDs specialized for a different domain.
. 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.
specialized vocabularies (domains) across information typesTyped topic:concepttaskreferenceIncluded domains:highlighting
software
programming
user interface
The basic domains defined as examples for DITA include:
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 any content element in the scope of DITA infotyped topics for a more semantically significant role in a new domain.
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
DITA common structures
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.
common structuresmetadataOASIS (CALS) table
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.
The table structure provides presentational semantics for body-level content. The OASIS/CALS table display model is supported in many popular XML editors.
Elements designed for specialization
DITA provides a rich base for specialization because of the general design of elements used in its archetype-like topic DTD.
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.
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.
The attribute lists within the topic DTD reflect this design philosophy. For example, one of the "universal attributes" (they appear on most elements) is importance, 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.
The values of specialization
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.
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.
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.
Role of content communities in the Darwin Information Typing Architecture
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.
The following figure represents how communities, as "content owners at the topic level," can specialize their content based on the core architecture.
Relationship of specialized communities to the base architecture
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.
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.
The whole process works like a pipeline. The pipeline
input is DITA map, DITA XML files and property files. And
the pipeline output is XHTML, Eclipse help, PDF, JavaHelp,
etc. depending on what output user selects. The pipeline
consists of various modules which performs different functions.
Interface between modules are files in different format.
Here is the overview chart of the two-stage transformation.
The whole pipeline is now controlled by one major Ant script
named 'conductor.xml'. Pipeline modules are implemented using
Ant tasks, XSLT stylesheet or a Java Program. Most modules
are implemented using XSLT stylesheet. For those modules
in the pipeline which are impossible or very difficult to
be implemented using XSLT stylesheet and Ant tasks, we choose
to use Java to implement them.
Ant script
There are four main Ant script files in DITA-OT. The relationship
of the files is illustrated as below.
Conductor.xml acts as the interface that user customized Ant script
can call the targets in it.
Targets in conductor.xmlTarget NameUsagedita2pdfTransform DITA to PDF output (need FOP)dita2docbookTransform DITA files to DOCBOOKdita2xhtmlTransform DITA to XHTML outputdita2javahelpTransform DITA to Java help output (based
on HTML and need Java help builder)dita2eclipsehelpTransform DITA to eclipse help output (based
on HTML)dita2htmlhelpTransform DITA to HTML help
Conductor.xml calls the targets in the following three
Ant script files.
Pretargets.xml contains all the targets that run in the preprocess.
Ditatargets.xml contains all the targets that run in the main
transformation.
Catalog-Ant.xml contains the xml catalog in Ant's style which is
used by Ant.
XSLT modules
Here is the XSLT modules structure.
The shell xsl files act like an interface for users or for Ant
to call. All of the shell xsl files lies in xsl directory.
They are dita2docbook.xsl, dita2fo-shell.xsl, dita2html.xsl,
dita2xhtml.xsl, topic2fo-shell.xsl and map2docbook.xsl.
The xsl files which are responsible for Implentation and specialized
transformation are in the following directories under xsl directory.
Directory NameSpecificationxslhtmlContains the files that implement the
transformation to htmlxslfoContains the files that implement the
transformation to XSL-FOdocbookContains the files that implement the
transformation to docbook
Implementation files are responsible for transforming normal elements
and specialized transformation files are responsible for transforming
elements which are only specified in different domains.
Common utility is contained in common directory under xsl directory.
It provides common function that will be called in transformation
to each output such as output error message, convert string
to lower or upper case and convert specified string to different
language.
Other xsl files in the xsl directory
Other xsl
filesFile Name or Directory NameUsagegeneralize.xslGeneralize a DITA topic file. For example, making
a concept file back to topic file.normalize.xslMake the hidden attributes, such as class
attribute, appear in the topic file.pretty.xslThe reverse action to normalize.specialize.xslThe reverse action to generalize.topicmerge.xslMerge the ditamap and topic files into
one big topic file. (Used in transforming a ditamap to PDF)map2eclipse.xslTransform the ditamap file to table of
content file in eclipse help output.map2hhc.xslTransform the ditamap file to hhc file in HTML
help output.map2hhp.xslTransform the ditamap file to hhp file in HTML
help output.map2htmtoc.xslTransform the ditamap file to the table of content
file in XHTML output.map2JavaHelpMap.xslTransform the ditamap file to jhm file in Java
help output.map2JavaHelpTOC.xslTransform the ditamap file to table of content
file in Java help output.preprocess (directory)This directory contains the xsl files
that used in preprocess as preprocess modules.
Java modules
Java modules
are organized loosely by a Java class named 'PiepleFacade'
which acts as an interface to enable modules can be called
from command line, another Java program or Ant script.
Here
is a detail description of how a GenList
module in the preprocessing stage is implemented in
Java
Here is the class diagram of a sample Java module 'GenListModule' in the
preprocessing stage
We use GenListModule which extends AbstractModule to control the whole
program logic of this module. MapReader is used to parse the input xml
file. It also implements the org.xml.sax.ContentHandler. Is used to
handle different information in xml file, collect and write the information
we need to class Content. ListWriter reads the information from class
GenListModule and outputs those lists into the intermediate files.
Here is the sequence diagram of the example.
GenListModule first creates MapReader and ListWriter. Then GenListModule
calls MapReader to read and parse the input file. In order to process the
large input file, we choose SAX Parser as the parser and each time we only
process one file and keep the list of files we will process later in the
waiting list of GenListModule. After the parse process is
over, GenListModule gets the result content from MapReader. Then
GenListModule processes the content and set the content to ListWriter. Then
it calls ListWriter to output the information to intermediate file.
dita-ot-1.5.3/doc/dev_ref/DITA-OTPreprocess.xml 0000664 0000000 0000000 00000023133 11671002146 0021071 0 ustar 00root root 0000000 0000000
DITA pre-processing architectureThis document describes the different steps in preprocessing
for DITA topics.
The DITA Toolkit implements a multi-stage, map-driven architecture
to process DITA content. Each step in the process examines some or
all of the content; some steps result in temporary files used by later
steps, while others result in updated copies of the DITA content.
Most of the processing takes place in a temporary working directory
(the source files themselves are never modified).
Most of this process is common between all output formats, and
is known as the "preprocess" stage. In general, any DITA process begins
with this common set of pre-processing routines, after which processing
specific to the output format (such as PDF or XHTML) takes over. The
stages of the pre-processing pipeline are described below, after the
following note on processing order.
A note on processing order
The order of
the steps below is significant. Although the DITA specification does
not mandate a specific order for processing, the toolkit has over
time found that the current order best meets user expectations. Switching
the order of processing may give different results.
For
example, if conref is evaluated before filtering, it is possible to
reuse content that will later be filtered out of its original location.
However, we have found that filtering first provides several benefits.
For example, the following <note> element uses conref, but also
contains a product attribute:<note conref="documentA.dita#doc/note" product="MyProd"></note>
If
the conref attribute is evaluated first, then documentA must be parsed
in order to retrieve the note content. That content is then stored
in the current document (or in a representation of that document in
memory). However, if all content with product="MyProd" is filtered
out, then that work is all discarded later in the build.
However,
if the filtering is done first as in the toolkit, this element is
discarded immediately, and documentA is never examined. This provides
several important benefits:
Time is saved simply by discarding unused content as early as
possible; all future steps can load the document without this extra
content.
More significant time is saved in this case by not evaluating
the conref attribute; in fact, documentA does not even need to be
parsed.
Any user reproducing this build does not need documentA. If the
content is sent to a translation team, that team can reproduce an
error-free build without documentA; this means documentA can be kept
back from translation, preventing accidental translation and increased
costs.
<apiname>gen-list</apiname>: generate lists for use
by later steps
The gen-list step examines the input files
and creates lists of topics, images, or other content. These lists
are used by later steps in the pipeline. For example, one list includes
all topics that make use of the conref attribute; only those files
are processed during the conref stage of the build. This step is implemented
in Ant and Java.
The result of this list is a set of several
list files in the temporary directory, including dita.list and dita.xml.properties.
A non-exhaustive selection of each list is given in the table below.
Sample lists included in the dita.list fileProperty NameUsageconreflistDocuments that contains conref attribute that
need to be resolved in preprocess.fullditamapandtopiclistAll of the ditamap and topic files that are
referenced during the transformation. These may be
referenced by href or conref attributes.fullditamaplistAll of the ditamap files in dita.listhrefditatopiclistAll of the topic files that are referenced with
an href attributefullditatopiclistAll of the topic files in dita.listimagelistImages files that are referenced in the content
Debug and filter
This stage processes
all referenced DITA content, and creates copies in a temporary directory
for use during the remainder of the build. This step is implemented
in Java.
As the files are copied, the following modifications
are made:
The files are filtered according to entries in any specified DITAVAL
file.
Debug information is inserted into each element (using the xtrf
and xtrc element). These values allow messages later in the build
to reliably indicate the original source of the error - for example,
the fifth <ph> element in a specific file.
Adjust column names in tables to use a common naming scheme. This
is done only to simplify later conref processing; for example, if
a table row is pulled into another table, this ensures that a reference
to "column 5" will continue to work in the fifth column of the new
table.
Copy related files
This step copies related
non-DITA resources to the output directory, including referenced HTML
files and images referenced by DITAVAL files.
Conref push
This step resolves "conref push"
references. Conref push is a new feature in the DITA 1.2 specification.
This step only processes documents that use conref push (or that are
updated due to the push action. The step is implemented in Java.
Resolve conref
This step resolves traditional
conref attributes. It is implemented in XSLT. The step only runs on
documents that use the conref attribute. It is implemented in XSLT.
move metadata entries
This step pushes
metadata back and forth between maps and topics. For example, index
entries and copyrights in the map are pushed into affected topics,
so that topics may be processed later in isolation while retaining
all relevant metadata. This step is implemented in Java.
Keyref
Keyref is perhaps the most significant
new feature in the DITA 1.2 standard. This step examines all keys
defined in the source material, and updates content appropriately.
Links that make use of keys are updated so that any href value is
replaced by the appropriate target; key based text replacement is
also evaluated. This step is implemented in Java.
Coderef
The codref element was added in
DITA 1.2, and allows references to non-DITA code for use in a codeblock
element. This step reads the referenced document, and adds the content
to the referencing DITA topic. This step is implemented in Java.
Mapref
The mapref step resolves references
to other maps, such as <topicref href="other.ditamap" format="ditamap"></topicref>
This
step is implemented in XSLT.
Mappull
The mappull step pulls content
from referenced topics into maps. For example, by default, the navigation
title on a topicref is replaced by a title from the referenced topic.
Short descriptions and link text are also established during this
stage. Finally, cascading attributes are made explicit; for example,
if a topicref does not set the toc attribute while the parent attribute
sets toc="no", that toc="no" value is explicitly set for the child.
This step is implemented in XSLT.
Chunk
The chunk step breaks apart and assembles
referenced DITA content based on the chunk attribute in maps. For
example, the chunk attribute may be used to assemble all referenced
topics into a single document; alternatively, it may do the opposite
and break one document with multiple topics into several individual
documents. This step is implemented in Java.
Maplink and move-links
These steps work
together to add links to topics based on the location of those topics
in a map. This is where family links (such as parent, child, next,
and previous) are created, as well as links based on relationship
tables. The maplink step (implemented in XSLT) generates all of the
links, and places them in one large file in the temporary directory.
Next, the move-links step (implemented in Java) pushes all of the
generated links into the proper topics.
topicpull:
The topicpull step is similar
to the mappull step, except that it runs on topics. This is used to
pull in titles for <xref> and <link> elements that do not already
specify link text. The step is implemented in XSLT.
Create a new directory in /demo directory, such as /plugin/pluginA.
Under the created directory, include the following subdirectories:
demo/
pluginA/
dtd
schema
catalog
xsl
lib
Note: Not all above subdirectories are required. However,
it is strongly suggested to use the structure and those subdirectories above
to make all files systematically. You also can create files under other directories,
such as python/ or vb/.
Specify the types of topic, such as task, reference or concept.
Put the dtd files into dtd directory.
Put schema files into schema directory.
Put the necessary catalog information about the plug-in from your
own catalog file into catalog directory.
Define the transformation for the new specialization and put it
into xsl directory.
Provide the Ant script to use the xsl file with preprocess with
default ant script template, and put it into pluginA root directory.
Put the complied necessary JAR files into lib directory.
Provide a description file named puglin.xml in pluginA root directory.
It informs the toolkit how to integrate the function of the new plug-in.
This file is an xml file. It's not validated by either dtd file or schema
file. Following specification shows you how to write the description file:
Use <plugin></plugin> tagsto define the root element for
plugin.xml. Set the id attribute, which is uniqute and necessary for each
plug-in.
Under <plugin> element, use <require> element to specify
which plug-in is needed by pluginA. The plugin attribute is used to specify
the ID of the plug-in which is needed by pluginA. This element
is not necessary if pluginA is loaded as an independent plug-in. However,
pluginA might not function after being loaded if another plug-in is needed,
which is not specified by a <require> element.
The <feature> tag specifies the extension point that is extended
and how it's extended in pluginA. For example, <feature
extension="dita.xsl.xhtml" value="xsl/pluginA2xhtml.xsl" type="file"/> means
adding new specific logic transformed from DITA to xhtml into pluginA. The
logic is written in file xsl/pluginA2xhtml.xsl in pluginA directory. type="file" means
that the type of value is file name. Another example, <feature
extension="dita.conductor.transtype.check" value="newoutput" type="txt"/> means
extending "dita.conductor.transtype.check" in pluginA. Another type of transformation
output for DITA-OT and the check logic for parameter transtype in DITA-OT
are to be added. The new transformation output is named newoutput. type="txt" means
the value is text not a file name. There are certain extension
point which can be defined here. See Extension point for
more details.
Package all the subdirectories and files under pluginA to a zip
binary file. Create a DITA Open Toolkit plug-in file for distribution.
Test the usability of plug-in files when integrating into DITA
Opent Toolkit base.
Put the zip binary file on a Web site, such as the DITA OT SourceForge
Web site.
dita-ot-1.5.3/doc/dev_ref/createnewp.xml 0000664 0000000 0000000 00000011612 11671002146 0020116 0 ustar 00root root 0000000 0000000
Create new plug-inCreate a new directory in /demo directory, such as /plugin/pluginA.Under the created directory, include the following subdirectories:demo/
pluginA/
dtd
schema
catalog
xsl
libNot all above subdirectories are required. However,
it is strongly suggested to use the structure and those subdirectories above
to make all files systematically. You also can create files under other directories,
such as python/ or vb/.Specify the types of topic, such as task, reference or concept.Put the dtd files into dtd directory.Put schema files into schema directory.Put the necessary catalog information about the plug-in from your
own catalog file into catalog directory.Define the transformation for the new specialization and put it
into xsl directory.Provide the Ant script to use the xsl file with preprocess with
default ant script template, and put it into pluginA root directory.Put the complied necessary JAR files into lib directory.Provide a description file named puglin.xml in pluginA root directory.
It informs the toolkit how to integrate the function of the new plug-in.This file is an xml file. It's not validated by either dtd file or schema
file. Following specification shows you how to write the description file: An example of the plugin.xml is shown below:<plugin id="org.dita.dost.pluginA">
<require plugin="base_pluginA"/>
<feature extension="dita.conductor.lib.import" value="pluginA.jar" type="file"/>
<feature extension="dita.conductor.transtype.check" value="newoutput" type="txt"/>
<feature extension="dita.conductor.target" value="pluginA_antscript.xml" type="file"/>
<feature extension="dita.specialization.catalog" value="pluginA_catalog-dita.xml" type="file"/>
<feature extension="dita.xsl.xhtml" value="xsl/pluginA2xhtml.xsl" type="file"/>
</plugin>
Use <plugin></plugin> tagsto define the root element for
plugin.xml. Set the id attribute, which is uniqute and necessary for each
plug-in.Under <plugin> element, use <require> element to specify
which plug-in is needed by pluginA. The plugin attribute is used to specify
the ID of the plug-in which is needed by pluginA. This element
is not necessary if pluginA is loaded as an independent plug-in. However,
pluginA might not function after being loaded if another plug-in is needed,
which is not specified by a <require> element. The <feature> tag specifies the extension point that is extended
and how it's extended in pluginA. For example, <feature
extension="dita.xsl.xhtml" value="xsl/pluginA2xhtml.xsl" type="file"/> means
adding new specific logic transformed from DITA to xhtml into pluginA. The
logic is written in file xsl/pluginA2xhtml.xsl in pluginA directory. type="file" means
that the type of value is file name.Another example, <feature
extension="dita.conductor.transtype.check" value="newoutput" type="txt"/> means
extending "dita.conductor.transtype.check" in pluginA. Another type of transformation
output for DITA-OT and the check logic for parameter transtype in DITA-OT
are to be added. The new transformation output is named newoutput. type="txt" means
the value is text not a file name.There are certain extension
point which can be defined here. See for
more details.Package all the subdirectories and files under pluginA to a zip
binary file. Create a DITA Open Toolkit plug-in file for distribution.Test the usability of plug-in files when integrating into DITA
Opent Toolkit base.Put the zip binary file on a Web site, such as the DITA OT SourceForge
Web site. dita-ot-1.5.3/doc/dev_ref/createplugin.html 0000664 0000000 0000000 00000015216 11671002146 0020613 0 ustar 00root root 0000000 0000000
Create plug-in architecture
Create plug-in architecture
DITA Open Toolkit 1.2 and above provides a new function to help developers
create new plug-ins for DITA Open Toolkit.
How to create a new plug-in
The developer can create
plug-ins for DITA Open Toolkit and provide users to use it. SeeCreate new plug-in for
detailed information.
Extension point
The following table
lists the extension points which can be extended by your plug-ins. You need
to specify the extension points in your plugin.xml file.
Table 1. Table of extension point
Extension point
Description
Location
Behavior
dita.specialization.catalog
It points where to provide catalog information for
your plug-ins.
catalog-dita_template.xml
org.dita.dost.platform.InsertAction
It inserts
the content of the file that you provide into catalog-dita.xml. The provided
file must be xml and the root element is not to be inserted into extension
point.
dita.conductor.lib.import
It points where to import your own built Java library
and to make it available for the transformation process.
conductor_template.xml
org.dita.dost.platform.ImportAction
It imports
the Java library that is built and provided into the generated conductor.xml.
dita.conductor.target
It points where to provide your own ant script targets
for transformation.
conductor_template.xml
org.dita.dost.platform.InsertAction
It inserts
the content of the file that you provide into conductor.xml. The
provided file must be xml and the root element is not to be inserted into
extension point.
dita.xsl.fo
It points where to provide your extension xsl code
of fo transformation.
dita2fo-shell_template.xml
org.dita.dost.platform.ImportAction
It imports
the xsl file that you provide into the generated dita2fo-shell.xsl.
dita.xsl.rtf
It points where to provide your extension xsl code
of fo transformation.
dita2rtf_template.xml
org.dita.dost.platform.ImportAction
It imports
the xsl file that you provide into the generated dita2rtf.xsl
.
dita.xsl.xhtml
It points where to provide your extension xsl code
of fo transformation.
dita2xhtml_template.xml
org.dita.dost.platform.ImportAction
It imports
the xsl file that you provide into the generated dita2xhtml.xsl.
dita.xsl.docbook
It points where to provide your extension xsl code
of fo transformation.
dita2docbook_template.xml
org.dita.dost.platform.ImportAction
It imports
the xsl file that you provide into the generated dita2docbook.xsl.
DITA Open Toolkit 1.2 and above provides a new function to help developers
create new plug-ins for DITA Open Toolkit.
How to create a new plug-in
The developer can create
plug-ins for DITA Open Toolkit and provide users to use it. See for
detailed information.
Extension point
The following table
lists the extension points which can be extended by your plug-ins. You need
to specify the extension points in your plugin.xml file.
Table of extension pointExtension pointDescriptionLocationBehaviordita.specialization.catalog It points where to provide catalog information for
your plug-ins.catalog-dita_template.xmlorg.dita.dost.platform.InsertAction
It inserts
the content of the file that you provide into catalog-dita.xml. The provided
file must be xml and the root element is not to be inserted into extension
point.
dita.conductor.lib.import It points where to import your own built Java library
and to make it available for the transformation process.conductor_template.xmlorg.dita.dost.platform.ImportAction
It imports
the Java library that is built and provided into the generated conductor.xml.
dita.conductor.target It points where to provide your own ant script targets
for transformation.conductor_template.xmlorg.dita.dost.platform.InsertAction
It inserts
the content of the file that you provide into conductor.xml. The
provided file must be xml and the root element is not to be inserted into
extension point.
dita.xsl.fo It points where to provide your extension xsl code
of fo transformation. dita2fo-shell_template.xmlorg.dita.dost.platform.ImportAction
It imports
the xsl file that you provide into the generated dita2fo-shell.xsl.
dita.xsl.rtf It points where to provide your extension xsl code
of fo transformation. dita2rtf_template.xmlorg.dita.dost.platform.ImportAction
It imports
the xsl file that you provide into the generated dita2rtf.xsl
.dita.xsl.xhtml It points where to provide your extension xsl code
of fo transformation. dita2xhtml_template.xmlorg.dita.dost.platform.ImportAction
It imports
the xsl file that you provide into the generated dita2xhtml.xsl.
dita.xsl.docbookIt points where to provide your extension xsl code
of fo transformation. dita2docbook_template.xmlorg.dita.dost.platform.ImportAction
It imports
the xsl file that you provide into the generated dita2docbook.xsl.
Option One is just like eclipse plugin architecture. We load the plugins every time a build is invoked.
Opion Two is like mozilla firefox. Every time when we installed new plugin, we should start a program to install those plugin and integrate them with toolkit.
In order to implement either of the above options. We can write a program to generate an integrated interface for ant script or xsl etc. which will be called in the building process. In the following diagram Integrator is such a program which combine every ant script into one integrated script which imports the content from the script of each plugins. This mechanism can ensure that we can implement either option 1 or option 2. When we want to remove a plugin, we can just delete that plugin and call the Integrator again to regenerate integrated ant script. Integrator can also works on the validation of plugins dependency which will make sure that each plugin we will load can work properly.Structure of ant scriptIn the figure, ant script 1 is the ant script provided by plugin 1. Integrated ant script is generated by Integrator. It imports different ant scripts from every plugin and serves as the call interface.
If we want to implement Option One, we need to put the integration step before the preprocess when a build is invoked. If we want to implement Option Two, we can just put integrator as utility in the toolkit and ask users to run that whenever they update, install or remove any plugin. Now we decided to support Option One. So the integrator should be run every time when a build is started and generate the general ant script to be called in the main transformation.
Here is the internal class structure between Integrator and other java classesInternal class structureIn this diagram, Integrator is used to generate all of the integrated ant script, xsl or catalog files. PlugTable is used to find and register all of the plugins. Class Plugin is just like every entry in the plugin table which contains the all of the information for each plugin.
Here is the sequce diagrams for the overall build process and detail integration process.Overall build processDetail sequence of integration
The plugin can also contains the document which serves as the sample document for the plugin. It should contain at least the build script for the document or the document in web pages style with a toc file. The toolkit won't run the build script automatically. Any document plugin with only the source dita files and build script will be considered as the source document plugin and can be build into plugin that toolkit can integrate.
The integration of document is similar to that of ant script. The integrator will generate a general toc file which links to different toc files for each plugin.
Plugin descriptor is an xml file which describe the structure of the plugin and what the plugin contains. The PluginTable search the plugin according plugin descriptor. If there is no plugin descriptor then the plugin cannot be integrated by the toolkit.
Plugin descriptor also contains the dependency information of the plugin and contact information of plugin author. Integrator will validate the dependency between plugins and it will not load the plugin if its required plugin is not loaded. The plugin author information will also be put to website but it can be found in the plugin when the website is inaccessable.
dita-ot-1.5.3/doc/dev_ref/dev_ref.ditamap 0000664 0000000 0000000 00000001401 11671002146 0020205 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/doc/dev_ref/doc.ditamap 0000664 0000000 0000000 00000001062 11671002146 0017343 0 ustar 00root root 0000000 0000000
dita-ot-1.5.3/doc/dev_ref/extension-points.dita 0000664 0000000 0000000 00000054030 11671002146 0021431 0 ustar 00root root 0000000 0000000 
Extension points for plug-ins to the DITA Open ToolkitExtensions to the DITA Open Toolkit are supported through a plug-in extension mechanism.
Plug-ins may do a number of things, such as adding support for specialized DTDs or Schemas,
integrating processing overrides, or providing entirely new output transforms. Extensions are
integrated using a file named plugin.xml, located in the plug-in's root
directory; the plug-in directory itself is generally located within the
demo/ or plugins/ directory inside of the DITA-OT.
This document describes all recognized extension points that are available for use within the
plugin.xml file.
Plugin configuration file
The root element of the plugin.xml file is <plugin>, and must
specify an id attribute. The id attribute is used to
identify the plugin, as well as to identify whether pre-requisite plugins are available. The
id attribute should follow the syntax rules:
The <plugin> element supports the following child elements:
<feature> defines an extension to contribute to a defined
extension point. The following attributes are supported:
AttributeDescriptionRequiredextensionextension point identifieryesvaluecomma separated string value of the extensioneither value or filefilefile path value of the extension, relative to
plugin.xmleither value or filetypetype of the value attributeno
<require> defines plug-in dependencies. The following attributes
are supported:
AttributeDescriptionRequiredpluginvertical bar separated list of plug-ins that are required yesimportantflag whether plug-in is required or optionalno
<template> defines files that should be treated as
templates. The following attributes are supported:
AttributeDescriptionRequiredfilefile path to the template, relative to plugin.xmlyes
<meta> defines metadata. The following attributes are
supported:
AttributeDescriptionRequiredtypemetadata name yesvaluemetadata valueyes
Any extension that is not recognized by the DITA-OT is ignored; all elements other than
<plugin> are optional. Since version 1.5.3 multiple extension
definitions within a plugin configuration file are combined; in older versions only the last
extension definition is used.
XML catalogs
The XML Catalogs extension point is used to update the XML Catalogs used to resolve DTD or
Schema document types. To do this, first create a catalog with only your new values, using
the OASIS Catalog format, and place that in your plugin. Next create a
<feature> element, with the extension attribute set to
"dita.specialization.catalog.relative", the file
attribute set to the name of your local catalog file. For example:
<feature extension="dita.specialization.catalog.relative" file="catalog-dita.xml"/> The dita.specialization.catalog extension is
deprecated.?Use dita.specialization.catalog.relative instead.New Ant targets
The Ant conductor extension point is used to make new targets available to Ant processing.
To do this, first place your extensions in an Ant project file within your plugin, such as
myAntStuff.xml. Create a small wrapper file myAntStuffWrapper.xml in
the same directory:
<dummy> <import file="myAntStuff.xml"/> </dummy>
Then create the following feature:
<feature extension="dita.conductor.target.relative" file="myAntStuffWrapper.xml"/> The dita.conductor.target extension is deprecated.?Use
dita.conductor.target.relative instead.Add Ant targets to the preprocess pipeline
To add an Ant target myTarget to the preprocess pipeline, choose which pipeline stage it
must occur before.?Then create a feature for the extension
depend.preprocess.stagename.pre:
There are also extension points depend.preprocess.pre and
depend.preprocess.post to execute a target before or after all
preprocessing.
New transtype
The transtype extension point is used to define a new "transtype", or transform type, which
makes use of targets in your Ant extensions.
The following feature defines a transform type of "newtext"; using this transform type
will cause the build to look for a target dita2newtext, defined previously in your Ant
extension:
The XSLT import extension points are used to override various steps of XSLT processing. For
this, the extension attribute indicates the step that the override applies to; the value
attribute is a relative path to the override within the current plugin; the type attribute
should be set to "file". The plugin installer will add an XSL import statement to the
default code, so that your override becomes a part of the normal build. The following XSLT
steps are available to override in the core toolkit:
dita.xsl.xhtml
Override default (X)HTML output (including HTML Help and Eclipse Help) with the
following
The generated text extension point is used to add new strings to the default set of
Generated Text. Copy the file xsl/common/strings.xml to your plugin, and edit it to contain
the languages that you are providing translations for ("en-us" must be present).?Copy the
file xsl/common/strings-en-us.xml to your plugin, and replace the
content with your own strings, being sure to give them unique name attributes.?Do the same
for each language that you are providing a translation for.
Use the following extension code to include your strings in the set of generated text:
The string is now available to the XSLT "getString" template.
Pass parameters to XSLT
You can pass parameters from the Ant build to XSLT pipeline stages, usually to have those
parameters avalable as global <xsl:param> values in your XSLT overrides.?Create a
file insertParameters.xml which contains one or more Ant <param> elements:
<dummy>
<!-- Any Ant code allowed in xslt task is possible. Common example: -->
<param name="paramNameinXSLT" expression="${antProperty}" if="antProperty"/>
</dummy>
To add your own warning and error messages to the set supplied by DITA-OT, create the
message in an XML file myMessages.xml:
<dummy>
<!-- See resource/messages.xml for the details. -->
<message id="myMessageId" type="WARN">
<reason>...</reason>
<response>...</response>
</message>
</dummy>
The <require> element requires the plugin
attribute. It is used to identify pre-requisite plug-ins. If the current plugin requires a
plugin with id="plugin-id" before it can be installed, it would include the
following:
<require plugin="plugin-id">
Prerequisite plugins are integrated before the current plugin is integrated. This does the
right thing with respect to XSLT overrides.?If your plugin is a specialization of a
specialization, it should <require> its base plugins, in order from
general to specific.
If a prerequisite plugin is missing, a warning will be printed during integration.?To
suppress this, but keep the integration order if both plugins are present, add
importance="optional" to the <require> element.
If your plugin can depend on any one of several optional plugins, separate the plugin ids
with a vertical bar.?This is most useful when combined with importance="optional":
<require plugin="pluginA|pluginB" importance="optional"/> Version and support information
The following extension points are used by convention to define version and support info
within a plugin:
package.support.name
package.support.email
package.version
The toolkit does not currently do anything with these values, but may do so in the
future.
The package.version value should follow the syntax rules:
version ::= major ( '.' minor ( '.' micro ( '.' qualifier )? )? )?
major ::= number
minor ::= number
micro ::= number
qualifier ::= ( [0..9] | [a..zA..Z] | 抇?| '-' )+
The default value is 0.0.0.
<feature extension="package.support.name" value="Joe the Author"/>
<feature extension="package.support.email" value="joe@example.com"/>
<feature extension="package.version" value="1.2.3"/>Create your own extension points
If your plugin needs to define its own extension point in an XML file, add the string
"_template" to the filename before the file suffix.燚uring integration,
this file will be processed like the built-in DITA-OT templates.ç‡o mark the file as a
template file, use the <template> element.
<template file="myTemplateFile_template.xsl"/> Example plugin.xml file
The following is a sample of a plugin.xml file. This file adds support for a new set of
specialized DTDs, and includes an override for the XHTML output processor. It would go into
a directory such as DITA-OT\plugins\music\ and referenced supporting
files would also exist in that directory. Unfortunately, due to limitations in this wiki,
the full code sample does not show up as well formatted as one might wish. A more extensive
sample using these values is available in the actual music plug-in, available at the DITA-OT download page at
SourceForge
