Lade...
 

Dies & Das

In diesem Blog finden Sie alle möglichen Informationen rund um practice innovation

Das in Kooperation mit Tracom(externer Link) entwickelte Filter-Plugin für SDL Trados Studio, um Visio Dokumente performant und sicher mit Trados übersetzen zu können, steht jetzt auch auf der OpenExchange-Plattform von SDL(externer Link) zum Download zur Verfügung.
veröffentlicht am 07 11 2011
Drucken
ODBC-Fehler
Folgende(r) Fehler trat(en) auf:
 
[Microsoft][ODBC Driver Manager] Der angegebene DSN weist eine nicht übereinstimmende Architektur von Treiber und Anwendung auf
Benötigt eine 32Bit Anwendung auf einem 64Bit System Zugriff über die ODBC-Schnittstelle auf die Datenbank, kommt es des Öfteren zu dieser Fehlermeldung. Grund dafür: Die 32Bit Anwendung versucht über die 64Bit ODBC-Schnittstelle mit der Datenbank zu kommunizieren. Deshalb muss für eine 32Bit-Anwendung auch eine 32Bit-ODBC-Konfiguration eingerichtet werden. Unter einem Windows 64Bit Betriebssystem erhält man über die Systemsteuerung lediglich Zugriff auf die 64Bit ODBC-Schnittstelle. Man kann also über die Systemsteuerung lediglich ODBC-Verbindungen für 64-Bit-Anwendungen einrichten. . Der Zugriff auf die 32Bit Schnittstelle ist nicht direkt über die Systemsteuerung möglich. Allerdings ist diese über den Explorer oder die DOS-Box über C:\Windows\SysWOW64\odbcad32.exe aufrufbar. Die 64Bit Schnittstelle ist hingegen unter C:\Windows\System32\odbcad32.exe zu finden. Interessanterweise heißen beide Programme odbcad32.exe; die erstere, die sich dann auch noch unter SysWOW64 befindet ist die 32Bit Adminschnittstelle, zweitere die 64Bit Schnittstelle. Aha. Ob die 32Bit oder 64Bit Schnittstelle gestartet ist erkennt man deshalb am besten im Taskmanager. Eine 32Bit-Anwendung wird auf einem 64Bit Betriebssystem immer mit *32 hinter dem Prozessnamen gekennzeichnet. Im Taskmanager handelt es sich also bei der odbcad.exe um die 64Bit Version und bei der odbcad.exe*32 um die 32Bit-Version der ODBC-Schnittstelle. Eigentlich alles ganz einfach. Noch einfacher wäre es, wenn die Namensgebung etwas sprechender gewählt wäre ;-)
veröffentlicht am 10 07 2011
Drucken
Am 19.05.2011 durfte ich das CrossMediaForum(externer Link) in München besuchen, bei dem das Thema HyperDistribution groß ausgehangen wurde. Insgesamt eine sehr gelungene Veranstaltung, die mir Gelegenheit gab mal etwas in die Verlagswelt zu schnuppern. Besonders interessant war der Vortrag Wie kann eine Tageszeitung ihre Reichweite über eine Mehr-Kanal-Strategie erfolgreich erhöhen?(externer Link) der Mittelbayerischen Zeitung(externer Link). Eindrucksvoll wurde hier dargestellt, wie die Mittelbayerische heute Ihre Informationen nicht nur für den Printbereich erstellt sondern diese Informationen über verschiedene Kanäle wieder verwendet, diese den Anwendern anders aufbereitet zugänglich macht und damit neue Geschäftsbereiche erschließt. Mit der Webseite Regensburg entdecken(externer Link) wurde hier ein sehr schönes und wie ich finde innovatives Projekt vorgestellt. Aus rein technischer Sicht ebenfalls beeindruckend der Vortrag Hyperdistribution durch Systemintegration: Wie de Gruyter CMS, CRM und ERP integriert(externer Link) von Christian Kohl. Der Verlag Walter de Gruyter(externer Link) hat sich das große Ziel gesteckt, alle Systeme, vom ERP über CRM bis hin zu den verschiedenen CMS-Systemen, über definierte Schnittstellen soweit zu vernetzen, dass jedes System mit dem anderen Kommunizieren und Informationen austauschen kann. Das Endergebnis: Ein einziges großes Informationssystem – zusammengesetzt aus mehreren Subsystemen verschiedenster Herstelltér. Absolut beeindruckend - vor allem die drittletzte Folie. Ist ein Vortrag wie Digitale Inseln im analogen Fluss.(externer Link), in dem es im Wesentlichen darum geht, dass man Dateien nicht wild durch die Weltgeschichte schicken sondern zentral auf einem Server abgelegen sollen, heute wirklich noch ein Thema. Hier sind wir in der Industrie doch schon viel weiter. Oder!? Leider fand der Vortrag Standardisierung und Medienvielfalt - Was Verlage von der Industrie lernen können(externer Link) , der mich natürlich brennend interessiert hat, krankheitsbedingt nicht statt. Die Folien wurden aber dankenswerter Weise trotzdem zur Verfügung gestellt. Sehen Sie selbst.

