Reihenfolge der verarbeitung von templates bei XSLT

[Michael_K]

Hallo,

da Chrome nun das Ende der Browser-Unterstützung angekündigt hat, versuche ich es mit einer JS-Lösung.

Allerdings wirft mir die genutzt JS Bibliothek ein Maximum stack exceed Fehler. Ich wollte nun mich langsam vorantesten, welcher Code in meinem XSLT dieses Problem verursacht. (Die Browser-Implementierung in hrome und FF funktioniert ohne Probleme). Jetzt komme ich aber ins Schwanken, in welcher Reihenfolge die Templates abgearbeitet werden. Gibt es hierzu eine gut verständliche Quelle, die veranschaulicht, wann ein <xsl:template match="*"/> etc durchlaufen wird und wann nicht. Es geht mir also um die Frage, wann welche Templates angewendet werden, um besser zu verstehen, wo ein template im xsl code platziert werden muss. Ich dachte eigentlich, ich haette es verstanden, aber dem ist scheinbar nicht so.

Zusatzfragen, die ich aktuell noch nicht beatnworten konnte: Kennt jemand eine gute/robuste client-side JS Lösung mit xsl und xml jeweils als xmlString input?

Wie lange gibt es, bis die XSLT native Unterstützung aus Chrome endgültig entfernt wird?

Gruss Michael

[Ryuno-Ki]

Moin Michael_K,

Zusatzfragen, die ich aktuell noch nicht beatnworten konnte: Kennt jemand eine gute/robuste client-side JS Lösung mit xsl und xml jeweils als xmlString input?

Ich nutze dafür oftmals DOMParser aus dem Browser direkt. (Gibt keinen Artikel dazu im SELFWiki bisher)

Was magst denn genau mit der Lösung machen? (Abfragen, manipulieren, …)

MDN hat eine Übersichtseite zu XML.

Gruß,

[Michael_K]

Hallo,

ich glaube, du hast es falsch verstanden. Es ging mir nicht um einen DOMParser, sondern um einen XSLTProcessor. Das sind zwei sehr verschiedene Dinge.

Gruss

[Ryuno-Ki]

Moin Michael_K,

ich glaube, du hast es falsch verstanden. Es ging mir nicht um einen DOMParser, sondern um einen XSLTProcessor. Das sind zwei sehr verschiedene Dinge.

Die Frage ging um XML- UND XSLT-Prozessor. Ich habe einen Teil davon beantwortet.

Gruß,

[Michael_K]

Ich kann nicht wirklich nachvollziehen, wie du aus meinen Fragestellungen einen Verweis auf den DOMParser ableitest. Die Überschrift und Fragen war klar auf XSLT begrenzt.

[Ryuno-Ki]

Moin Michael_K,

Ich kann nicht wirklich nachvollziehen, wie du aus meinen Fragestellungen einen Verweis auf den DOMParser ableitest. Die Überschrift und Fragen war klar auf XSLT begrenzt.

Zusatzfragen, die ich aktuell noch nicht beatnworten konnte: Kennt jemand eine gute/robuste client-side JS Lösung mit xsl und xml jeweils als xmlString input?

Hervorhebung von mir.

Gruß,

[Michael_K]

Ganz ehrlich, was verstehst du nicht an "mit xsl UND xml jeweils als xmlString input". Ein DOMParser ist in keinster Weise geeignet, lange xmlStrings zu Parsen, es sein denn, man möchte extrem schlechte Performance und hohen Ressourcenverbrauch. Lass bitte gut sein.

Gruss

[ThomasM]

Hallo Michael,

Allerdings wirft mir die genutzt JS Bibliothek ein Maximum stack exceed Fehler. Ich wollte nun mich langsam vorantesten, welcher Code in meinem XSLT dieses Problem verursacht. (Die Browser-Implementierung in hrome und FF funktioniert ohne Probleme). Jetzt komme ich aber ins Schwanken, in welcher Reihenfolge die Templates abgearbeitet werden. Gibt es hierzu eine gut verständliche Quelle, die veranschaulicht, wann ein <xsl:template match="*"/> etc durchlaufen wird und wann nicht. Es geht mir also um die Frage, wann welche Templates angewendet werden, um besser zu verstehen, wo ein template im xsl code platziert werden muss. Ich dachte eigentlich, ich haette es verstanden, aber dem ist scheinbar nicht so.

Üblicherweise entscheidet der XSLT-Prozessor im Kontext der Templatestruktur:

<xsl:template match="/"> <!-- Wurzelknoten bzw. anderer Knoten -->
 <xsll:apply-templates/> <!-- ggf. mit select="..." -->
</xsl:template>

Ob in Deinem Code die "*"-Referenz nötig ist, kann ich so nicht beurteilen. Zeige mal ein minimales testbares Beispiel mit dem Fehler.

