Technische Dokumentation – Version 1.0


1  Konzepte & Methoden

Die Konzeption von XIPA setzt auf die Entwicklung in Anlehnung an Standards und Empfehlungen des „World Wide Web Consortium“ (W3C), um eine langfristige Verwendbarkeit des Projektes durch die Nutzung zukunftstauglicher, nachhaltiger Technologien zu garantieren. Die Verwendung offener Standards sichert dabei die Wiederverwendbarkeit der Daten und die Austauschbarkeit der Daten über Plattformen hinweg.

Die Grundstruktur von XIPA beruht auf XML-basierten Datenformaten (XML, XSLT und SVG). Der Vorteil XML-basierter Daten liegt in der Möglichkeit einer verständlichen (logischen) Auszeichnung der Elemente sowie einer klaren Trennbarkeit von Form und Inhalt. Durch die Textform der Daten ist zur Bearbeitung der Dateien lediglich ein einfacher Texteditor notwendig.

Die interaktiven Elemente („Event-Handler“, z.B. zur Übertragung der Zeichen in das Textfeld, zur Ausgabe der Audiodateien und zur Anzeige des Tooltips) sind mit JavaScript realisiert. Einige Funktionen nutzen Methoden der JavaScript-Bibliothek jQuery. Alle verwendeten Technologien sind in aktuelle Browser implementiert.

Die Möglichkeit einer klaren Trennung von Inhalt und Form erlaubt es, dass Inhalte und Darstellungsoptionen unabhängig voneinander bearbeitet werden können. Sie ist damit eine wichtige Voraussetzung für die Weiterverarbeitung der Daten wie beispielsweise die Nutzung der gesammelten Informationen zu den phonetischen Zeichen in anderen Projekten oder die Auswertung mit anderen Werkzeugen.

1.1  XML-Daten

Als Ausgangspunkt für die Zusammenstellung der einzelnen phonetischen Zeichen und der dazugehörigen Informationen wurde das Datenformat XML (Extensible Markup Language) gewählt. Den Kern des Projekts bildet eine ca. 5000 Zeilen Code umfassende XML-Datei.

Da XML – im Gegensatz zu HTML – keine festgelegte Liste von Auszeichnungselementen (Tags) zur Auszeichnung der Daten vorschreibt, ist eine Strukturierung der Daten durch selbstbenannte Tags möglich. Durch die Verwendung eines selbsterklärenden Markups wird die Lesbarkeit und Weiterverarbeitbarkeit der Daten erheblich erleichtert.

Allerdings enthält XML selbst keine Hinweise darüber, wie die Daten in einem Browser zu interpretieren sind. Die reine XML-Datei wird vom Browser lediglich als Baumstruktur – Quellcode mit Einrückung und farblicher Markierung – dargestellt. Um die Daten zu formatieren (d.h. in einer brauchbaren Form auszugeben) wird ein Stylesheet benötigt. Die Ausgabe kann entweder durch ein CSS-Stylesheet realisiert werden – sofern sich die Daten schon in einer geeigneten Reihenfolge befinden – oder durch ein XML-basiertes Stylesheet (z.B. eine XSL-Transformation durch ein XSLT-Stylesheet).

1.2  XSL-Transformation (XSLT)

XSLT dient der Umwandlung eines XML-Dokuments in ein anderes (XML-)Format. XSLT baut auf der abstrakten, durch das Markup repräsentierten Struktur des Quelldokuments auf, die einer Baumstruktur aus Knoten entspricht (siehe XPath). In XIPA wird das XML-Dokument mittels XSLT (Version 1.0) in das XML-konforme Format XHMTL konvertiert, d.h. in XML-gerechtes, vom Browser darstellbares HTML umgewandelt.