Fazit

Verlage und die technische Dokumentation haben grundsätzlich die gleiche Anforderung an Ihre Inhalte und damit an die Prozesse. Angefangen beim Multichannel-Publishing, über das Lektorat bis hin zum Variantenmanagement. Selbstverständlich unterscheiden sich diese Anforderungen in der Ausprägung von Details ganz erheblich, aber der aus meiner Sicht größte Unterschied, ist der dass Verlage mit Ihren Inhalten – also Ihren Produkten - Geld verdienen möchten und dies auch durch neue innovative Ideen und Neuausrichtungen schaffen. Bei der technischen Dokumentation hingegeben geht es heute - leider noch zu oft - einzig und allein darum Kosten einzusparen und Prozesse effektiver zu gestalten. Sicherlich ein wichtiger Aspekt, was dazu führt, dass manche Entscheidungsfindungs- und Änderungsprozesse schnellere Durchlaufzeiten aufweisen, als im Verlagswesen. Aus meiner Sicht könnte sich hier aber auch in der Technischen Dokumentation etwas tun, so dass diese nicht nur als Kostentreiber sondern, durch neue innovative Ideen, als Instrument gesehen wird, das Ihren Teil zur Wertschöpfungskette im Produktionsprozess beiträgt.
veröffentlicht am 31 05 2011
Drucken
Immer wieder beschäftigt mich in meinen Projekten ein Thema: Weißraum. Was für ein schönes Wort. Dabei beschäftigt mich dieses Wort nicht, wenn es darum geht Absätze oder Zeichen für die bessere Lesbarkeit der Dokumentation mit einem Abstand zu versehen. Hier ist es durchaus sinnvoll und kann auch regelbasiert umgesetzt werden. Vielmehr beschäftigt es mich, wenn auf Seiten ein Drittel des Platzes einfach dafür freigelassen wird, damit bei langläufigen Sprachen sichergestellt ist, dass der Inhalt immer noch auf die gleiche Seite passt. Weißraum ist unbedingt notwendig, so die immer gleiche Diskussion, damit der Service- oder Supportmitarbeiter, die Seitenzahl, auf der eine Information zu finden ist, egal welche Sprache der Kunde spricht, auf Anhieb dem Interessenten mitteilen kann. Ist dieser Vorteil heute wirklich noch zeitgemäß und ist der Aufwand der heute noch dafür getrieben wird wirklich gerechtfertigt? Wenn ich mir dann die Dokumente, in denen dieser Weißraum realisiert wird, anschaue, stelle ich dann fest, dass dies oft mit manuellen Zeilenschaltungen, Umbrüchen und sonstiger Kreativität des Redakteurs realisiert ist. Es sind keine Auszeichnungen, durch spezielle Absatzformate oder sonstige Kennzeichnungen vorgesehen. Diese Absätze unterscheiden sich also vom restlichen Inhalt einfach nur dadurch, dass sie keinen Inhalt haben. Cool! Dann haben wir doch eine Regel. Ist es so? Haben diese dann wirklich keinen Inhalt? Nein die Konsequenz in der Inkonsequenz fehlt: Denn da ist dann schon einmal der ein oder andere Tabellen- oder Grafikanker oder ein Leerzeichen zu finden. Wie sich dann herausstellt ist eine nachträgliche Layoutierung dann immer noch notwendig, weil man eben für eine Sprache dann doch zu wenig Platz gelassen hat. Zur Not macht man eben an solchen Problemstellen die Schrift einen Punkt kleiner. Hauptsache es passt auf die Seite. Hat man das dann alles geschafft, kommt zum Schluss der Produktmanager und hätte an bestimmten Stellen dann noch gerne einen Umbruch, weil es eben besser aussieht. Aha!? Was für ein Aufwand hierfür im Erstellungs-, Übersetzungs- und im abschließenden Finishing getrieben wird, nur um eine scheinbar sinnvolle Anforderung zu erfüllen, ist unvorstellbar! Denn dieser Aufwand entsteht bei jeder Überarbeitung aufs Neue. Wie oft ruft denn ein Kunde wirklich an, dem genau ein Hinweis auf eine Seite genügt? Gibt es noch Servicemitarbeiter, die Ihren Kunden mit der Aussage „… schauen Sie auf Seite 598 nach, da steht‘s…“ abspeisen? Sicherlich ist ein Hinweis auf die Stelle in der Dokumentation hilfreich. Genügt dann aber nicht der Hinweis „…wenn Sie es nachlesen wollen, finden Sie Informationen hierzu auch in Kapitel 7.3.2“? Aber nicht nur der Aufwand in Erstellung und Übersetzung steigt. Auch die Druckkosten nehmen durch solche Mittel enorm zu, da enorm viel Papier für „Nichts“ verbraucht wird. Gerade in der Zeit in denen durch die steigende Anzahl von zu dokumentierenden Produktvarianten und zunehmenden Anzahl an Zielsprachen nimmt das Druckvolumen ohnehin rasant zu. Ist das wirklich noch das Thema in das Redakteure und Übersetzer Ihre Zeit und Ihr Geld investieren müssen? Ich denke nein: Es gibt heute sicherlich spannendere Themen als dieses, in die es sich lohnt, einmalig und nicht immer wieder neu, zu investieren. Es geht darum, den Kunden mit Informationen zu bedienen. Informationen, die sich heutige Anwender aus verschiedenen Kanälen und Medien holen. Es stellt sich heute die Aufgabe für die technische Dokumentation neue Informationskanäle zu erschließen und somit den Kunden den für Ihn bestmöglichen Informationszugang zu ermöglichen. Hier liegt doch der wahre Nutzen für alle Beteiligten: im Prozess der Informationsbeschaffung.

