Ich denke, das Besondere bei DITA sind ein paar technische Kniffe, die eine gewisse Generizität des Ansatzes realisieren. Wenn wir im obigen XML Schnippsel noch die DTD mit angeben:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE topic SYSTEM "ditadtd/topic.dtd"> <topic id="maintaining" xml:lang="en-us"> [...] </topic>Plain Text
und eine Identity-Transformation ausführen, so sind magischerweise weitere Attribute hinzugekommen, vgl.
<?xml version="1.0" encoding="UTF-8"?> <topic xmlns:ditaarch="http://dita.oasis-open.org/architecture/2005/" id="maintaining" xml:lang="en-us" ditaarch:DITAArchVersion="1.3" domains="(topic ui-d) (topic hi-d) (topic pr-d) (topic sw-d) (topic ut-d) (topic indexing-d)" class="- topic/topic "> <title class="- topic/title ">Maintaining</title> <shortdesc class="- topic/shortdesc "> You maintain your solution to ensure that all components are operating at maximum efficiency. </shortdesc> <body class="- topic/body "> <p class="- topic/p "> Maintenance is a task that you perform along with configuration to get the most from your solution. </p> </body> </topic>Plain Text
Besonders interessant ist hier das @class Attribut. Wie ist das nun passiert?
XSLT Regeln in einem DITA Prozessor matchen nun nicht auf die Elementnamen, sondern auf die @class Attribute, z.B. so:
<xsl:template match="*[contains(@class,' topic/topic ')]/
*[contains(@class,' topic/title ')]">
[...]Plain TextHier soll der Titel des Topics formatiert werden. In einer Spezialisierung des Topics - das wäre z.B. ein Concept:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> <concept id="concept_kl3_knd_f3b"> <title>My concept</title> <shortdesc>Just a concept to illustrate specialization</shortdesc> <conbody> <p>Yeah, we need some content here, too!</p> </conbody> </concept>Plain Text
werden nun die #FIXED Attribute folgendermassen gesetzt:
<?xml version="1.0" encoding="UTF-8"?> <concept xmlns:ditaarch="http://dita.oasis-open.org/architecture/2005/" id="concept_kl3_knd_f3b" ditaarch:DITAArchVersion="1.3" class="- topic/topic concept/concept "> <title class="- topic/title ">My concept</title> <shortdesc class="- topic/shortdesc ">Just a concept to illustrate specialization</shortdesc> <conbody class="- topic/body concept/conbody "> <p class="- topic/p ">Yeah, we need some content here, too!</p> </conbody> </concept>Plain Text
Unsere Regel von oben mit
<xsl:template match="*[contains(@class,' topic/topic ')]/ *[contains(@class,' topic/title ')]"> [...]Plain Text
die einen Titel formatiert, würde also sowohl für Topic-Elemente, als auch für Concept-Elemente gelten. Will man eine Spezialformatierung für Concept-Elemente, so müsste man die folgende Regel noch zur Regelbasis mithinzunehmen:
<xsl:template match="*[contains(@class,' concept/concept ')]/ *[contains(@class,' topic/title ')]"> [...]Plain Text
Warum ist das Ganze nun so clever? Wenn bspw. Firma XYZ noch keine Concept-Definitionen erstellt hat, kann sie trotzdem Concept-Elemente der Firma ABC verarbeiten, weil die Match-Regeln nicht auf Elementnamen operieren, sondern auf dynamisch durch die DTD hinzugefügte Klassenattribute - die neben der Bezeichner der Spezialisierung auch die Bezeichner der Generalisierung enthalten. Diese kennt jeder DITA Prozessor und kann zumindest einen Default bereitstellen.
Für obiges Beispiel - bzgl. des Titels - würde das bedeuten, dass der Concept-Titel in Firma XYZ nicht so schön (oder an einer bestimmten Stelle) dargestellt wird, wie er in Firma ABC angedacht war. Der wichtige Content wird aber trotzdem dargestellt.
Das Erstellen einer redundanzarmen DITA DTD ist allerdings eine Wissenschaft für sich. Schliesslich will man ja auch für eigene Spezialisierungen den generischen Ansatz beibehalten. Der DITA Redakteur oder besser der Dokumentationsbeauftragte muss sich deshalb einer ziemlich komplizierten Namens- und Strukturkonvention unterziehen.