Das XSL-Stylesheet definiert dabei die Regeln, nach welchen die Baumstruktur des Quelldokuments in den Ergebnisbaum transformiert wird. Die Transformation bietet die Möglichkeit, Daten aus dem Quelldokument gezielt auszuwählen, die Inhalte einzelner Elemente zu kombinieren oder zu manipulieren und damit das resultierende Ergebnisdokument (bzw. dessen Formatierung und Gestaltung) an die gegebenen Bedürfnisse anzupassen.

Theoretisch kann die XSLT-Datei alle zur Ausgabe der HTML-Datei notwendigen Formatierungsangaben und alle Elemente zur optischen Gestaltung beinhalten. Um die Flexibilität zu erhalten, sollten Logik, Darstellung und Daten allerdings soweit wie möglich voneinander getrennt bleiben. Aus diesem Grund konzentriert sich die für XIPA generierte XSLT-Datei auf die Organisation der Elemente in Gruppen, auf die zur Formatierung HTML-Datei notwendigen Angaben und auf die Anreicherung der Elemente mit den für die Benutzerinteraktion notwendigen Attribut-Wert-Paaren.

1.3  XSL- und CSS-Stylesheets

Um Logik, Darstellung und Daten soweit wie möglich voneinander zu trennen, enthält die XSL-Datei möglichst wenig Gestaltungselemente. Lediglich einige Breitenangaben diverser Tabellenzellen sind in den einzelnen Templates hinterlegt. Die Ausgabe besteht also aus einem Dokument, dessen Formatierung bereits nahezu der endgültigen Darstellungsform entspricht. Die finale visuelle Gestaltung ist in XIPA in zwei weitere Dateien ausgegliedert – eine aus „Attribut-Sets“ bestehende XSL-Datei und eine CSS-Datei.

Innerhalb der XSL-Datei sind diverse „Attribut-Sets“ hinterlegt, die aus den einzelnen Template-Aufrufen des XSL-Stylesheets heraus aufgerufen werden. Die Attribut-Sets bestehen z.B. aus Angaben zu Rahmenlinien (für verbundene Zellenreihen), aus Breitenangaben für unterschiedliche Tabellenblöcke und weiteren „Style“-Elementen. Die Inhalte der innerhalb der Sets definierten Attribute (z.B. „style“ oder „colspan“) entsprechen der Notationsweise von CSS-Anweisungen. Sie bieten sich an denjenigen Stellen an, an welchen Attribut-Gruppen mehrmals wiederholt eingesetzt werden sollen, ohne dafür zusätzliche – durch CSS-Selektoren „ansprechbare“ – Attribute verwenden zu müssen.

Durch die Verwendung der XSL-Attribut-Sets sind nur noch wenige Elemente übrig, die separat mit (Styling-)Angaben versehen werden müssen. Diese letzten Angaben sind in eine CSS-Datei ausgelagert, die das grundsätzliche Aussehen der Grundelemente bestimmt und das finale Rendering im Browser bestimmt.

Innerhalb der CSS-Datei sind beispielsweise die Hintergrundfarbe von Tabellenzellen der Klasse „imp“ angegeben (um Laute die als nicht produzierbar klassifiziert sind hervorzuheben), das Verhalten bei Mausbewegungen über Symbole festgelegt (z.B Änderung des Mauszeigers beim Bewegen über „aktive“ Bereiche), sowie einige Angaben zur Ausgestaltung der Vektorgrafik und zum Erscheinungsbild des Tooltips gespeichert.

1.4  XPath (Navigation im XML-Strukturbaum)

XPath ist eine Sprache zur Adressierung von Teilen eines XML-Dokuments, die auf der abstrakten, logischen Struktur eines XML-Dokuments operiert. XPath-Ausdrücke verwenden eine Pfad-Notation, die es erlaubt durch die Knoten der hierarchischen Baumstruktur eines XML-Dokuments zu navigieren und Knoten mit bestimmten Eigenschaften und Werten aufzufinden und auszuwählen. Dabei kann unter anderem auf Elementknoten, Attributknoten oder Textknoten zugegriffen werden.