Ein Bespiel

Bei der Einführung von TIM-RS(externer Link) - in einem Projekt mit dem strukturierten FrameMaker - ist es uns alleine durch die Umstellung des Layouts und den Verzicht auf Weißraum gelungen ca. 100 Mio. Seiten Papier pro Jahr einzusparen. Was dies an Kostenersparnis bedeutet, kann jeder für sich selbst ausrechnen. Dabei wurde dies im gesamten Projekt nie als Ziel definiert. Die Vorteile wurden sich bei der Einsparung von Übersetzungskosten, Wiederverwendung von Inhalten und automatischen Publikationsprozessen in verschiedensten Formaten erhofft. Diese Einsparung bei den Druckkosten war also nicht mehr als ein „Abfallprodukt“, welches sich aus der konsequenten XML-Umsetzung und natürlich der Bereitschaft des Kunden, das Layout der Anleitung diesen neuen Anforderungen leicht(!) anzupassen, von selbst ergeben hat. Und nebenbei bemerkt: Die Benutzerfreundlichkeit hat darunter nicht gelitten. Im Gegenteil!

Ein nicht ganz neues Fazit: CONTENT FIRST

Es ist Aufgabe eines automatischen Layoutprozesses, für das richtige Layout in der jeweiligen Zielsprache und vor allem für den jeweiligen Ausgabekanal zu sorgen. Hierfür gilt es zum einen Regeln für das Layout zu finden, die eine Software verstehen und entsprechend umsetzen kann. Zum anderen die Bereitschaft nicht regelbasierte Layoutentscheidungen zu hinterfragen und nach Möglichkeit zu eliminieren. Jeder manuelle Eingriff ins Layout kostet Geld! Und das immer und immer wieder. Weißraum bedeutet immer einen manuellen Eingriff. Auch wenn über Attributierungen oder spezielle Absatzformate eine Auszeichnung dieser Stellen erfolgt. Verzichten Sie darauf!!!
veröffentlicht am 28 05 2011
Drucken
Zum gestrigen Regionalgruppentreffen war ich als Referent bei MB DocuTec Ravensburg zum Thema "ePUB in der Technischen Dokumentation" eingeladen. Rund 30 Teilnehmer machten sich am späteren Abend auf zum Vortrag. Für mich ein überraschend großes Interesse, für ein Thema, das in der TechDoc derzeit nur am Rande diskutiert wird. Die Folien zum Vortrag möchte ich Ihnen nicht vorenthalten. Sie stehen hier zum Download bereit. Mein Fazit zu ePUB: ePUB ist derzeit sicherlich nicht das Format, welches in der Technischen Dokumentation den wichtigsten Platz einnimmt und kurzfristig einnehmen wird. PDF und Online-Hilfe-Formate haben hier sicherlich auch in Zukunft weiterhin die Oberhand. Dennoch bietet ePUB, spätestens mit den geplanten Erweiterungen in ePUB 3.0, interessante Perspektiven und stellt einen weiteren Informationskanal bereit, mit denen Anwender mit Informationen versorgt werden müssen. Die Voraussetzungen ePUB 2.0 zu generieren, sind in vielen Unternehmen vorhanden; egal ob sie mit "unstrukturierten" oder "strukturtieren" (XML) Informationen arbeiten. Gerade dann, wenn sie bereits XHTML-basierte Dokumentationen erstellen. Tools zum Erstellen (Packen) des ePUB-Pakets (mehr ist es ja erstmal nicht wenn die Inhalte vorliegen) sind in ausreichender Zahl - und teilweise - auch frei verfügbar vorhanden. Selbst wenn das Thema ePUB heute für Sie kein Thema ist, zeigt es doch wohin die Reise geht. Immer mehr Formate, Geräte, Informationskanäle und damit auch Kundenwünsche, werden künftig in der Technischen Dokumentation bedient werden müssen. Deshalb müssen, wer es noch nicht getan hat, bereits heute die Weichen für die Zukunft gestellt werden. ePUB ist "pretty cool", gerade seit dem heutigen Hype um iPad & Co. Das (Produkt-)Marketing fährt sicherlich auf das Format ab. Auch wenn ePUB zunächst scheinbar keinen Nutzen für den Anwender technischer Dokumentation bringt, kann es eines schaffen: Es kann den die TechDoc etwas aus dem Schatten holen, so dass sie, wie leider noch zu oft der Fall, nicht immer nur als Kostentreiber gesehen wird, sondern auch zur Verbesserung des Produkts und somit zur Wertschöpfung beitragen kann. Voraussetzung dafür: das Erzeugen des Ausgabeformat lässt die Kosten nicht explodieren. Sie müssen gegen NULL tendieren.
veröffentlicht am 27 05 2011
Drucken
Während der Entwicklung eines Installers mittels Visual Studio 2010 Setup- und Bereitstellungsprojekten hatte ich das Problem, dass die Verknüpfung zur MSI-Datei verloren ging. Eine Deinstallation meines Debug-Builds war somit nicht mehr möglich. Bei meinen Recherchen bin ich auf das Tool Revo-Uninstaller(externer Link) gestoßen. Ein sehr mächtiges Tool, welches meine Umgebung wieder sauber bereinigen konnte. Da das Problem, dass eine Software nicht mehr deinstalliert werden kann, auch außerhalb von Entwicklungsumgebungen auftreten kann, ist dies vielleicht auch von allgemeinerem Interesse. Bitte nicht vergessen einen Wiederherstellungspunkt zu erstellen. Bei der Verwendung der Standardsettings, wird dieser automatisch durch Revo-Uninstaller erstellt.
veröffentlicht am 07 01 2011
Drucken
In diesem Beitrag möchte ich auf die beiden Achsen preceding und following in XSLT eingehen. Wo die Funktionsweise der Achsen preceding-sibling und following-sibling recht klar verständlich und leicht erklärbar ist, ist die Funktionsweise der Achsen following und preceding oft nicht immer so leicht verständlich, zumindest dann nicht, wenn sie in einem konkreten Anwendungsfall eingesetzt werden sollen. Während preceding-sibling(externer Link) und following-sibling(externer Link) die Geschwisterknoten eines konkreten Knotens behandelt, behandelt preceding(externer Link) alle Vorgängerknoten ohne Berücksichtigung der Hierarchie und ohne die Knoten der ancestor-or-self-Achse(externer Link). following(externer Link) behandelt alle Knoten, die auf einen ausgewählten Knoten folgen, ungeachtet der Hierarchie der Knoten. Die Arbeitsweise mit preceding und following soll in einem kleinen Tutorial zur Publikation von Leseproben für Bücher, die u.a. auf dieser Grundlage Käufer finden sollen, erklärt werden. Dabei kommen Freunde von komplexen XPath-Ausdrücke sicherlich auf ihre Kosten, wir müssen Regeln auf Basis von XPath-Ausdrücke finden, die Knoten zwischen zwei Knoten, die an einer beliebigen Stelle in der Hierachie vorkommen können, finden. Noch nicht spannend? Abwarten und weiterlesen!

