Goodbye XML – Befreiungsakt mit Xtext

Es zeigt sich abermals, dass eine Sprache, die genau einen Problembereich adressiert und im Erscheinungsbild möglichst frei von syntaktischen Einschränkungen ist, deutlich leichter geschrieben und vor allem gelesen und verstanden werden kann. Wenn bei der Entwicklung der Sprache auch noch ein moderner Editor für die spezialisierte DSL mitgeliefert wird und mächtige Tools für die Weiterverarbeitung der Daten bereitstehen, gibt es kaum noch einen Grund, auf XML zu setzen.

Die Sonnenseiten von XML

XML ist natürlich nicht in jeder Situation eine schlechte Wahl. Die Faustregel, kein XML zu verwenden, sobald Menschen diese Dateien lesen oder editieren müssen, passt im Prinzip schon ganz gut. Wir möchten aber fairerweise zwei Eigenschaften nennen, die XML durchaus attraktiv machen können:

  1. XSD wird interpretiert: Mit Xtext müssen Sie nach einer Änderung in der Grammatik die Implementierung des Parsers neu generieren und auch den Editor neu deployen bzw. die Testumgebung neu starten. Bei der Entwicklung sind die Turnaround-Zeiten mittlerweile wirklich nahe an einem interpretativen Modus – aber eben nicht ganz. Ohne Neustart oder erneute Kompilierung die Sprache zu verändern, hat gerade in der Prototypphase durchaus seinen Reiz.
  2. XML Parser gibt es für jede Plattform: Xtext generiert eine Implementierung für die JVM, d. h. solange Sie eine Sprache nutzen, die auf der JVM ausgeführt wird, gibt es kein Problem. Wenn Sie allerdings in C, C++ oder auf der .NET-Plattform Modelle einer Xtext-Sprache laden möchten, sieht es nicht gut für Sie aus.

Falls Sie einen dieser Punkte für sich als entscheidendes Kriterium ansehen, sollten Sie vielleicht auch noch andere Alternativen wie JSON [6] oder YAML [7] in Betracht ziehen.

Es ist nie zu spät

Sofern man in einem Softwareprojekt einen proprietären XML-Dialekt verwendet, ist man natürlich nicht automatisch dazu verdammt, auf immer und ewig daran festzuhalten. Auch eine sukzessive Ablösung und Umstellung auf ein Xtext-basiertes Format ist möglich. Gerade die Verwendung des Eclipse Modeling Framework erweist sich dabei wieder als sehr hilfreich. Um mit Xtext herumzuspielen, ohne ein völlig synthetisches Szenario umzusetzen, kann beispielsweise mit EMF-Bordmitteln aus einem existierenden XML Schema ein korrespondierendes Ecore-Modell abgeleitet werden. Dabei werden die Konzepte und Typen aus dem Schema nach EMF übersetzt, und nachdem der EMF-Generator mit diesem Ecore-Modell konfiguriert und ausgeführt wurde, entsteht im Grunde ein typsicheres API genau für das eigene Schema.

Seit Version 1.0 erlaubt es Xtext, aus einem bestehenden Ecore-Modell wiederum eine initiale Grammatik abzuleiten. Sie enthält einfach eine Regel für jedes Konzept aus dem Ecore-Modell. Damit wird schon einmal eine gute Ausgangslage geschaffen, die eine Analyse nahe am echten Projektszenario zulässt. Von hier aus ist es kinderleicht, die automatisch erzeugte Grammatik nach und nach abzuspecken, an die eigenen Vorstellungen anzupassen und dabei stets inhaltlich kompatibel zu dem ursprünglichen XML-Format zu bleiben.

Im Grunde wird dadurch einfach eine alternative Syntax für das existierende Schema erzeugt. In beiden Formaten können jetzt gleichwertige Informationen abgelegt werden. EMF erlaubt es anschließend mit wenigen Zeilen Code, das XML nach Xtext zu übersetzen und umgekehrt. Ersten Experimenten mit der Technologie steht also nichts im Weg. Und da die beiden Syntaxen ineinander überführt werden können, stehen natürlich ausgehend von beiden Richtungen die gleichen Möglichkeiten für die Weiterverarbeitung des initialisierten Modells zur Verfügung. Wenn man also Xpand oder andere EMF-Technologien sowohl mit Xtext-basierten als auch gleichzeitig mit den existierenden XML-Modellen verwenden möchte, ist dies problemlos möglich – und sobald man von der Technologie überzeugt ist, können auf diesem Weg Schritt für Schritt alle alten Dateien abgelöst werden.

Spätestens nach den ersten eigenen Gehversuchen mit Xtext sollte auch den letzten Zweiflern deutlich werden, wie einfach das Bauen einer eigenen Sprache von der Hand geht. Freilich soll hier nichts verschönert werden: Es ist nicht trivial, eine vollständige Programmiersprache wie Java mit Xtext umzusetzen (aber mit Hexenwerk hat auch das nichts zu tun). Doch gerade, wenn es um statische Daten geht, wie sie in der Vergangenheit üblicherweise mit XML erfasst wurden, können mit Xtext schon nach sehr kurzer Zeit beachtliche Erfolge erzielt werden – und wer einmal mit EMF-basierten Modellen anstelle von Java Beans gearbeitet hat, wird auch dieses Framework nicht mehr missen wollen.

Sebastian Zarnekow ist Softwarearchitekt und Berater bei itemis. Er entwickelt Frameworks und Tools, um die modellgetriebene Softwareentwicklung zu verbessern und die Produktivität zu steigern. Sebastian ist Committer im Eclipse Modeling Project.

Sven Efftinge ist bei der itemis AG (http://www.itemis.de) beschäftigt und maßgeblich für die Weiterentwicklung von Methoden und Werkzeugen für die modellgetriebene Softwareentwicklung verantwortlich. Er ist Mitglied des Eclipse Modeling PMC und leitet die Entwicklung des TMF-Xtext-Frameworks. Er spricht regelmäßig auf Softwarekonferenzen und ist Koautor des Buchs „Modellgetriebene Softwareentwicklung“ (dpunkt).
Kommentare

Schreibe einen Kommentar

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