Mit Eclipse Vex XML-Dateien wie mit einer Textverarbeitung editieren

XML ohne spitze Klammern

Holger Voormann

XML ist beliebt. Darüber ist sich zumindest die IT-Branche einig. Aber die Begeisterung bei weniger computeraffinen Menschen hält sich in Grenzen. Das direkte Editieren von XML-Dokumenten meiden sie lieber – man könnte geradezu meinen, sie würden sich an den spitzen Klammern pieksen. Was also, wenn XML-Dateien von Endbenutzern zu editieren sind, aber der Aufwand für die Entwicklung eines Editors sich nicht lohnt?

Hier kommt Vex [1] ins Spiel. Vex steht für „Visual Editor for XML

“ und ist eine Art WYSIWYG-Editor für alle XML-Formate, für die sowohl das Format per DTD als auch die Darstellung mittels CSS definiert sind. Das Einfügen eines neuen XML-Elements ist in Vex genauso einfach wie das Umschalten auf Fett- oder Kursivschrift in einer Textverarbeitung: Cursor an die gewünschte Stelle setzen bzw. den auszuzeichnenden Text selektieren und das einzufügende Element auswählen (Abb. 1), fertig. Zusätzlich zu der angezeigten Start- und Endmarkierung ändert sich die Darstellung wie beispielsweise Schriftgröße und -farbe, Unterstreichung oder Umrandung entsprechend den Vorgaben des Stylesheets. Im Gegensatz zu XML im Quelltext wird der Lesefluss nicht durch Tags gestört, sondern durch die entsprechende Formatierung des ausgezeichneten Texts unterstützt. Im Unterschied zu einem Textverarbeitungsprogramm, das „fett“ und „kursiv“ prinzipiell überall erlaubt, bietet Vex nur die Elemente zum Einfügen an, die an dieser Stelle zugelassen sind.

Abb. 1: Einfügen eines neuen Elements

Wozu ist das gut?

In der technischen Dokumentation sind die Formate DITA und DocBook am verbreitetsten. Ein reichhaltiges Angebot an kommerziellen und freien Konvertierungsmöglichkeiten in verschiedenste Endformate wie HTML und PDF gibt es für beide. Und beide XML-Dialekte können mit Vex direkt editiert werden, entsprechende Stylesheets sind vorkonfiguriert. Zwar liegt Dokumentation in einem Wiki zu erstellen im Trend, aber DITA und DocBook sind stärker strukturiert als Wikiformate. Das Tastaturkürzel STRG + S für Speichern wird in DocBook beispielsweise nicht nur als Text in Kursivschreibweise, sondern als keycombo-Konstrukt aus zwei keycap-Elementen für STRG und S dokumentiert. Das macht zwar das Dokumentieren aufwändiger, bietet aber dafür letztendlich mehr Möglichkeiten. Beispielsweise könnte durch den Abgleich der Liste der dokumentierten Tastaturkürzeln mit den vorhandenen herausgefunden werden, ob alle Tastaturkürzel beschrieben wurden und ob es die dokumentierten Tastaturkürzel auch tatsächlich gibt. Oder, wenn man sich besonders viel Mühe geben will, kann man beim Generieren des Benutzerhandbuchs die Tastaturkürzel durch Abbildungen der entsprechenden Tasten ersetzen.

Aber auch in der Computerlinguistik und den Sprachwissenschaften können WYSIWYG-XML-Editoren bei der Erstellung großer, manuell oder teilweise manuell getaggter Textsammlungen helfen. Diese so genannten Textkorpora dienen dem Validieren, als Trainingsdaten für Parser oder als Datengrundlage für statistische Auswertungen. Mit Korpora können Grammatikregeln, die jeder Fremdsprachenlerner pauken muss, überprüft werden, z. B. ob oder wie weit sie mit der Realität übereinstimmen. Sie helfen bei Fragestellungen, wie beispielsweise der, wie sich gesprochene von geschriebener Sprache unterscheidet, was charakteristisch für einen bestimmten Dialekt oder eine nationale Varietät einer Sprache ist, oder wie sich Sprache im Lauf der Zeit verändert. Der TiGer-Korpus [2] beispielsweise besteht aus 50 000 Zeitungssätzen der Frankfurter Rundschau. Annotiert wurde für jedes einzelne Wort die Wortart und für jeden Satz der Syntaxbaum. Solche Korpora werden zur Entwicklung von Computerprogrammen benötigt, die Wörter in ihrem Zusammenhang verstehen – wie z. B. die Suchmaschine WolframAlpha [3], die in der Lage ist, auf die Anfrage „How old was Michael Jackson when Elvis Presley died?“ nicht wie Google mit einer Liste von Webseiten zu antworten, sondern wie man es von „Data“ vom Raumschiff Enterprise erwarten würde mit „18 Jahre, 11 Monate, 18 Tage“.

