FW: The blizzard of tags in DITA

Hi JoAnn,

Thank you for your interest.

I've attached the plugin. Simply extract it to the DITA OT plugins folder and then run ant -f integrator.xml from the DITA OT root folder. The plugin includes a samples folder that has topics with the necessary public identifiers for calling the restricted DTDs.

Currently, ConfigurationSettings.ent is calling in all of the standard domain modules and each of the 32 constraint modules. As I said in the last message, those can each be included or ignored as needed.

The content model overrides in each of the constraint modules (files of the form simple***Constraint.mod) can also be changed. The overrides that are in there now are simply my best guess as to what they ought to be. The parameter entities used in these content model overridess can be found in a single file named commonElementSets.ent. The commonElementSets.ent file is a verbatim amalgamation of the parameter entity definitions used in the OASIS DTDs.

If you have questions or suggestions please don't hesitate to contact me.

Best Regards,

On Tue, Nov 19, 2013 at 2:41 PM, JoAnn Hackos <joann.hackos@comtech-serv.com> wrote:

Hi Bob,

This looks exactly like what we need. When you've got it set, let me try it out. We could publish an article through OASIS Adoption TC on the process and provide links to the open source. We really need to get this message out. I was amazed that the vendors had not heard of a shell model and never offered the concept to their clients.

JoAnn

JoAnn T. Hackos, PhD

President

Comtech Services Inc.

710 Kipling Street, Suite 400

Denver, CO 80215

Joann.hackos@comtech-serv.com

303-232-7586

From: Bob Thomas <bob.thomas@tagsmiths.com>
Date: Tuesday, November 19, 2013 2:36 PM
To: JoAnn Hackos <joann.hackos@comtech-serv.com>
Subject: The blizzard of tags in DITA

Hi JoAnn,

Your concern about the number of tags that the XML Domain was going to add to out-of-the-box DITA piqued my interest. I have been working on a DITA authoring plugin that I plan to distribute under an open-source license. At this point, the technical implementation for the plugin is complete, but I still need to document it.

The plugin's primary goal is to dramatically reduce the number of tags an author has to choose from, while not losing any of the tags that they actually need. The plugin accomplishes this primarily through DITA constraints. It comes with 32 predefined constraint modules.

The plugin's secondary goal is to make it easy to configure the DITA technical communications shell DTDs from a single configuration file. To make this work, I re-factored the shell DTDs to accept parameters from a file named ConfigurationSettings.ent (see the attached file). This file allows individual domains and constraint modules to be included or excluded from a single point.

For example, to turn off the hazard-statement domain across all of the technical communications shell DTDs, you would make the following change in ConfigurationSettings.ent:

With hazard-statement-domain:



<!ENTITY % hazard-statement-domain "INCLUDE">



Without hazard-statement-domain:





<!ENTITY % hazard-statement-domain "IGNORE">

Once this single change has been made, the concept, ditabase, glossterm, reference, and task DTDs will no longer show any of the hazard-statement-domain tags.

Best Regards,

--
Bob Thomas
+1 720 201 8260

Skype: bob.thomas.colorado

Instant messaging: Gmail chat (bob.thomas@tagsmiths.com) or Skype

Time zone: Mountain (GMT-7)

--
Bob Thomas

+1 720 201 8260

Skype: bob.thomas.colorado

Instant messaging: Gmail chat (bob.thomas@tagsmiths.com) or Skype

Time zone: Mountain (GMT-7)

dita-adoption message