Die XPath-Syntax wird in XSLT-Dokumenten für die Auswahl von Knotenmengen durch den Vergleich mit einem bestimmten Muster (z.B. alle Elemente mit dem Attribut ’vowel’) verwendet. Durch geeignete Formulierung der XPath-Ausdrücke in den XSLT-Anweisungen „select“, „match“ und „test“ und die Kombination mit Operatoren (and, or, !, etc.) können die gewünschten Elemente oder Werte gesucht und die Ergebnisse als Zeichenkette zurückgegeben werden. Neben der Identifikation der zu bearbeitenden Teile eines Eingabedokuments, ist XPath auch für numerische Kalkulationen und die Manipulation von Strings geeignet.

In XIPA werden XPath-Ausdrücke genutzt, um die Elemente einer bestimmten Gruppe (z.B. alle Suprasegmentalia) aufzufinden und innerhalb der Tabelle in welcher das XSL-Template aufgerufen wurde zu verteilen. In einem weiteren Schritt werden für jedes Element die für die Anzeige relevanten Informationen extrahiert und in die entsprechenden Tabellenzellen eingetragen (Unicode-Zeichen, Beschreibung des Zeichens und – sofern verfügbar – ein Beispiel). Durch ein weiteres Template werden die zeichenspezifischen Meta-Informationen generiert, die den Tabellenzellen in Form von Attribut-Wert-Paaren angehängt werden. Diese Informationen bilden die Grundlage für die Benutzerinteraktion und die interaktiven Elemente die in XIPA mithilfe von JavaScript implementiert sind.

1.5  Ausgabe (Client-seitige XSL-Transformation und XHTML)

Die Ausgabe der transformierten XML-Datei erfolgt im XML-basierten Format XHTML. Dieses Format muss den hohen Ansprüchen an XML-Dateien genügen. Demnach muss das Dokument wohlgeformt sein, d.h. es muss die Regeln der XML-Syntax einhalten, damit ein Parser problemlos mit dem Code umgehen kann. Weiterhin muss das Dokument valide (gültig) sein, d.h. die Syntax der verwendeten Elemente muss den Regeln und Standards des XML-Formats entsprechend eingesetzt werden (dies betrifft unter anderem die richtige Verwendung von Klammern, Elementverschachtelungen, sowie die Benennung von Tags und Attributen etc.).

Die strikte Formulierung in der Syntax und Semantik von XML bietet einige Vorteile. So ist die Kompatibilität mit älteren Browsern größtenteils gegeben, da diese das XHTML meist als einfaches HTML verarbeiten können. Weiterhin besteht in XHTML die Möglichkeit, Elemente aus anderen XML-basierten Sprachen direkt einzubetten. In XIPA bildet diese Möglichkeit die Grundlage, um die SVG-Grafik des Vokaltrapezes innerhalb der Transformation zu erstellen und um die Grafik unkompliziert mit den gleichen interaktiven Elementen wie den Rest der Seite bereitzustellen. Eine gewisse Zukunftssicherheit besteht unter anderem durch die Maschinenlesbarkeit des XHTML-Formats, die es ermöglicht, Abweichungen oder Besonderheiten neuer Spezifikationen durch zusätzliche Stylesheets abzubilden und die Dokumente relativ einfach in das neue Format zu konvertieren.

Da die meisten modernen Browser einen XSLT-Prozessor bereitstellen, wurde sich dafür entschieden, die Transformation der XML-Datei vollständig auf den Client (d.h. das ausführende Gerät) auszulagern. Die Vorteile dieser Verfahrensweise liegen einerseits darin die Serverlast zu minimieren, das Potenzial aktueller Hardware zu nutzen und die Leistungsfähigkeit moderner Browser voll auszuschöpfen. Die Auslagerung auf den Client ist anderseits die Grundlage für die Nutzbarkeit des Tools im Offline-Modus und sichert die Funktionalität der Transkriptionsumgebung bei schwankender Leistung und Übertragungsgeschwindigkeit des Webservers.

