tekom-Tagung 2009 – Countdown

Pünktlich zum Highlight des TR-Jahres erwache ich wieder aus dem Blog-Koma 🙂

Eiiigentlich gäbe es zur Zeit viel zu bloggen, doch ist es mir in den letzten Wochen schwer gefallen auch wirklich etwas zu schreiben. Manchmal muss man abends auch ein bisschen Abstand zum Beruf gewinnen – man nennt es auch Freizeit 😉

In Anbetracht der bevorstehenden Informationsaufnahme mache ich mich aber nun langsam warm.

Ich werde am Mi. und Do. die Tagung besuchen und freue mich riesig. Mein persönlicher Fokus liegt dieses Jahr auf den Themen:

  • Lokalisierung / Übersetzungsmanagement
  • User assistance
  • Redaktionssystem / Metadaten

Ich hoffe, da draußen findet sich dann noch der ein oder andere Blogger, der den Tagungs-Freitag „verarbeiten“ wird 🙂

Links in DITA #3 – Relationship tables

Mit den so genannten Relationship tables (reltable) kann man die Beziehungen zwischen Topics definieren. Hiermit implementiert man Verlinkungen, die nicht durch die Hierarchie (oder die anderen collection-types) festgelegt ist. „Links in DITA #3 – Relationship tables“ weiterlesen

Links in DITA #2 – Hierarchien und collection-type

Ich habe bereits vorgestellt, welche Möglichkeiten des manuellen Verlinkens es gibt. Wie gesagt, erschwert diese Methodik die Wiederverwendung eines Texts. Da Wiederverwendung jedoch einer der Kernpunkte von DITA ist, gibt es natürlich auch hier Mittel und Wege. Und zwar indem man die Verlinkungregeln in die Maps auslagert. So kann man auch nur das verlinken, was in der Map drin ist und läuft nicht Gefahr tote Links zu erzeigen.
„Links in DITA #2 – Hierarchien und collection-type“ weiterlesen

XHTML-Output anpassen

Jeder, der mit DITA anfängt, kommt schnell an dem Punkt an dem er das starke Bedürfnis hat, den Output an das eigene Layout anzupassen. Die Standardlayouts im OT sind, sagen wir mal, sehr nüchtern oder auch eher 0.5 als 2.0 😉

Und in einer Firma will man natürlich Logos und allerlei Schnick-schnack einbauen.

So, und ich will nun beginnen einen schönen XHTML-Output zu bauen und habe nun damit angefangen die XSL-Stylesheets auseinanderzunehmen, um zu verstehen, was eigentlich wo passiert.

Schöne Overrides

Sehr interessant fand ich diese schöne modulare (oh ja, das Wort das jeden technischen Redakteur jauchzen lässt!) Vorgehensweise die eigenen Anforderungen einzubinden. Robert Anderson zeigt in diesem Webinar, dass man eigene Anpassungen immer auslagern sollte, seien es eigene Spezialisierungen oder eben auch „nur“ eigene Layoutdefinitionen. So muss man beispielsweise später keine Bedenken haben, wenn man ein Upgrade auf eine neue OT-Version machen möchte: man hat eben keine Original-OT-Dateien bearbeitet, sondern nur eigene, die in die OT-Dateien nur eingebunden werden.

Das OT bietet dem User die Möglichkeit sogenannte Overrrides zu definieren, die die Standard-Einstellungen mit den selbst definierten überschreiben.  Diese Overrides werden in Plugins ausgelagert. In der Datei _dita2htmlImpl.xsl_ sind dafür ab Zeile 4166 Templates vorgesehen und zwar für Header, Footer, die head-section,Angaben zu CSS-Dateien und Skripten.

Eine sehr einleuchtende Vorgehensweise, die schön modular und damit leichter pflegbar ist.

Ich benutze ja XMetal und hier wurde eine solches Layoutmodul schon mitgeliefert. Wer einmal den Output Single HTML file advanced testet, wird sehen, dass da ein JustSystems-Design hinterlegt ist. Die entsprechenden Dateien findet man je nach Installation ungefähr hier: c:\Programme\Gemeinsame Dateien\XMetaL Shared\DITA_OT\demo\xhtmls.

Hässliche Overrides

Umso seltsamer fand ich, dass für einfache Anpassungen im OT-User-Guide ein ganz anderes Vorgehen geschildert wurde: einfach das XSL aus dem OT kopieren, entsprechend ändern und unter anderem Namen abspeichern. Und dann den Output über dieses eigene Stylesheet erzeugen (Quelle). Nun ja, klar das geht. Aber irgendwann wird es nahezu unmöglich sein herauszufinden, was Original-OT ist und was man selbst verbrochen hat. Und Updates sind dann sehr aufwändig.

Schön oder hässlich? – Kommt drauf an

So wie ich das bisher verstehe, ist „hässliche“ Variante erst sinnvoll, wenn ich den XHTML-Output komplett anders haben möchte. Dann verbiegt man sich komplett, indem man alle Änderungen in Overrides auslagert. Ich habe beim TWiki genau diese Erfahrung nämlich gemacht. Man kann dort die Default-Styles mit eigenen Styles überschreiben und den Rest übernehmen. Bei einem Update haben die selbstdefinierten Styles damals nicht mehr gut funktioniert, weil man sich in zu vielen Punkten auf Default-Styles verlassen hat und die aber beim Update signifikant verändert wurden.

Los geht’s

Bei mir wird leider nicht bei einigen „billigen“ Styleverbesserungen bleiben, sondern ich will strukturell auch einiges anders haben als im Standard-Output und daher versuche ich mal es in einem neuen Stylesheet auszulagern. Es wird spannend 🙂

Logfiles in XMetal – Nachtrag

Einen kleinen Haken hat die Angelegenheit!

Man sollte nicht aus Versehen das Verzeichnis löschen, das man als Logfile-Verzeichnis angegeben hat. Sonst bekommt man nämlich diese vielsagende Fehlermeldung beim Generieren!


Tja, ich wusste durch diese Meldung zwar, dass irgendetwas nicht gefunden wurde, aber was?! Nachdem ich mir anschaute, welche Verzeichnisse ich kurz vorher „aufgeräumt“ hatte, wusste ich Bescheid…

Wer also bei XMetal eine Fehlermeldung zur DitaRenditionsImpl bekommt und gar mit dem Error code -2,146828212, landet hoffentlich auf dieser Seite und erlangt die Erleuchtung. Meine Suche danach hat nämlich nichts ergeben 😉