XSL-T / XSLT-Tipps / XSL-Prozessoren

XSL-Prozessoren

➪ In der Entwicklung, im Test- und im Produktivsystem werden mitunter unterschiedliche Prozessoren bzw. Versionen verwendet. Das kann zum Problem führen, wenn unterschiedliche Prozessoren nicht einheitlich arbeiten.

Zur Ausführung der in XSL deklarierten Logik ist ein geeigneter Prozessor erforderlich. Es gibt eine längere Reihe von freien bzw. kommerziellen XSL-Prozessoren, die unterschiedliche Unterstützung bieten.

• Einige Prozessoren unterstützen XSLT 1.0, XSLT 2.0 und XSLT 3.0, teilweise mit, teilweise ohne Streaming.
• Weitere Prozessoren unterstützen XSLT 2.0, einige davon werden nicht weiter entwickelt, andere nur experimentell.
• Eine Vielfalt weiterer Prozessoren unterstützt lediglich XSLT 1.0.
• Für browserseitige XSL-Transformationen steht im Regelfall nur XSLT 1.0 zur Verfügung. Ausnahme: Das in JavaScript geschriebene Saxon-JS unterstützt XSLT 3.0; Voraussetzung: Das XSLT muss durch Saxon-EE kompiliert sein.
• Prozessoren, die XPath 3.1 unterstützen, müssen die entsprechenden Features anbieten (https://www.w3.org/TR/xslt-30/#dt-xpath31-feature). Siehe zum Beispiel Arrays.
• Das gilt analog für Streaming: https://www.w3.org/TR/xslt-30/#streaming-feature.
• Die HOF-Features (https://www.w3.org/TR/xslt-30/#hof-feature) gelten für Prozessoren, die "higher-order functions" unterstützen. Auch hier gibt es einen Unterschied zwischen freien und kommerziellen Implementierungen, der sich zum Beispiel bei den anonymen Funktionen bemerkbar macht.

Einige XSL-1.0-Prozessoren bieten neben den zahlreichen XSL-Standard-Elementen und -Attributen noch diverse Extensions an, die die Standardfunktionalitäten erweitern. Ein Beispiel finden Sie unter max.

Bei jenen XSL-Prozessoren, die verschiedene XSL-Versionen unterstützen, kann die Versionierung des xsl:stylesheet wesentlichen Einfluss auf die interne Verarbeitung der Anweisungen haben, was Informationsverlust nach sich ziehen kann. Ein Beispiel finden Sie unter contains.

<xsl:stylesheet 
     xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
     version="1.0">
</xsl:stylesheet>

Aber auch bei identischer XSL-Versionierung arbeiten die Prozessoren durchaus nicht einheitlich. Das macht sich u.a. bemerkbar

• bei Zeitkalkulationen und diesbezüglichen Formatierungen (dateTime, duration).
• bei der Behandlung von Zahlen (automatischer typecast als xs:double oder xs:decimal, s.u.).
• wenn in der Entwicklung, im Test- und im Produktivsystem unterschiedliche Prozessoren bzw. Versionen oder Konfigurationen verwendet werden.
• bei der zeitaufwendigen, nervigen Detailkorrektur nach einem Prozessorwechsel.

Ein Beispiel finden Sie bei der sum()-Funktion. Hier lohnt sich ein Type-Cast der zu addierenden Werte, insbesondere, wenn sie erst berechnet werden müssen.

In der Variablen vtmpdemo werden 100 Childnodes generiert:

<xsl:variable name="vtmpdemo">
  <root>
    <xsl:for-each select="1 to 100">
      <k p="0.1" a="3"/>
    </xsl:for-each>
  </root>
</xsl:variable>

Im Ergebnis stehen für vtmpdemo damit 100 Einzelpositionen mit demselben Inhalt bereit:

<root>
  <k p="0.1" a="3"/>
  <k p="0.1" a="3"/>
...
  <k p="0.1" a="3"/>
</root>

Nun geht es darum, die Werte der Attribute a und p zu multiplizieren und sämtliche Einzelprodukte zu addieren. Dabei arbeite ich einmal mit den Standardsetzungen des jeweiligen Prozessors, ein andermal erzwinge ich einen Type-Cast jedes Einzelwertes auf xs:decimal".

<erg 
   summe1="{sum($vtmpdemo/root/k/(@p * @a))}" 
   summe2="{sum
             (
               $vtmpdemo/root/k/
                (xs:decimal(@p) * xs:decimal(@a))
             )
           }">
  <xsl:for-each select="$vtmpdemo/root/k">
    <wert>
      <xsl:value-of select="@p * @a"/>
    </wert>
  </xsl:for-each>
</erg>

Bei den Ergebnissen zeigen sich Unterschiede.

Während ein Prozessor die summe2" korrekt berechnet (wo der Type-Cast für jeden Einzelwert auf xs:decimal" erzwungen wurde), wird bei summe1" die Addition der Einzelwerte vermutlich über xs:double" berechnet.

<erg summe2="30" summe1="30.00000000000005">
  <wert>0.30000000000000004</wert>
  <wert>0.30000000000000004</wert>
  <wert>0.30000000000000004</wert>
...
  <wert>0.30000000000000004</wert>
</erg>

Völlig dasselbe Ergebnis erhalte ich mit einem anderen Prozessor:

<erg summe1="30.00000000000005" summe2="30">
  <wert>0.30000000000000004</wert>
  <wert>0.30000000000000004</wert>
...
  <wert>0.30000000000000004</wert>
</erg>

Wieder ein anderer Prozessor arbeitet dagegen vermutlich von vornherein auf der Basis von xs:decimal"; zumindest stimmen die tatsächlichen Ergebnisse mit den erwarteten überein.

<erg summe1="30" summe2="30">
 <wert>0.3</wert>
 <wert>0.3</wert>
...
 <wert>0.3</wert>
</erg>

Wegen Abweichungen dieser Art sind vor dem Go-Live detaillierte Tests anzuraten, und zwar mit jenem Prozessor (derselben Version und Konfiguration!), der auch produktiv arbeitet.

wg / 22. April 2018

---

---

Fragen? Anmerkungen? Tipps?

Bitte nehmen Sie Kontakt zu mir auf.

---