Grüße,
Thomas

[Michael_K]

Hallo Thomas,

mir ging es insbesondere um die Fragestellung, wo die Default-Templates platziert werden sollten. Direkt am Anfang oder doch am Ende.

Mir scheint aber, dass die anvisierte JS-Bibliothek einige Bugs hat (dies hier: https://www.npmjs.com/package/xslt-processor). Zumindest liefert iese Ergebnisse, die ich definitiv nicht erwarte bzw. auch nicht mit der nativen Browser-Implementierung erhalte.

Die von den Google Chrome Entwickler empfohlene xslt-polyfill (hier: https://github.com/mfreed7/xslt_polyfill) ist ein schlechter Witz, weil diese unsafe-eval für die CSP erfordert.

Wirklich keine schöne Situation, angeblich wird der Brwoser-Support für XSLT wohl Ende 2026 abgeschaltet.

Gruss

[ThomasM]

Hallo Michael,

mir ging es insbesondere um die Fragestellung, wo die Default-Templates platziert werden sollten. Direkt am Anfang oder doch am Ende.

Was sind Default-Templates, die mit match="*" und wozu überhaupt? select="*" oder "//*" wäre als child- oder descendant-Zugriffe unterhalb von xsl:applay-templates relevant.

xsl:template-Blöcke gehören auf die oberste Ebene unterhalb von xsl:sylesheet. Der Prozessor arbeitet diese entsprechend ab. Zu beachten wären ggf. noch durch xsl:import bzw. xsl:include eingefügte Teile.

Mir scheint aber, dass die anvisierte JS-Bibliothek einige Bugs hat (dies hier: https://www.npmjs.com/package/xslt-processor). Zumindest liefert iese Ergebnisse, die ich definitiv nicht erwarte bzw. auch nicht mit der nativen Browser-Implementierung erhalte.

Wenn das serverseitig mit Node.js umgesetzt werden soll, dann könnte auch PHP zum Einsatz kommen. Kann ebenfalls (nur) XSLT 1.0.

Die von den Google Chrome Entwickler empfohlene xslt-polyfill (hier: https://github.com/mfreed7/xslt_polyfill) ist ein schlechter Witz, weil diese unsafe-eval für die CSP erfordert.

Das tue ich mir vorerst nicht an, zumal ich keine Transformationen im Browser online habe, jedoch welche auf PHP-Basis oder via SaxonJS (dort kommt XSLT 3.0 + XPath 3.1 als JSON-Kompilat zum Einsatz).

Wirklich keine schöne Situation, angeblich wird der Brwoser-Support für XSLT wohl Ende 2026 abgeschaltet.

Mal abwarten.

Grüße,
Thomas

[Michael_K]

Moin,

XSLT default templates

A default template is used during XSLT processing when there is no matching explicit template rule in the style sheet. The default template, also referred to as built-in template rule, is defined in section 5.8 of the W3C XSLT 1.0 Recommendation. The default template allows the XSLT processor to process a node, even though there is no explicit template rule that matches it. However, because the built-in template rule is not explicitly defined in the style sheet, this may lead to unexpected or confusing XSLT transformation results.

Um sicherzugehen, sollte man die default templates im xsl angeben. Also so etwas hier:

<xsl:template match="@*|node()">
      <xsl:copy>
         <xsl:apply-templates select="@*|node()" />
      </xsl:copy>
   </xsl:template>

Stellt sich für mich aber die Frage, ob die an den Anfang, ans Ende oder egal wo stehen können. Ich war immer daavon ausgegangen, dass die irgendwo stehen können, weil ja kein anderes Template matched.

[ThomasM]

Hallo Michael,

Um sicherzugehen, sollte man die default templates im xsl angeben. Also so etwas hier:

<xsl:template match="@*|node()">
  <xsl:copy>
    <xsl:apply-templates select="@*|node()" />
  </xsl:copy>
</xsl:template>

Stellt sich für mich aber die Frage, ob die an den Anfang, ans Ende oder egal wo stehen können. Ich war immer daavon ausgegangen, dass die irgendwo stehen können, weil ja kein anderes Template matched.

Dieses Template kopiert alle Knoten 1:1 in die Ausgabe und wird üblicherweise als Identity-Template eingesetzt, meistens mit zusätzlichen Templates, welche spezielle Anpassungen regeln sollen. Oft <xsl:template match="..."/>, um Teile der Ausgangsstruktur auszuschließen oder, falls nicht leer, mit weiterem Template-Inhalt anzupassen.

Von daher ist dieses Verhalten bei HTML-Ausgaben eher unerwünscht.

Übrigens lässt sich dieses Identity-Template in XSLT 3.0 kompakter formulieren:

<xsl:mode on-no-match="shallow-copy"/>

Grüße,
Thomas

[Michael_K]

Hallo Thomas,

ich habe es eigentlich schon bereut, XSLT im vorliegenden Fall zu nutzen. Mit einem Sax-Parser wäre ich vermutlich besser bedient .. nun gut. Aber XSLT3.0 wäre ein overkill bzw. möchte mich nicht wirklich einarbeiten.

Aber habe ich es richtig verstanden, dass die SaxonJS bibliothek nur mit json basierten xslt input arbeitet? Ich habe als input dynamisch erzeugten XSL-Quellcode als String und eine XML-Quelle als String. Wenn cih es richtig verstehe, kann ich die SaxonJS bibliothek nicht verwenden, weil die nur json basierte XSL on-the-fly ermöglicht.

Gruß Michael

[ThomasM]

Hallo Michael,

Aber habe ich es richtig verstanden, dass die SaxonJS bibliothek nur mit json basierten xslt input arbeitet? Ich habe als input dynamisch erzeugten XSL-Quellcode als String und eine XML-Quelle als String. Wenn cih es richtig verstehe, kann ich die SaxonJS bibliothek nicht verwenden, weil die nur json basierte XSL on-the-fly ermöglicht.

SaxonJS ist primär eine Laufzeitumgebung für die vorkompilierten Transformationen. Die Eingabedaten (typischerweise XML oder JSON) werden mit dem kompilierten XSLT-Stylesheet (SEF = Stylesheet Export File) verarbeitet.

Das grundsätzliche Vorgehen habe ich hier erläutert. Mittlerweile (seit SaxonJS 2) ist die SEF-Datei als JSON formuliert, aber das ist im Gesamtprozess eher sekundär. Ein prototypisches Beispiel ist mein SVG-Funktionsplotter. Hierbei gibt es keine separate XML-Datenquelle, alle Operationen laufen direkt über das kompilierte XSLT.

Grüße,
Thomas

[Michael_K]

Interessant, aber es scheint wirklich unvermeidlich, dass XSLT der Bedeutungslosigkeit geweiht ist.

Es mag jemand für sich die Sinnhaftigkeit von den kompilierten SEF files erkennen, ich tue es nicht. Werde wohl tatsächlich es umschreiben müssen. Damit werde auch ich XSLT für immer den Rücken zuwenden. Aber manchmal muss man scheinbar mit alter Technik brechen, die nicht sinnvoll unterstützt wird. Kann man nur wünschen, dass FF mitzieht und auch den alten Balast abwirft.

Es wird wohl ein Sax Parser für meinen Anwendungsfall werden; ist performanter und benötigt zudem noch weniger Ressourcen. RIP XSLT.

[ThomasM]

Hallo Michael,

Interessant, aber es scheint wirklich unvermeidlich, dass XSLT der Bedeutungslosigkeit geweiht ist.

Es kommt überwiegend in Branchen wie Technische Dokumentation/Kommunikation, Verlagswesen (Bucherstellung: DOCX > InDesign (IDML) > PDF | EPUB usw.) und Digital Humanities zum Einsatz. Dort überwiegend in Form lokaler oder serverseitiger Transformationen und mit Saxon-HE steht ein freier Prozessor zur Verfügung, welcher XSLT 3.0 und XPath 3.1 in breitem Umfang unterstützt.

SaxonJS ist nicht der Ersatz für Browser-XSLT, zumal der benötigte Saxon-PE/HE etwas kostet. Es ist jedoch eine Möglichkeit, in einem bestimmten Ökosystem zu bleiben. So konnte ich die 101 Funktionen und ihre ersten bis dritten Ableitungen als xsl:function hinterlegen und die 101 MathML-Formeln ebenfalls sauber vorhalten. Da die SVG-Ausgabe auch XML ist, passt das ideal zusammen.

Die Browser-Nutzung von XSLT sehe ich durch die aktuellen Querelen auch am Ende, aber das war und ist gar nicht meine Baustelle. Meine Website-News erzeuge ich weiterhin völlig ausreichend mit XSLT 1.0 via PHP (eine XML-Quelle + drei Transformationen nach HTML, RSS und Atom) und ansonsten hat eben die clientseitige Nutzung das Primat. Dort kann mir niemand reinreden.

BTW: Mir wurde kürzlich prophezeit, dass es für Leute wie mich eine ganz besondere Hölle gibt. Tja.

Grüße,
Thomas

[Michael_K]

Ich hatte ja auch XSLT ausgewählt, weil es sich um eine Konvertierung von einem XML Format in ein anderes XML handelt. Das war ja der Haupantwendungszweck von XSLT. Nach meiner EInschätzung kann man dies aber genauso gut mit einem Sax-Parser durchführen. Ein DOMParser wird langsam, wenn das XML-Dokument groß ist un der ganze DOM im Speicher vorgehalten werden muss. Ich ärgere mich nur jetzt, weil ich nicht gleich auf Sax gesetzt habe.