Problemstellung

Auf den Daten für ein Buch soll mit einem anderen oder erweiterten XSLT-Stylesheet eine Leseprobe generiert werden können. Das Spezielle: Der Autor soll an beliebiger Stelle im Textfluss den Beginn und das Ende von Passagen für eine Leseprobe markieren können. Der Transformationsprozess soll dann die Bestandteile des Dokuments ignorieren, welche außerhalb dieser markierten Bereiche liegen. Beim Einsatz von XML-Dokumenten sind hier einige Fragen zu klären, die bei unstrukturierten Dokumenten nicht auftreten. Denn: Die Ergebnisstruktur muss zum einen die Hierarchien beibehalten, well-formed (und idealerweise valide) sein, um dieses entsprechend mit XML-Technologien (hier XSLT) weiter verarbeiten zu können. Grundsätzlich muss das XML nicht valide sein, dennoch muss es von der Struktur bestimmten Regeln genügen, die sicherstellen, dass elementare Strukturen (z.B. Tabellen) weiterhin den Anforderungen für die spätere Ausgabe genügen.

Lösungsansatz

In der Struktur werden zwei weitere Elemente BeginLP und EndLP als Inline-Elemente bei der Texteingabe zugelassen. Der Autor hat so die Möglichkeit den Beginn und das Ende einer Leseprobe beim Schreiben seines Textes selbst zu definieren, wichtige Passagen auszuschließen und Passagen, die den Leser zum Kauf animieren sollen, zu markieren. Dabei können auf diese Art mehrere dieser Bereiche definiert werden. Der Publikationsprozess auf Basis des Gesamt-XMLs wird parametrisiert und auszuschließende Teile durch diesen ignoriert. Das ist Aufgabe des Prozesses mittels XSLT und läuft für alle Publikationen auf die selbe Weise automatisch im Hintergrund ab. Die Entwicklung des XSLT wird im folgenden Schritt für Schritt beschrieben. Zunächst aber noch einen Blick in das Ausgangs-XML:
Basis XML
  1 . <Document>
  2 .     <Cover>
  3 .         <Author>Markus Wiedenmaier</Author>
  4 .         <Title>Leseproben auf Basis von XML</Title>
  5 .     </Cover>
  6 .     <Chapter>
  7 .         <Head>Kapitel 1</Head>
  8 .             <!-- More Content -->
  9 .     </Chapter>
 10 .     <Chapter>
 11 .         <Head>Kapitel 2</Head>
 12 .         <Chapter>
 13 .             <Head>Kapitel 2.1</Head>
 14 .             <!-- More Content -->
 15 .         </Chapter>
 16 .         <Chapter>
 17 .             <Head>Kapitel 2.2</Head>
 18 .             <Para>
 19 .                 <BodyText></BodyText>
 20 .                 <BodyText><BeginLP/></BodyText>
 21 .             </Para>
 22 .         </Chapter>
 23 .         <Chapter>
 24 .             <Head>Kapitel 2.3</Head>
 25 .             <Para>
 26 .                 <BodyText></BodyText>
 27 .                 <BodyText><EndLP/></BodyText>
 28 .                 <BodyText></BodyText>
 29 .             </Para>
 30 .         </Chapter>
 31 .     </Chapter>
 32 .     <Chapter>
 33 .         <Head>Kapitel 3</Head>
 34 .         <Para>
 35 .             <!-- More Content -->
 36 .         </Para>
 37 .     </Chapter>
 38 .     <Back>
 39 .         <ISBN>1-111-111-1111</ISBN>
 40 .     </Back>
 41 . </Document>
