Der Dating DITA-Vortrag kommt mir gerade wieder in den Sinn, wo ich mich Metadaten beschäftige. Und da stehen mir wirklich die Haare zu Berge – das ist das erste Mal, dass ich DITA wirklich, wirklich unpraktisch finde und noch keine gute Lösung habe, wie ich da in Zukunft verfahren soll.
Wie man komplette Topics nicht rausfiltert
Nehmen wir mal an, ich generiere aus einer Map einen User-Guide und einen Admin-Guide. Viele Inhalte überschneiden sich, aber einige sind exklusiv nur für eine der Zielgruppen gedacht.
Bisher dachte ich mir das so: Wenn ich von einem kompletten Topic weiß, dass es nur audience=”user” ist, dann setz ich das Attribut auf das Root-Element, also so:
<task id="123" product="wundertuete2" audience="user">...
Dann wird doch dieses Topic, auf diese Weise attributiert, nun beim Generieren des Admin-Guides bestimmt nirgends verlinkt bzw. gar nicht erst generiert.
Weit gefehlt. Das Topic wird generiert und zwar leer (und damit nicht valide). Alle Verlinkungen, sprich: alle Topicrefs, sind auch im Output existent, führen aber natürlich ins Leere.
Wie man komplette Topics wirklich rausfiltert
Um zu verhindern, dass etwas überall verlinkt wird, muss man das Attribut auf jeden Topicref setzen!
<topicref id="123" product="wundertuete2" >
<
Und zwar auf wirklich jeden, auch die in den Relationship tables. Und das in allen Maps in denen das Topics vorkommt. Wenn ich da an zentrale, so gut wie immer gültige Attribute wie audience oder product denke, wird mir übel. Wie soll man das denn anständig pflegen oder gar mal aktualisieren? So müsste jeder Redakteur für jedes Topic erneut prüfen, welche Gültigkeit es hat und es auch wieder in der Map hinterlegen. Und darauf hab ich eigentlich überhaupt keine Lust.
(Im Übrigen gilt das Prinzip nicht nur für Topicrefs, sondern auch für den Einsatz anderer interner Verlinkungsarten wie xref oder related-links)
Zudem ist es sehr inkonsistent, dass es hier plötzlich ein eigenes Element audience gibt, zusätzlich zum gleichnamigen Attribut. Um die Verwirrung zu komplettieren, kann man beides gleichzeitig auf einen einzelnen Topicref beziehen.
<topicref id="123" product="wundertuete2" audience="user">
<topicmeta>
Eine passende Diskussion auf der Yahoo-Group hab ich schon gefunden, aber eben leider noch keine Lösung. Und sowas muss ich kurz vor dem Wochenende rausfinden 
Dateiendungen in DITA – kleines Problem
Heute ein kleiner Wissensschnipsel zu Dateiendungen in DITA. Prinzipiell ist es inzwischen erlaubt, sowohl Dateien mit XML-Endung als auch welche mit DITA-Endung in eine Map zu integrieren. Ich persönlich finde ja so einen Misch-masch nicht gut, und als ich es mal getestet habe, hat es auch nicht gut funktioniert.
Kommen wir aber zu einem Problem, das seine Ursache in diesem Misch-Masch hat, und das in den meisten Fällen gar kein Problem ist, außer man schafft es mal wieder einen Sonderfall zu erwischen. So wie ich 
Ich musste gerade bei einer Transformation einem Topic die Information mitgeben, welchen Parent es hat – und zwar musste es die ID des Parents sein.
Da kam mir sehr gelegen, dass in unserem Redaktionssystem der Dateiname auch als Topic-ID fungiert .
Also geb ich hier einfach das href-Attribut des Parents aus, das ja den Dateinamen beinhaltet. Sehr einfach, juhu!
Aber Moment im Endergebnis der Transformation finde ich plötzlich das hier
Die Parent-ID stimmt im Prinzip, bloß ist da plötzlich XML als Dateiendung angegeben! Was soll das denn jetzt?
Ich habe eine Weile gesucht, blieb aber ratlos. Ein Artikel zur Verwendungvon Dateien mit XML-oder DITA-Endung hat mich dann auf die Lösung gebracht. Beim Generieren der temporären Dateien aus denen das Toolkit letzten Endes die Ausgabe baut, kann man sich auch “aussuchen” welche Dateiendung diese temporären Dateien haben sollen.
Standardmäßig werden sie in XML generiert, aber das kann man in seinen Build-Dateien auch ändern.. Also habe ich in meine Build-Datei flugs folgenden Parameter eingebaut:
Und schon hat es gepasst!
Breadcrumbs in DITA-XHTML – Update
Ich habe das Breadcrumbs-Plugin ja bereits vorgestellt. Der damalige Bug bei der Verwendung von Reltables war sehr schnell behoben – superklasse!
Aber schon damals ist mir eine unschöne Sache aufgefallen: der Text für das Wurzelelement in der Breadcrumb ist hart kodiert. Das ist natürlich gerade bei der Internationalisierung der Hilfe eher so ein bisschen doof. Schließlich will ich ja nicht für jedes Generieren jeder Sprache immer wieder die Stylesheets anfassen. Daher hab ich eine Internationalisierung an dieser Stelle eingebaut, d.h. der Text für das Wurzelelement wird je nach Sprache der Map & Topics generiert.
Wer sich dafür interessiert, befolge bitte diese Schritte:
In der Datei dita.xsl.maplink.xsl aus dem Plugin wird dieser Schnipsel
<xsl:param name="indexLinkText" select="'Index'"/>>
zu diesem
<xsl:param name="indexLinkText">
<xsl:call-template name="getString">
<xsl:with-param name="stringName" select="'Start'"/>
</xsl:call-template>
</xsl:param>
In der de-de.xml im xsl-Verzeichnis des Toolkits muss natürlich der entsprechende String angelegt werden:
<str name="Start">Start
Dann muss man noch den obigen Schnipsel aus Zeile 9 in das xsl-Template (ab Zeile 14) verschieben, also so:
<xsl:template match="*" mode="link-to-other">
<xsl:param name="pathBackToMapDirectory"/>
<xsl:param name="indexLinkText">
<xsl:call-template name="getString">
<xsl:with-param name="stringName" select="'Start'"/>
</xsl:call-template>
</xsl:param>
<xsl:if test="$doAncestors='yes'"> ......
Wenn man die Parameterdefinition global belässt, wird immer nur en-us als Sprache erkannt, warum auch immer.
So, das war's auch schon. Und zu meinen Tricks, um mich beim Programmieren und Testen bei Laune zu halten, gehören motivierende Ausgabetexte für den Fall, dass es endlich klappt, und eher so die destruktiven für den anderen Fall
tekom-Jahrestagung 2009 #2 – Dating DITA
Ich war in sage und schreiben einem DITA-Vortrag. Erstens gab es davon gar nicht so viele (”Der Hype flaut ab”, wie ein CMS-Hersteller mir bestätigte), zweitens waren die meisten davon eher auf einem Anfängerlevel.
Bei diesem Vortrag war ich fast geneigt nicht hinzugehen, da mir der Titel zuerst zu gewollt witzig vorkam. Ein Blick in den Tagungsband hat mich dann doch überzeugt.
Hier ging es um einen rein semantischen Blick auf DITA – was ich zur Abwechslung mal sehr erfrischend fand. Das ganze hier spielte hier keine Rolle: “Dann kannst du auch noch das machen – und Maps und Conref… und DITAVAL… das Open Toolkit und Spezialisierung”
DITA – die Informationsarchitektur
Im Blickpunkt stand: die Sicht des Redakteurs. Kann man als Redakteur relativ einfach mit der DITA-DTD arbeiten? Erschließen sich bspw. Elementnamen sofort (”Self-documenting structure”), braucht man am Ende keinen Styleguide mehr?
Ralf Steiner und sein Team haben sich DITA angeschaut und ihnen ist Folgendes aufgefallen
- endlos viele Titles (searchtitle, navtitle, title) und keine gute Abgrenzung
- Abgrenzung zwischen abstract und shortdesc unklar
- das Schachteln von versch. Topictypen ist fragwürdig.
Ich finde es schon fragwürdig, zwei tasks ineinander zu schachteln. - Unterschied zwischen choices und choicetable ist unklar.
Für mich ist das eine Layoutsache, manchmal lassen sich Handlungsvarianten besser tabellarisch darstellen. Aber natürlich ist das wieder so eine Sache, weil man ja hier semantisch denken sollte und nicht layoutorientiert. Doch zu 100% lässt sich das nie trennen, wie ich festgestellt habe. - Was soll das info-Element, wo doch ein Task keine Hintergrundinfo geben soll?
Nun ja, ganz ohne Hintergrundinfo geht es eben nicht. Ich platziere hier auch nur Hintergrundinfo, die sich auf den spezifischen Schritt bezieht, daher hab ich an dem Element nichts auszusetzen. - Wozu braucht man steps-unordered?
Ja, allerdings, wozu? Ob die Steps später nummeriert werden oder als Bullets dargestelt werden, entscheidet sich doch erst beim Generieren. - Die Concept-Topics sind eine Glaskugel aus der man alles ableiten kann.
Oh ja! Ich habe bis heute nur eine vage Idee, wie ich Concepts wirklich standardisieren soll. - Die Benennung der Element ist inkonsistent bzw. nicht sprechend. Man könnte eine dl auch deflist nennen, äquvalent zur linklist.
Ich füge noch hinzu:
- Abgrenzung zwischen context und shortdesc ist schwammig.
- Wozu werden related-links ermöglicht, wenn man doch nur die Wiederverwendung damit erschwert und Relationship tables eigentlich viel besser sind?
- Für Tasten gibt es kein Element! Wie soll den Software-Dokumentation ohne Tasten gehen? Ich habe uicontrol daher eben auch hierfür als Auszeichnungselement definiert.
- Ich kann das p überall benutzen, aber sollte ich auch? Zum Beispiel innerhalb von note, li, shortdesc, context etc.
DITA – ohne Styleguide? Lieber nicht…
Das ist das Fazit von Ralf. Und da kann ich mich voll und ganz anschließen. Ich habe auch zuerst ein Funktionsdesign erarbeitet und dann quasi mit DITA verheiratet. Es sind einfach zu viele Elemente, die nicht eindeutig out-of-the-box zu befüllen sind. Und man hat ja auch bei der Strukturierung immer noch sehr viele Freiheiten, die am Ende dann auch nicht mehr wirklich Standardisierung bedeuten.
Insgesamt ein sehr guter und gut gehaltener Vortrag, der sich mal dem gewidmet hat, auf das es am Ende ankommt: kann man gut damit arbeiten?
PS: Zu viele Bilder der personifizierten DITA sind dann irgendwann auch nicht mehr witzig…