[ header = Seite 2: Update und los ]

Update und los

Es gibt noch keine Updatesite für Vex, aber aktuelle Builds können unter [4] heruntergeladen werden und vielleicht bald über den neueren Continuous Integration Server bei Eclipse [5]. Installiert wird Vex, indem das heruntergeladene und ausgepackte ZIP-Archiv in den dropin-Ordner von Eclipse kopiert wird. Zuvor müssen aber Eclipse XML Editors and Tools installiert werden oder man verwendet die Eclipse IDE for Java EE Developers, die alles Notwendige mitbringt.

In RCP-Applikationen, wie die zur Dokumentations- oder Korpuserstellung, kann Vex auf drei verschiedene Weisen integriert werden. Am aufwändigsten ist es, das Vex Widget direkt zu nutzen. Dafür lässt es sich dann aber auch überall einbauen, also auch in Views oder Dialogen. Deutlich einfacher ist es, gleich den Vex-Editor zu verwenden und nur das oder die XML-Formate sowie ihre Darstellung über Extension Points zu registrieren. So sind DITA und DocBook als jeweils ein Daten-Plug-in realisiert, das die entsprechenden DTD- und CSS-Dateien enthält und sie über die entsprechenden Extension Points bekannt machen. Sind die DTD- oder CSS-Dateien ständigen Änderungen unterworfen, bietet sich die dritte Möglichkeit an. Format- und Darstellungsbeschreibungen sind dabei nicht Bestandteil der Entwicklungsumgebung, sondern eines Vex-Plug-in-Projekts.

Bastelstunde

Um Vex besser kennen zu lernen, werden wir im Folgenden selbst eine kleine Anwendung bauen. Wir wollen Kontaktdaten in einem Fließtext aus beispielsweise via OCR eingelesenen, eingescannten Visitenkarten markieren, um daraus per XSLT-Skript ein Adressverzeichnis zu generieren. Denkbar sind aber auch andere Szenarien, in denen vorhandener Text manuell annotiert wird oder hierarchisch strukturierte Daten eingegeben bzw. editiert werden und dann der Text bzw. die Daten automatisiert weiterverarbeitet werden. Beispielsweise könnte man alternativ in einem Rezept die Zutaten annotieren, um daraus die Zutatenliste zu erstellen oder so aus einem Spielbericht Statistiken gewinnen.

Im ersten Schritt ist das Format zu definieren, dann darauf aufbauend die Darstellung per CSS festzulegen. Im dritten und letzten Schritt erfolgt die Registrierung. Entwickeln wollen wir innerhalb eines Vex-Projekts, das wir mit FILE | NEW | OTHER… und dann VEX | VEX PLUG-IN PROJECT anlegen. Wenn wir am Ende zufrieden sind, können wir bei Bedarf daraus immer noch ein Eclipse-Plug-in machen.

