Es ist schwierig, Technologien zu bewerten, wenn Sie keine tiefgreifende Erfahrung mit ihnen haben, aber natürlich müssen Sie genau dann Ihre Entscheidungen treffen, sodass es keine einfache Antwort auf dieses Dilemma gibt.
Sie führen zwei Bedenken an: Leistung und Benutzerfreundlichkeit. Ich werde versuchen, beide unten zu adressieren.
Erstens Leistung. Die Leistung hängt natürlich nicht nur von der Sprache, sondern auch von der Implementierung und dem Fachwissen der Benutzer ab. Verschiedene XSLT-Prozessoren können sich in der Leistung stark unterscheiden, und der gleiche Prozessor kann sich in Abhängigkeit von seiner Verwendung stark unterscheiden (bei Saxon zum Beispiel wird sehr häufig festgestellt, dass Menschen mit Leistungsproblemen ihn mit DOM verwenden, was eine schlechte Kombination ist , und die Leistung kann sich verzehnfachen, wenn Sie stattdessen das native Baummodell von Saxon verwenden. Der erste Ratschlag ist also, nicht das Hörensagen zu messen. und der zweite Rat ist, sicherzustellen, dass die Person, die die Messung durchführt, über genügend Erfahrung verfügt, um keine dummen Fehler zu machen. Leichter gesagt als getan.
Grob gesagt können Sie Transformationsjobs in zwei Kategorien unterteilen: einfach und komplex. Für einfache Transformationen ist mit einem guten XSLT-Prozessor nur das Parsen und Serialisieren erforderlich, und die XSLT-Verarbeitungszeit kommt kaum ins Spiel. Da bei jeder anderen Technologie die gleichen Kosten für Parsing und Serialisierung anfallen, wird die Wahl der Transformationstechnologie keinen großen Unterschied machen (außer vielleicht sehr für sehr einfache Codierung mit Streaming, aber nicht viele Leute können sich die Programmierung leisten Zeit und Fähigkeiten, um dies umzusetzen). Bei komplexen Transformationen großer Dokumente treten die gleichen Probleme auf wie bei der SQL-Programmierung: Um eine gute Leistung zu erzielen, ist eine gute Interaktion zwischen den Fähigkeiten und Kenntnissen des Programmierers und den Fähigkeiten des Optimierers erforderlich. Wie bei SQL ist es Es ist sehr einfach, in solch einer Hochsprache ein paar einfache Anweisungen zu schreiben, die dazu führen, dass der Prozessor sehr viel Arbeit erledigen muss. Aber auch wie bei SQL können Programmierer, die wissen, was sie tun, viel besser als Anfänger.
Zweitens Benutzerfreundlichkeit. Die XML-basierte Syntax für XSLT ist für viele Menschen sehr abstoßend, wenn sie zum ersten Mal mit der Sprache in Berührung kommen. Dafür gibt es gute Gründe und echte Vorteile: Es gibt das Argument "template", dass ein Großteil des Codes aus XML besteht, das in das Ergebnisdokument geschrieben werden soll, und dass XML am besten in XML geschrieben wird. Und da ist das Argument "Reflektion"; In großen komplexen Systemen werden häufig Stylesheets gefunden, die Stylesheets generieren. Dann gibt es das Argument "Werkzeuge"; Wenn Sie sich in einem XML-Shop befinden, verfügen Sie wahrscheinlich über viele XML-Tools, z. B. syntaktisch gesteuerte Editoren, und es ist gut, dieselben Tools für die Verwaltung Ihrer Programme und Daten zu verwenden. Die Nachteile erweisen sich im Vergleich als ziemlich kosmetisch: s Die Anzahl der Tastenanschläge bei der Bearbeitung (leicht mit einem guten Bearbeitungswerkzeug zu beheben) und die Ausführlichkeit des Codes (die Lesbarkeit wird verringert). Die Ausführlichkeit wird in XSLT 2.0 durch die Einführung von Funktionen wie regulären Ausdrücken und Stylesheet-Funktionen erheblich reduziert: Viele Stylesheets werden auf die Hälfte oder ein Drittel verkleinert, wenn sie XSLT 2.0 voll ausnutzen.
Ihre Erwähnung von DSSSL hinterlässt ein schiefes Lächeln. Ich habe noch nie DSSSL verwendet, aber die Geschichten, die ich gehört habe, waren, dass es nicht erfolgreich war, weil seine Syntax arkan war und nichts mit der Syntax der Daten (SGML) zu tun hatte. Die Verwendung einer XML-Syntax für XSLT war stark von den Erfahrungen mit DSSSL motiviert.
Es gibt Leute, die XSLT lieben und es gibt Leute, die es hassen. Es überrascht nicht, dass diejenigen, die es häufig verwenden, in die erste Kategorie fallen. Diejenigen, die es nicht mögen, sind im Allgemeinen diejenigen, die nicht gelernt haben, wie man XSLT denkt. Sie könnten argumentieren, dass eine Programmiersprache nicht die Art und Weise beeinflussen sollte, wie Sie denken, aber es tut dies: Das Schreiben in einer regelbasierten Sprache unterscheidet sich von dem Schreiben in einer imperativen Sprache. Die erste Reaktion vieler Programmierer ist, dass sie sich weniger unter Kontrolle fühlen (das Problem beschreiben, anstatt dem Computer Schritt für Schritt mitzuteilen, was zu tun ist). Es ist der Reaktion sehr ähnlich, die Sie beim ersten Kennenlernen von SQL gesehen haben. Heutzutage lernen die Leute SQL zu einem früheren Zeitpunkt in ihrer Karriere, sodass weniger mentale Anpassungen erforderlich sind.
Letztendlich sollten Sie eine Technologie wählen, die auf objektiven messbaren Kriterien basiert, nicht auf Liebes- / Hassreaktionen. Es ist schwierig, diese Messungen durchzuführen. Aber es gibt viele Leute, die XSLT sehr intensiv und sehr erfolgreich nutzen, daher besteht kein Zweifel, dass dies möglich ist.