1.6  JavaScript

Die interaktiven Elemente sind mit JavaScript realisiert. Für die Wahl von JavaScript sind sowohl die hohe Verbreitung von JavaScript-Interpretern in aktuellen Webbrowsern, als auch eine größere „Wartungsfreundlichkeit“ der Skripte ausschlaggebend1. Die Skripte sind in drei Dateien unterteilt. Um eine vereinfachte Nutzung der JavaScript Event-Handler zu ermöglichen, ist zusätzlich die JavaScript-Bibliothek jQuery eingebunden.

Die Entwicklung der JavaScript-Dateien wird in diesem Handbuch nur gestreift, da abzusehen ist, dass die Anpassung der Skripte den größten Veränderungen unterliegen wird. Im Folgenden wird die elementare Funktionsweise und Einbettung der Skripte unter der Angabe von Referenzen kurz erläutert.

1.6.1  JavaScript-Skripte

tooltip.js

Das JavaScript-Tooltip zur Anzeige der zusätzlichen Zeicheninformationen beim „Berühren“ der Zeichen mit der Maus basiert auf einer lizenzfreien Vorlage von Michael Leigeber. Die grundlegende Funktionsweise ist im Tutorial „Create a Nice, Lightweight JavaScript Tooltip“ erläutert.

Um die Funktionalität des Skripts an XIPA anzupassen, wurde der Code an einigen Stellen modifiziert. Die Veränderungen betreffen unter anderem:

Die im Tooltip anzuzeigenden Informationen (z.B. Symbolname, Kardinalzahl, Unicode-Zeichen etc.) sind in der Funktion toggleTooltip im Skript onclickSwitcher.js definiert.

onclickSwitcher.js

Das Skript onclickSwitcher.js ist in erster Linie für den Wechsel zwischen Transkriptions- und Audioausgabemodus zuständig. Die für den Wechsel zwischen den Modi zuständigen Funktionen switchToAudio und switchToTranscription legen das Verhalten der Onclick-Handler für den jeweiligen Modus fest. Die Funktion toggleTooltip bestimmt, welche Informationen bei der Einblendung des Tooltips angezeigt werden sollen.

Das Skript bedient sich an jenen Informationen, die in den Metadaten der „klickbaren“ Elemente hinterlegt sind. Diese bestehen aus einer Reihe von Attribut-Wert-Paaren (z.B. Symbolname, Unicode-Kode, Zeichenkodes für die unterschiedlichen Transkriptionsmethoden, dem Pfad zur Audiodatei etc.). Der Zugriff auf die Elemente (bzw. die Ausgabe der Attributwerte) erfolgt dabei über die verkürzte Schreibweise der jQuery-Methode .attr(Attributname).

Im Abspielmodus (switchToAudio) wird die entsprechende Audiodatei durch Auslesen der Pfadangabe im Attribut data-sound geladen und mittels XMLHttpRequest angefragt. Sofern die entsprechende Audiodatei im Verzeichnis vorhanden ist, wird diese in den zu Beginn der Skript-Datei definierten Audio-Kontext eingehängt und abgespielt (siehe Abschnitt 1.6.2 Web-Audio-API).

Beim Wechsel in den Transkriptionsmodus (switchToTranscription) wird der Wert der im Dropdown-Menü eingestellten Ausgabemethode (Unicode, TeX etc.) ausgelesen. In Abhängigkeit von der gewählten Transkriptionsmethode werden die entsprechenden Attributwerte – also die Kodes für Unicode, Unicode-Entities, LATEX- oder Praat-Notation – mit dem Onklick-Handler verknüpft. Sobald ein Element geklickt wird, wird der Wert zur weiteren Verarbeitung an die Funktion insertAtCursor im gleichnamigen Skript weitergegeben.

insertAtCursor.js