<!ELEMENT contacts (card+)> <!ELEMENT card (#PCDATA|first-name|family-name|e-mail|tel)*> <!ELEMENT first-name (#PCDATA)> <!ELEMENT family-name (#PCDATA)> <!ELEMENT e-mail (#PCDATA)> <!ELEMENT tel (#PCDATA)> <!ATTLIST tel comment CDATA #IMPLIED> 

Einfachheitshalber beschränken wir uns bei der DTD-Datei [6] contacts.dtd, die wir direkt im Projektordner erstellen, auf das Allernötigste (Listing 1). Das Wurzelelement contacts kann beliebig viele Visitenkarten, card-Elemente, beinhalten. Eine Visitenkarte kann gemischten Inhalt, also sowohl Elemente als auch Text, besitzen. Semantisch markieren wollen wir den Vornamen (first-name), den Nachnamen (family-name), die Telefonnummer (tel) und die E-Mail-Adresse (e-mail). Firmenname, Anschrift, Webadressen, Funktion und Titel der Person etc. lassen wir außer Acht. Nur bei der Telefonnummer sehen wir ein Kommentarfeld (Attribut comment) für Zusatzinformationen vor, z. B. wann die Person unter dieser Nummer zu erreichen ist.

* {font-family: Arial; color: #000000;} contacts {padding: 8px; background-color: #666688;} card {display: block; margin-bottom: 12px; padding: 8px; color: #999999; background-color: #ffffff; border-style: dotted;} family-name {font-weight: bold} tel, e-mail {color: #000099 font-style: italic;} tel:before {content: " Tel.: "} e-mail:before {content: " E-Mail: "} 

In einer zweiten Datei, die wir unter dem Namen default.css anlegen, definieren wir per CSS [7] das Aussehen (Listing 2). Die erste Überlegung betrifft die Frage, welche Elemente als Blöcke untereinander und welche Elemente im Textfluss darzustellen sind. Da bei uns ausschließlich Visitenkarten untereinander anzuordnen sind, reicht es aus, bei card die Anzeigenart auf display:blockfestzulegen. Bei Farben, Schriftart, Abständen und Rahmen können wir uns richtig ausleben. Nur auf Hintergrundbilder müssen wir leider verzichten, da Vex keine Bilder unterstützt. Dafür kann mit den Pseudoelementen <Element>:before und <Element>:after zusätzlicher Text angezeigt werden, was wir bei Telefonnummern und E-Mail-Adressen nutzen.

<plugin> <extension point="org.eclipse.wst.xml.vex.ui.doctypes" id="contacts" name="Kontakte"> <doctype dtd="contacts.dtd" publicId="-//DTD Contacts//EN" systemId="contacts.dtd"> <rootElement name="contacts"/> </doctype> </extension> <extension point="org.eclipse.wst.xml.vex.ui.styles" id="default-style" name="Standard"> <style css="default.css"> <doctypeRef publicId="-//DTD Contacts//EN"/> </style> </extension> </plugin> 

[ header = Seite 3: Ausblick, Visionen ]

Die beiden Dateien, die wir erstellt haben, registrieren wir nun in der vorhandenen Datei vex-plugin.xml (Listing 3), die sich nur durch ihren Namen und Ort von einer plugin.xml-Datei eines Plug-ins mit Vex-spezifischen Erweiterungen unterscheidet. Da Darstellung und Inhalt voneinander getrennt sind, können mehrere alternative Darstellungsformen für ein Format registriert werden, zwischen denen im Editor umgeschaltet werden kann (DOCUMENT | SYTLE). Die Zuordnung von Stylesheet zu Format erfolgt über das Attribut publicId. Damit Vex beim Öffnen einer XML-Datei weiß, um welches Format es sich handelt, muss in der XML-Datei eine DOCTYPE-Deklaration mit dieser ID vorhanden sein. Die beiden id-Attribute sind nur für interne Zwecke bestimmt, wogegen die beim Erstellen eines neuen Dokuments bzw. die beim Umschalten der Darstellung angezeigten Bezeichner im entsprechenden name-Attribut angegeben werden. Mit dem Speichern von vex-plugin.xml sind das Format und das Stylesheet registriert.

Neue Dokumente können nun mit FILE | NEW | DOCUMENT erstellt werden. Weil .xml-Dateien standardmäßig nicht mit Vex, sondern mit dem normalen XML-Editor geöffnet werden, sind sie das erste Mal explizit mit Vex zu öffnen (Rechtsklick auf die Datei: OPEN WITH | VEX XML EDITOR). Text lässt sich wie bei jedem Texteditor eingeben, und weil das card-Element ein block-Element ist, wird bei einem Zeilenvorschub oder bei RETURN automatisch ein neues card-Element erzeugt. Neue Elemente lassen sich an der Cursor-Position oder um selektierten Text über einen Dialog erstellen, der zwar etwas anders aussieht als die in Eclipse weitverbreiteten Dialoge zur Codevervollständigung, aber genauso funktioniert und über die gewohnte Tastenkombination STRG + LEERTASTE zu erreichen ist. Befindet sich der Cursor innerhalb des Elements oder ist das Element selektiert, so können die Attributwerte in der PROPERTIES-View editiert werden. Bei uns ist das nur beim tel-Element der Fall, alle anderen Elemente haben keine Attribute.

In dem Beispielprojekt (das hier zum Download bereit steht) (zu importieren mit FILE | IMPORT… | GENERAL | EXISTING PROJECTS INTO WORKSPACE und dann die ZIP-Datei bei SELECT ARCHIVE FILE auswählen) ist ein Ant- und XSLT-Skript (auszuführen über RUN | EXTERNAL TOOLS | EXTERNAL TOOLS CONFIGURATIONS…) zum Erstellen einer Adressliste im HTML-Format enthalten.

Ausblick

Vex erblickte bereits 2002 bei SourceForge [8] das Licht der freien Softwarewelt. Nach einem Jahr intensiver Entwicklung nahmen die Aktivitäten um Vex ab. Erst 2008 endete der Dornröschenschlaf, wachgeküsst von David Carver, der Vex mit auf sein Schloss, Eclipse Web Tools Incubator, nahm. Dave tauschte das interne Modell gegen ein EMF-basiertes aus, wodurch es kompatibel zu dem herkömmlichen Eclipse-XML-Editor wurde, und realisierte so einen Multipage-Editor aus Quelltext-XML-Editor und Vex. Zukünftig soll Vex die XML-spezifischen Funktionen des „normalen“ XML-Editors nutzen, um Nachimplementierungen zu vermeiden. Durch das gemeinsame Modell steht auch der Nutzung von XML Schema und vielleicht bald sogar von RELAX NG nichts mehr im Weg.

Aber natürlich hat eine so große Veränderung wie der Austausch des Unterbaus sowie die lange Zeit der Inaktivität auch Spuren hinterlassen. Die Stabilisierung steht auf der To-do-Liste ganz oben, vom veralteten Action-Framework wurde bereits auf das neue Command-Framework umgestellt. Damit nicht pauschal alle .xml-Dateien mit dem Vex-Editor geöffnet werden, müsste die Zuordnung nicht anhand der Dateinamenserweiterung, sondern, wie es beispielsweise beim Plug-in-Editor der Fall ist, anhand des Inhalts erfolgen, genauer gesagt anhand der bei Vex registrierten Public ID. Weit oben stehen auf der Wunschliste außerdem noch die Darstellung von Bildern und Verweisen sowie das Verschieben von XML-Fragmenten per Drag and Drop.

Visionen

Styling mit CSS liegt im Trend – wie auch das Eclipse von Morgen, das e4-Projekt, zeigt. Und noch etwas hat Vex mit e4 gemeinsam: das EMF-basierte Modell. Mit ihm ist der Weg in die boomende Modellierungswelt geebnet. Beispielsweise könnte Xtext [9] aus der gegebenen Grammatik anstatt eines einfachen Texteditors mit Syntax-Highlighting einen Vex-Editor erzeugen. Wie beim Meta Programming System [10] von JetBrains wäre damit das Editieren direkt im Syntaxbaum möglich und das ständige Parsen anhand einer komplexen Grammatik würde entfallen.

Auch beim Modellieren von Geschäftsprozessen, Business Process Modeling, wird auf strukturierte, typisierte und vernetzte Daten gesetzt. Gängig ist hier immer noch, dass Berichtswesen und Eingabe zweierlei sind. Vex könnte Eingabe und Ausgabe vereinen und so ein intuitiveres Bearbeiten ermöglichen. Auch bei Javadoc oder WikiText [11] könnte Vex als WYSIWYG-Editor das direkte Editieren ermöglichen und die Bedienbarkeit verbessern. Und ganz nebenbei bemerkt: Automatischen Zeilenumbruch beherrscht Vex im Gegensatz zu allen anderen Eclipse-Texteditoren [12] seit jeher.

Vex macht das Editieren von XML einfach. Vielleicht zu einfach, als dass „echte“ Programmierer es interessant genug fänden. Für sie muss „richtiges“ XML spitze Klammern haben und mit Texteditoren bearbeitet werden, in denen jedes Zeichen genau gleich breit ist. Möglicherweise war das mit einer der Gründe, wieso es die letzten Jahre um Vex so still geworden ist. Bei Eclipse genießt Vex wieder mehr Aufmerksamkeit, und das EMF-basierte Modell erweitert die Einsatz- und Kombinationsmöglichkeiten von Vex in bzw. mit anderen Projekten, Produkten und Ideen auch abseits technischer Dokumentation.

Geschrieben von
Holger Voormann
Holger Voormann
Holger Voormann: irgendwas mit Eclipse; früher festangestellt, seit 2010 freiberuflich; Eclipse Vex (a Visual Editor for XML) Committer, aber länger inaktiv; dafür kleinere Code-Beiträge für die Eclipse-Plattform, aber nicht als Committer; bloggt unregelmäßig (eclipsehowl.wordpress.com); antwortet nicht immer auf E-Mails (eclipse@voormann.de) und auf Tweets (@howlger)
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.