In Zeile 20 wird der Beginn der Leseprobe durch den Autor markiert. Das heißt die Inhalte vor diesem Element nach oben müssen ignoriert werden. Des weiteren wird in Zeile 27 das Ende der Leseprobe markiert. Das heißt, alle Inhalte nach diesem Element dürfen ebenfalls nicht mehr publiziert werden. Eine Ausnahme stellen die Informationen im Cover und Back-Element dar . Zudem soll die Hierarchie (Zeilen, 20, 18, 16, 10, 1) beibehalten werden. Und natürlich dürfen die dazugehörigen Überschriften (Zeilen 17 und 11) nicht fehlen.
Mehr... (4 Seiten)
veröffentlicht am 07 12 2010
Drucken
Michael Kay hat in seinem Blog The 10 most common XSLT programming mistakes(externer Link) für mich sehr eindrücklich dargestellt, welche Fehler bei der Entwicklung von Stylesheets vermieden werden sollten. Ein Blick in diese Liste schadet bei einem Code Review nie, denn sie hilft dabei die Qualität von XSLTs erheblich zu verbessern. Denn oft gibt es bessere und sogar einfachere Lösungsmöglichkeiten, wenn man diese Regeln befolgt und nach und nach verinnerlicht. Bei meiner täglichen Arbeit mit XSLT halte ich mich dabei an weitere, mir selbst auferlegte Entwicklungsrichtlinien für XSLT-Stylesheets, um die Qualität der jeweiligen Anwendungen und eine nachhaltige Umsetzung sicherzustellen.

1. Du sollst mit Elementen aus dem XSL-Namensraum arbeiten

Gerade in vielen XSLTs, die in das HTML-Format transformieren, findet man sehr häufig, dass die HTML-Auszeichnung direkt als Inhalt des Templates geschrieben wird. Diese Art der Programmierung ist zulässig und wird auch entsprechend unterstützt. XSLT-Editoren wie Stylus Studio bieten hierfür sogar eine Intellisense an, mit der die Erfassung der HTML-Tags vereinfacht wird.
Code-Snippet 1
  1 . <h1 class="Heading1"></h1>