Im Skript insertAtCursor.js ist die Funktion insertAtCursor definiert. Diese ist für das Einfügen des Zeichens (bzw. die Ausgabe des Kodes) an der aktuellen Cursorposition im Textfeld zuständig. Das Skript bietet die Möglichkeit, Zeichen und Diakritika per Mausklick in das Textfeld zu übertragen. Bei aktivem (schwarz hinterlegtem) Textfeld kann die Cursorposition zwischen den Eingaben mit den Pfeiltasten oder der Maus verändert werden. Die zuletzt gewählte Position des Cursors bleibt auch erhalten, wenn das Textfeld durch einen Mausklick auf einen der inaktiven Bereiche der Seite oder einen Wechsel zwischen Transkriptions- und Abspielmodus im passiven Zustand ist.

Das Skript basiert auf einer Vorlage von Torsten Anacker. Die Grundzüge der Funktionsweise des Skripts sind im Artikel „Formulare: Text an Cursorposition einfügen“ erläutert. An einigen Stellen ist das Skript gekürzt und an die gegebenen Anforderungen angepasst.

1.6.2  Web Audio API

Die Web Audio API ist eine Programmierschnittstelle zur Verarbeitung, Wiedergabe und Manipulation von Audiodateien in Web-Anwendungen, die das direkte Laden und Weiterverarbeiten von Audiodateien per JavaScript in Web-Anwendungen ermöglicht. Die Nutzung der Web Audio API ist ohne die Installation zusätzlicher Plug-ins möglich und bietet einige Funktionen, die über die grundlegenden Abspielfunktionen des HTML5 audio-Elements hinausgehen. Neben der reinen Wiedergabe- bzw. Abspielfunktion werden unter anderem die Visualisierung von Audio-Rohdaten, die Synthese von Klängen (durch Oszillatoren) und die Manipulation der Wiedergabe (durch diverse Filter) unterstützt. Im folgenden Verlauf sind die für XIPA relevanten Eigenschaften der Wiedergabefunktion der Web Audio API kurz skizziert.

Um die auf dem Server oder der Festplatte gespeicherten Audiodateien abspielen zu können, muss in erster Instanz ein AudioContext bereitgestellt werden. In diesen Kontext können mehrere Objekte eingehängt werden, die in Form von AudioNode-Objekten repräsentiert werden. Der Aufruf des Audio Kontexts und die Wiedergabefunktion (switchToAudio) sind im Skript onclickSwitcher abgelegt.

Die Quelle (d.h. die beim Mausklick auf einen der Laute abzuspielende Datei), wird im Skript mittels XMLHttpRequest geladen. Dazu wird der im data-sound-Attribut hinterlegte Pfad über die Variable filename ermittelt. Wenn die Quelldatei existiert, wird dem AudioContext die Methode createBufferSource() zugewiesen – sollte die Datei nicht gefunden werden, wird die Anfrage mit einer Fehlermeldung quittiert. Beim Laden der Audiodatei wird die Methode decodeAudioData() des AudioContext aufgerufen, um die betreffende Audiodatei zu dekodieren. Im weiteren Verlauf wird die Audiodatei in den Puffer geladen und abgespielt.

Obwohl die Web Audio API von den meisten aktuellen Browsern unterstützt wird, bestehen hinsichtlich der Umsetzung in den verschiedenen Browsern einige Unterschiede. Es ist zu erwarten, dass diese sich im Laufe der Entwicklung der W3C Empfehlung an einen Quasi-Standard angleichen werden.

1Theoretisch wäre eine vollständige Implementierung der interaktiven Elemente in XQuery denkbar (W3C-Empfehlung einer Abfragesprache für XML-Daten). Auf diese Lösung wurde aufgrund der mangelnden (nativen) Browserunterstützung und der geringen Verbreitung von XQuery (und damit auch einer beschränkten Auswahl an Informationsquellen) verzichtet.