Auf dem ersten Blick haben Extreme Programming (XP) und XML überhaupt nichts miteinander zu tun. XP ist ein leichtgewichtiger OO-Entwicklungsprozess, XML dagegen ein allgemeines Dokumenten-Datenformat. Beide aber haben sich in den letzen Jahren immer größerer Bedeutung erfreut. Allein das sollte Grund genug sein, sich ein Bisschen Gedanken darüber zu machen, ob sie mehr als das "X" gemeinsam haben.
Da XML ja eher schwergewichtig ist, ist es der XP community erstmal suspekt. Um XML als Datenformat zu benutzen, muss man sich normalerweise erstmal Gedanken darüber machen, wie das Format aussehen soll, mit anderen Worten "Big Design Upfront", eine Todsünde für XPler. Das ist auch der Grund, warum XML im reinen XP-Entwicklungsprozess wohl nur sehr begrenzt Einzug halten wird.
Es ist jedoch nicht immer möglich, alle Anforderungen von XP zu erfüllen, und manchmal kombiniert man XP auch mit anderen Entwicklungsprozessen und ist deshalb gezwungen, Kompromisse einzugehen. Die Vorschläge XML im XP-Prozess einzusetzen, zielen entweder in die Richtung den XP-Prozess zu formalisieren oder ihn technisch komplizierter zu machen.
Die Planung von features wird in XP mit CRC Cards durchgeführt. Dies geht solange gut, wie der Kunde - wie von XP gefordert - ständig vor Ort ist. Dies ist aber oft nicht möglich. Wenn man den Kunden aber nicht jederzeit Fragen kann, ist es nötig, die Kommunikation etwas genauer zu koordinieren. Man muss nachvollziehen können, was die Anforderungen sind, und man sollte sie in einer Datenbank speichern können. Bevor man aber den kompletten Entwicklungsprozess formalisiert und in Tools und Datenbanken quetscht - was nach Ansicht von XPlern zeitverschwendung ist - kann man die User Stories auch als XML abspeichern.
XP fordert auch, dass man sich bei der Wahl von Klassen-, Funktions- und Packagenamen an eine selbtgewählte Metapher hält. Wenn sich aber nicht alle Entwickler täglich sehen und zusammen Programmieren, kann es leichter passieren, dass unterschiedliche Namen für das gleiche Konzept verwendet werden. Da könnte ein XML-Glossar aushelfen.
XPler arbeiten sehr nah und fast ausschließlich mit dem Code. Deshalb sind Coding Standards auch sehr wichtig für sie. Aus dem gleichen Grund wie das Glossar kann man also auch die Coding Standards in XML festhalten. Eingeschränkt bieten aber bereits einige IDEs diese Möglichkeit.
XP sieht zwei Arten von Tests vor: Kunden- und Entwicklerseitige Tests. Acceptance Tests sind die ersteren und die Verifizierung der User Stories und sollten deshalb auch vom Kunden spezifiziert werden. Wenn man also die User Stories als XML abspeichert, kann man das auch mit den Akzeptanztests machen und diese in die User Stories einbetten. Wenn man noch einen Schritt weiter in Richtung der schwergewichtigen Prozesse gehen will, kann man auch darüber nachdenken, diese Programmiersprachenunabhängig zu gestalten.
In die gleiche Richtung zielt die Idee, Unittests - die Entwicklertests - sprachenunabhängig zu machen. JXUnit ist eine Implementation dieser Idee. Dem Datum des letzten Releases (18 April 2001) zufolge, ist das Projekt aber nicht weiter verfolgt worden.
Da es, wie erwähnt, oft nicht möglich ist, alle Entwickler und einen Vertreter des Kunden physikalisch Zusammenzuarbeiten zu lassen, kann man sich dafür technische Krücken überlegen. Programme wie NetMeeting eben. Damit hätte man dann Virtual Pair Programming und Virtual On-Site Customer respektive. Als Kommunikationsprotokolle können dabei XML-RPC oder Web Services Verwendung finden.
Das hat aber dann nur noch recht abstrakt etwas mit XML zu tun. Etwas konkreter sind die Ideen, was XP für die Entwicklung von XML-Applikationen tun kann.
So wie XML XP schwergewichtiger macht, soll XP die Entwicklung von XML Applikationen leichter machen. Die Ansätze gehen also in die Richtung den mehrstufigen Prozess von Dokumentendefinition, mit allen eventuell abhängigen Dokumenten zu vereinfachen oder zu automatisieren. Das das nicht für allgemeine oder unternehmenskritische Standards wie WSDL anzuraten ist, ist offensichtlich.
Gemäß dem Motto Do the simplest thing that could possibly work sollte man keine unnötig komplizierten Lösungen für einfache Probleme entwerfen. Und nicht versuchen, zukünftige Anforderungen zu erahnen (You're not gonna need it). Demnach kann es sinnvoll sein, am Anfang des Projektes gar kein XML Format explizit zu definieren. Oft reicht es aus, die Java-Objekte einfach automatisch zu serialisieren. JSX ist ein Beispiel dafür.
Refactoring wird in XP ganz groß geschrieben. Wenn irgendwas nicht gut "aussieht" (when code "smells"), dann sollte man nicht lange zögern, und das Problem bei der Wurzel packen - und die könnte eben auch das XML Datenformat sein. Bei folgendem Abhängigkeitsgraphen kein ganz leichtes Unterfangen:
Eine Java-Applikation liest und schreibt die Daten, Ein Schema validiert diese syntaktisch, Schematron überprüft die "busniness rules" und XForms macht aus dem XML eine GUI. Um alle diese Aspekte gleichzeitig zu ändern braucht man entweder ein integriertes Werkzeug, das alle diese Dateien automatisch generiert oder ändert, oder man muss diese Dateien irgendwie integrieren. Ersteren mögen XPler nicht, weil es dabei nicht um codenahes Programmieren handelt. XVIF probiert sich an der zweiten Möglichkeit.
Auf einem etwas abstrakterem Level betrachtet besteht bei den W3C-Standards auch Refactoring-Bedarf: So etwa sieht der Abhängigkeitsgraph der Core Standards aktuell aus:
Ein großer Teil der Arbeit des W3C besteht deshalb auch in der Vereinfachung dieser Abhängigkeiten.
Seit XSLT haben XML-Dokumente die Komplexität und Funktionalität von Programmiersprachen. Da ist es nur konsequent, das Konzept des Unit testing auf XML und insbesondere XSLT zu übertragen. XSLTUnit ist die Portierung von JUnit. Die Idee von JUnit Ist es, Java-Klassen Methodenweise zu testen. Entsprechen dazu können XSLT Stylesheets template-weise getestet werden. Beim Vergleichen der (XML)-Ausgabe mit einem Muster besteht jedoch das Problem, äquivalente XML-Dokumente zu erkennen. (") ist z.B. meistens gleichbedeutend mit ('). Whitespace zählt meist auch nicht. Um dieses Problem zu lösen, gibt es XML-Vergleicher (z.B. XMLdiff).
XML für XP und XP für XML haben nicht viel gemeinsam. Auch XML und XP haben nicht wirklich viel gemeinsam. Aber sie können - eingeschränkt - voneinander profitieren.
XML macht XP zu einem etwas schwergewichtigeren Prozess, mit all seinen Vor- und Nachteilen. Positiv kann sicherlich die Syntaxvalidierung der XML-kodierten Dokumente, die auch gleich noch via XSLT in andere Formate ungewandelt werden können, angeführt werden. Ob die von Eric van der Vlist vorgeschlagegenen XMLisierungen aber Lösungen für existierende Probleme sind, kann angezweifelt werden: we've found that fancy tools are much more expensive and much less effective than a stack of cards ist einer der Kommentare.
Die konkreten Vorschläge für die Benutzung von XP für XML-Applikationen sind z.T. leider auch Lösungen für Probleme, die es so gar nicht gibt oder einfach noch nicht praxistauglich. Sich das passende aus XP für das eigene Projekt rauszusuchen kann aber sicherlich nicht schaden.