Diese Art der Programmierung ist aber wenig flexibel und meiner Ansicht nach nicht im Sinne von XSLT. Dafür gibt es im XSL-Namensraum entsprechende Elemente, mit denen mit XSL-Syntax programmiert werden kann.
Code-Snippet 2
  1 . Heading1
Diese Art der Programmierung sieht nicht nur schöner aus :-) sondern bietet gerade in der Pflege der XSLT-Stylesheets eine erheblich höhere Flexibilität. Wird es beispielsweise notwendig, abhängig von einer Bedingung das class-Attribute entsprechend zu erweiteren, wird das XSLT schnell unübersichtlich und führt zu unnötigem doppelten Code.
Code-Snippet 3
  1 . <h1 class="Heading1 Condition"></h1>
  2 .         <h1 class="Heading1"></h1>
Mit der konsequenten Arbeit mit xsl:element und xsl:attribute wird das Template übersichtlicher und doppelter Code wird vermieden, was das XSLT um vieles vereinfacht und es somit wartbarer wird:
Code-Snippet 4
  1 . Heading1condition
Die Logik des Code-Beispiels 4 ändert sich grundsätzlich nicht. Nur die Prüfung der Bedingung ist direkt in die Logik integriert. Im Code-Snippet 3 muss aber die gesamte Logik des Templates dupliziert werden.

2. Du sollst das Push-Verfahren verwenden

Wie Michael Kay im Punkt 4 seines Blog-Beitrags bereits ausführt, dürfen die Elemente xsl:template und xsl:apply-templates in XSLTs gerne verwendet werden. Denn diese Konstrukte bilden das Grundgerüst der XSL-Technologie. Bei der Verwendung solcher Anweisungen spricht man vom Push-Verfahren, denn beim Aufruf von xsl:apply-templates wird die Verarbeitung der folgenden Knoten an xsl:template weitergegeben; push. Das Code-Snipped 2 zeigt dies auf relativ einfacher Art. Der Inhalt wird nicht durch das Template "Chapter/Head" ausgegeben, sondern durch weitere Templates erledigt, welche die Unterknoten des Head-Elements (z.B. Textknoten) bearbeiten. Ein Beispiel für das Pull-Verfahren zeigt Code-Snippet 1. Der Inhalt des Head-Elements wird direkt im Template "Chapter/Head" bearbeitet und mittels xsl:value-of ausgegeben. Der Inhalt wird also in das Templates gezogen; pull. In diesem Fall wird nur der Text ausgegeben. Inline-Elemente, welche bestimmten Text beispielsweise kursiv auszeichnet, werden hier nicht beachtet. Im Fall des Push-Verfahrens finden diese Elemente aber sehr wohl Beachtung, wenn auch nur durch das Standardtemplate . Sobald aber für das Element welches Text kursiv auszeichnet, ein Template eingebaut wurde, wird dieses Element auch spezieller verarbeitet. Folgende Anweisungen sollten in XSLT-Stylesheets mit Bedacht verwendet werden. Häufig ist deren Einsatz nicht notwendig und kann durch die Elemente im Push-Verfahren oft problemlos ersetzt werden:
  • xsl:value-of
  • xsl:for-each
  • xsl:if
  • xsl:choose
  • xsl:call-template
Beispielsweise werden xsl:choose und xsl:for-each Anweisungen nur in besonderen Fällen benötigt. In vielen Fällen aber lassen sich diese viel einfacher mittels xsl:template und xsl:apply-templates Anweisungen ersetzen. Dies führt zu einem übersichtlicheren und wartbareren XSLT und entspricht nicht zuletzt der Philosophie von XSLT, wie die Code Snippets 5 und 6 veranschaulichen sollen.
Code-Snippet 5 - Pull-Verfahren
  1 . ItalicRegular
Code-Snippet 6 - Push-Verfahren
  1 . ItalicRegular
Das Ergebnis in beiden Snippets ist identisch. Allerdings wird der Code durch den Einsatz von xsl:choose Anweisungen in Snippet 5 komplexer und trägt nicht zur Verständlichkeit der Logik bei. Die XSLT-Technologie implementiert durch den Einsatz von xsl:template diese Wenn-Dann-Bedingungen implizit. xsl:choose Anweisungen sind deshalb oft unnötig. Meist finden sich an solchen Stellen mehr oder weniger ausführliche Kommentare, welche zur Verständlichkeit des Codes beitragen sollen. Wer aber XPath - Ausdrücke versteht, benötigt im Snippet 6 keine zusätzlichen Kommentare, um die Vorgehensweise und den Code selbst zu verstehen. Hinterfragen Sie also immer vor dem Einsatz der in der obigen Liste aufgeführten Elemente, ob diese unbedingt benötigt werden oder das selbe Ergebnis nicht besser mit xsl:templates erzielt werden kann.

