Tutorial: Specializing DITA Conditional Attributes [W. Eliot Kimber, Blog]

[Grant Hogarth]

Tutorial: Specializing DITA Conditional Attributes
W. Eliot Kimber, Blog

A new feature in Darwin Information Typing Architecture (DITA) 1.1
is the ability to specialize from the base= and props= attributes.
For conditional processing, this lets you add your own attributes
rather than using otherprops=, which can be clearer to authors and
implementors. Note that at the time of writing the DITA Open
Toolkit does not implement support for specializations of props=,
but it should be added soon. This form of specialization is fairly
easy to implement. This tutorial shows you how to do it using DTDs;
the mechanism using Schemas is essentially the same and if you've
stepped up to using the DITA 1.1 schemas I'm going presume you can
figure this out on your own.  The specialization requires two things:
(1) Modification of any shell DTDs that need to reflect the
specialized attribute (e.g., topic.dtd, reference.dtd, or your own
specialized topic types' shell DTDs). You integrate the
specialization attribute domain through the shell DTDs. (2) For
each specialization of props=, a '.ent' declaration set that defines
the attribute and a corresponding domain declaration. This is the
"attribute domain specialization module".  Note that as a rule,
any production use of DITA will likely require local versions of
the DITA-provided shell DTDs, if only to do configuration of the
domains you need, so unless you are using DITA very informally, you
should already have local copies of all the DITA-provided shell
DTDs... For this tutorial assume we're putting everything in the
directory dtd/myspecs within the normal DITA Open Toolkit distribution
structure. It can go anywhere as long as you configure the entity
resolution catalogs appropriately, but for initial development and
testing I find it convenient to use relative paths to the various
declaration components as that eliminates a variable from the
configuration (resolution via catalogs) that can lead to confusing
errors. Once you've established that the declarations are correct
you should replace all relative paths with absolute URLs or (if you
must) PUBLIC IDs that are resolved via catalogs. For my development
work I use the OxygenXML editor, which makes it easy to set up
catalog configurations for testing resolution via catalogs, and
generally testing the correctness of all the parts...

http://drmacros-xml-rants.blogspot.com/2007/03/tutorial-specializing-dit
a-conditional.html
See also DITA resources: http://xml.coverpages.org/dita.html


EXTRACTED FROM XML Daily Newslink. Thursday, 15 March 2007
Provided by OASIS http://www.oasis-open.org