3. Du sollst so allgemein als möglich bleiben

Das allgemeinste Template (auf Elemente bezogen) ist
Code-Snippet 7
  1 . 
Wird kein konkreteres Template definiert, werden alle Elemente über dieses Template abgearbeitet. Um Erweiterungen in der DTD, wenn irgendwie möglich, abzufangen und im Idealfall korrekt zu handeln sollten die Templates so allgemein als möglich gehalten werden. Dies minimiert den Änderungs- und Anpassungsaufwand erheblich. Umso näher man bei der Entwicklung an den Default-Templates bleibt, um so allgemeiner ist also das Template umgesetzt. Am Beispiel von der Verarbeitung von Querverweisen, soll dies etwas näher veranschaulicht werden. Dabei wird vorausgesetzt, dass die eindeutige Regel existiert, dass das Attribut IDReference nur bei Querverweisen zum Einsatz kommt und Querverweise außer durch Ihren Namen auch durch das Vorhandensein dieses Attributs identifiziert werden können.
Code-Snippet 8
  1 . Es folgt ein Querverweisnk IDReference="ABCDE"/>
Code-Snippet 9
  1 . 
Code-Snippet 10
  1 . 
Wird die DTD nun um ein weiteres Element ImageLink erweitert, müsste das Template in Snippet 9 unter ansonsten gleichbleibenden Umständen, entsprechend erweitert werden.
Code-Snippet 11
  1 . 
Bei der Umsetzung mit Code-Snippet 10 ist keine Anpassung des Stylesheets notwendig. Die Erweiterung der DTD hat keine Auswirkungen auf den Publikationsprozess. Natürlich ist diese Aussage etwas theoretischerer Natur, denn das Element ImageLink, bedarf sicherlich noch einer weiteren differenzierteren Verarbeitung. Dennoch soll dieses Beispiel veranschaulichen, dass eine konkretere Angabe eines XPath-Ausdrucks den Pflegeaufwand für das XSLT erhöht. Eine andere Möglichkeit für eine allgemeinere Umsetzung zu sorgen ist, die Templates zu parametrisieren. Die Parametrisierbarkeit von xsl:call-template ist allgemein bekannt und wird - IMHO - teilweise zu viel genutzt. Was viele aber nicht wissen oder zumindest in der Praxis nicht anwenden, ist die Möglichkeit auch xsl:template Anweisungen mittels xsl:param zu parametrisieren. Die Parametrisierung soll an folgendem Beispiel erläutert werden:
Code-Snippet 12
  1 . 
$Condition ist hierbei eine globale Variable, welche als Parameter übergeben wird. Allerdings - wer's gemerkt hat - es wurde noch eine andere Verallgemeinerung eingebaut. Mit der Verwendung von {name()} wird der Name des jeweiligen Elements, auf welches das Template gerade angewendet wird, ausgegeben. Hierdurch kann ein zweites Template vermieden werden, welches sich nur in der Ausgabe eines anderen Elementnamens unterscheidet.
Mehr... (2 Seiten)
veröffentlicht am 04 12 2010
Drucken
Nun ist auch die diesjährige Tekom Jahrestagung 2010 vorbei. Nach den Stimmen zu urteilen war die Veranstaltung in diesem Jahr ein voller Erfolg. Sowohl für die Aussteller als auch für die Besucher der Versanstaltung. Viele interessante Vorträge waren auf der Messe zu hören. Auch ich war, zusammen mit Joachim Endres ILLIG(externer Link) für FCT(externer Link) mit einem Partnervortrag zu einem von mir in der Hauptverantwortung umgesetzten Projekt vertreten. In dem Vortrag haben wir das Projekt hinsichtlich des Variantenmanagements, welches direkt aus der SAP-Auftragskonfiguration heraus angesteuert wird, beleuchtet. Die 12 Maschinenfamilien mit insgesamt 60 Maschinen können kundenspezifisch mit mehr als 8000 verschiedenen Merkmalen kombiniert werden. Für den Vertrieb ergeben sich hieraus bei großen Maschinen mehrere Millionen unterschiedlichen Konfigurationsmöglichkeiten. Und jeden Tag haben die Entwickler neue geniale Ideen, wie sich die Maschinen noch besser vom Markt abheben können. ILLIG selbst hat sich mit der Einführung des Redaktionssystems TIM-RS(externer Link) ein großes Ziel gesetzt. ILLIG möchte nicht nur Maschinenrichtlinien-konforme Dokumentation schreiben sondern zudem jedem Kunden in gedruckter Form oder direkt an der Maschine seine eigene, auf ihn bzw. den Auftrag zugeschnittene Unikat-Dokumentation zur Verfügung stellen. Einmal mehr hat sich in dem Projekt herausgestellt, dass weniger das eingesetzte System sondern das zugrundeliegende Konzept für Modularisierung und Variantensteuerung der ausschlaggebende Punkt für das Gelingen des Projekts waren. Bis auf kleinere notwendige Bugfixes und ohne spezielle Softwareerweiterungen in der Standardsoftware konnte TIM-RS mit kleineren und etwas größeren Konfigurationsanpassungen optimal auf das Lösungskonzept angepasst werden. Natürlich muss das Konzept auch auf die Software abgestimmt sein. Diese Abstimmung der Basislösung auf das System erfolgte aber ohne größere Kompromisse, so dass für ILLIG die optimale Lösung gefunden werden konnte. Im Konzept und in der Umsetzung war dabei ständig der Redakteur im Blick zu behalten. Denn bei dieser enormen Anzahl an Kombinationsmöglichkeiten muss das System so konzipiert sein, dass der Redakteur ständig den Überblick behalten kann. Zur Vereinfachung der Definition des Gültigkeitsbereichs wurde das Konstrukt "Kombi-Merkmale" (Folie 33) eingeführt. Zudem ist es jederzeit möglich zu einem Auftrag eine Übersicht zu generieren (Folie 34), welche in übersichtlicher Weise darstellt, welche Merkmale nicht dokumentiert wurden und welche Inhalte/Module in der finalen Publikation nicht erscheinen würden. Für mich war in diesem Projekt die Verknüpfung von Grafik-Overlays (z.B. Positionsnummern auf der Grafik) mit den variantenabhängigen Inhalten in der jeweiligen Legende besonders spannend (Folien 30 und 31). Die Grafiken werden ohne Positionsangaben in das FrameMaker-Dokument eingefügt. Die Positionsnummern selbst werden, abhängig von der Stelle in der Dokumentation an der die Grafik verwendet wird, mit den FrameMaker-Grafiktools angebracht und gruppiert. Wird in der Legende eine Zeile nicht publiziert, weil die Option durch den Kunden nicht bestellt wird, wird automatisch auch die Positionsnummer auf der Grafik entfernt. Eine kleine Herausforderung stellte dann natürlich die Publikation für die HTML-Online-Hilfe dar, da die Positionsnummern, welche nicht Bestandteil der Grafik sind, ebenfalls im HTML erscheinen müssen. Das Problem löste sich dann aber sehr schnell durch die Verwendung der SVG-Technologie. Im Publikationsprozess wird mit den Informationen der Grafik selbst und den Koordinaten der Grafik auf der Grafik zunächst eine SVG-Grafik erstellt, welche dann wiederrum in das JPG-Format konvertiert wird. Für diejenigen, die den spannenden Vortrag nicht besuchen konnten, habe ich die Vortragsfolien sowie den Beitrag im Tagungsband auf diesen Seiten entsprechend veröffentlicht. Wenn Sie Fragen zu dieser Lösung haben oder nach eigenen Lösungsmöglichkeiten für Ihre Problemstellungen suchen, wenden Sie sich vertrauensvoll an mich.
veröffentlicht am 11 11 2010
Drucken
Heute wurde die Pressemittelung zu "practice innovation mit innovativem ePublishing-Tool an den Start" veröffentlich. Mit dem Konvertierungswerkzeug PIEP-up stellen wir ein Tool bereit, welches mit kleineren Konfigurationsanpassungen (XSLT/CSS) XML-Dateien in das für eBook-Reader, wie eBooks auf iPhone und iPad, geeignete Standard-Format epub(externer Link) transformiert. PIEP-up ist derzeit als Standalone-Applikation verfügbar. Eine Integration in Adobe FrameMaker und in weitere Anwendungsbereiche wie überwachte Dateiordner sowie eine Demoversion für den Download sind für die Zukunft geplant. Bereits bei der Konzeption und dem Design der Anwedung wurde u.a. an eine flexible Erweiterbarkeit dieses Werkzeug, um vor- oder nachgeschaltete Prozesse, zu ermöglichen, gedacht. Beispielsweise wird so eine Anbindung an ein CMS oder die Integration in Adobe FrameMaker sowie die Integration in eine kundenspezifische Systemlandschaft, problemlos möglich.
veröffentlicht am 25 08 2010
Drucken
Seite: 1/2
12