Diskussion:XSL Transformation

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „XSL Transformation“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Zum Archiv

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 30 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind.

XSLT eine Programmiersprache?

XSLT ist eine Programmiersprache zur Transformation von XML-Dokumenten - dies wage ich zu bezweifeln. XSLT ist doch keine Programmiersprache, oder? HTML ist schließlich auch keine Programmiersprache.

Das müsste man prüfen.

XSLT ist Turing-vollständig, HTML nicht.--dbh 22:54, 6. Jan 2005 (CET)

XSLT hat viele Möglichkeiten, die andere Programmiersprachen haben. Es ist möglich Schleifen (durch Rekursive tricks...) zu konstruieren, man hat lokale Variablen (auch wenn man diese nicht ändern kann). Es gibt viele Dinge, die mit XSLT leichter zu lösen wären, als mit anderen Programmiersprachen, dafür gibt es auch viele Dinge, die man mit XSLT schwer lösen kann. Ein Betriebssystem kann man damit selbstverständlich nicht entwickeln (das geht aber mit Basic auch nicht). Zudem kann man mit Xalan und Saxon auch den Funktionsumfang von XLST drastisch erweitern, ohne das hierdurch die Grundkonzepte verloren gehen. Man sollte daher die Möglichkeit verschiedene Biblotheksfunktionen aufrufen zu können auch als zusätzliche Fähigkeiten werten. (Wie hoch ist den beispielsweise der tatsächliche Sprachumfang der Sprache C?! Hier werden nur Funktionen aufgerufen und nur durch ANSI-C hat man hier eine Standardisierung angestrebt. Syscalls kann man auch nicht machen mit dieser Sprache, sondern nur über den Umweg integriertes Assembler... Von Java will ich gar nicht erst sprechen ;) ). Daher bin ich dafür, dass man XLST schon als Programmiersprache sehen kann/muß.

23:06, 24. Jan 2005 (CET)

Nach dem hier die Argumente geliefert worden sind, dass XSLT sehr wohl eine Programmiersprache ist, bin ich verwundert dass die Änderung von Christian Juner vom 12.02.2005 noch nicht korregiert wurde.

--Ingoschi 02:54, 19. Mär 2005 (CET)

Ich habe Auszeichnungssprache wieder in Programmiersprache geändert!

Die Begrünung von mir steht ja weiter oben. ;-)

Smoki 21:37, 23. Mär 2005 (CET)

Dem möchte ich zustimmen. XSLT ist definitiv eine Programmiersprache.--ChristianHujer 14:10, 26. Apr 2005 (CEST)

Ich halte den hierfür im Artikel genannten Beleg http://www.unidex.com/turing/utm.htm nicht für ausreichend. Quelle, die genau diesen Beleg kritisiert und den Nachweis deshalb selbst, für mich nachvollziehbar, zu führen versucht: http://www.cis.uni-muenchen.de/people/Meuss/Herrsching02/kepser_slides_1.pdf

• "Viele Seiten im WWW behaupten XSLT sei Turing-vollständig."
• "Aber: Keine Seite liefert einen Beweis"
• "Seite für Universelle Turingmaschine: http://www.unidex.com/turing/"
• "Aber: Programmcode viel zu lang, um Behauptung zu verifizieren."

-- RöntgenTechniker 12:34, 26. Mär. 2011 (CET)

Ich habe drei Beweise gefunden:

1. Universal Turing Machine in XSLT

2. A Proof of the Turing-completeness of XSLT and XQuery bzw. in ausführlicherer Form A Simple Proof for the Turing-Completeness of XSLT and XQuery

3. Für XSLT 2.0 XSLT Version 2.0 is Turing-Complete: A Purely Transformation Based Proof, in dem auch #1 und #2 Erwähnung finden.

An #2 habe ich auch etwas Kritik gefunden. Ich werde mal #1 als Quelle in den Artikel einfügen, denn damit sollte sowohl für 1.0 als auch 2.0 die Turing-Vollständigkeit gezeigt sein. --Zupftom 18:16, 26. Mär. 2011 (CET)

?? Jemand hatte schon zwei Beweise als Quellen hinzugefügt, bevor du hier geschrieben hast. Damit kommen wir auf vier Beweise (einen von denen im Artikel hatte ich schon aufgelistet). --Zupftom 18:19, 26. Mär. 2011 (CET)

Mir scheint, meine Nachfrage wurde falsch Verstanden. Der von Dir gefundene Beweis 1 war bereits als Beleg 1 im Artikel. Er wird aber eben in der von mir oben genannten Quelle als nicht verifizierbar kritisiert. Ob der zweite Beleg (Beispiel-Programmcode) einer genauen Überprüfung standhält, ist mir nicht klar. Bei einer objektiven Betrachtung müsste das zumindest erläutert oder diskutiert werden, wenn sich der Artikel auf diesen Beleg beruft. Der von Dir genannte Beleg :2. ist mir zu hoch. Falls das wasserdicht ist, sollte er auch als Quellenangabe in den Artikel. Bei dem von Dir genannten Beleg :2. funktioniert der Link nicht, deshalb weiß ich nicht, was drinsteht. Von den vier Belegen bleibt momentan einer übrig, den ich mangels tieferem Verständnis nicht kritisieren kann.-- RöntgenTechniker 19:40, 29. Mär. 2011 (CEST)

Tschuldige, ich hatte deine Links nicht richtig begutachtet. Du hast recht, die Nachweise sind nicht ausreichend. Der Unidex-Code ist wirklich furchtbarst. Aber Kepsers Nachweis ist auch falsch. Er behauptet, dass das Attribut @name des <call-template>-Elements ein XPath-Ausdruck sein darf, der einen QName zurückgibt. Das ist aber falsch, lediglich Saxon erlaubt das. Wenn es in einer zukünftigen Version mal erlaubt sein sollte, dann höchstens in Form eines attribute value templates so wie bei den <element>- oder <attribute>-Elementen, wo man z.B. name="{concat('abc',123)}" schreiben kann. In den Spezifikationen steht dort "name = { qname }", während bei <call-template> "name = qname" steht. Das ist für die Versionen 1.0 und 2.0 gleichermaßen so und auch für Version 3.0 bisher nicht anders vorgesehen. Auch Korlyukov ist nicht zu brauchen, weil er die node-set()-Funktion benutzt, die nicht im Standard enthalten ist. Selbst wenn #3 meiner Liste oben korrekt ist, dann haben wir immer noch keinen Nachweis für die Turing-Vollständigkeit von Version 1.0.

Ich frage mich, warum es sich alle so schwer damit machen. Ich habe mehrere Varianten einer Turing-Maschine in XSLT geschrieben. Eine ganz einfache Turing-Maschine ohne Firlefanz ist auf einer A4-Seite XSLT-Code gut machbar. Was müssen denn für Voraussetzungen gegeben sein, dass so was als Nachweis der Turing-Vollständigkeit gelten kann? Ich bin jetzt kein Informatiker, vielleicht weißt du ja mehr. --Zupftom 12:54, 31. Mär. 2011 (CEST)

Beispiel

Hallo, das es ein Beispiel gibt, finde ich gut, aber woraus macht dieses Beispiel eine XHTML-Datei (vermutlich aus einer XML-Datei)? Kann man nicht auch mal exemplarisch eine solche Datei angeben (muss ja nicht groß sein). 80.138.250.75 12:42, 4. Okt 2005 (CEST)

Jede XHTML-Datei mit h2-Überschriften kann für das Beispiel als Eingabe verwendet werden. -- Stf 10:33, 20. Mai 2009 (CEST)

Hallo, wäre folgende Änderung im Beispiel nicht sinnvoller:

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

-- demx8as6 (23:37, 19. Mai 2009 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Ja, da bin ich auch gestolpert. Diese Änderung wäre sinnvoll. Sei mutig! -- Stf 10:33, 20. Mai 2009 (CEST)

HTMLWorld: XSLT-Tutorial

Vorab: Wahrscheinlich gehört dieser Diskussionsbeitrag eher zu der Seite, die unter Weblinks angegeben wurde als zum XSL-T Artikel hier, jedoch ist in der angegebenen Seite keine Möglichkeit zur freien Diskussion gegeben und es dürfte auch hier von Interesse sein.

Ich habe versucht die Beispiele, die auf der Seite „HTMLWorld: XSLT-Tutorial“ gegeben sind nachzuvollziehen, bin jedoch schon beim zweiten Beispiel ins Schleudern gekommen: Ich habe mit zwei, hier im Wikipedia-Artikel empfohlenden XSLT-Prozessoren (xmlstarlet und Sablotron) versucht das, auf der Webseite [www.html-world.de/...#Templates in Templates] gegebenen Beispiel zu transformieren und erwartete, dass auch das herauskommt, was auf der besagten Webseite prophezeit wird, jodoch haben beide XSLT-Prozessoren konsequent etwas anders gemacht. Ich bin Neuling in Bezug auf XML und XSLT und würde mich freuen, wenn mir jemand sagen könnte, wieso sich das Ergebnis von dem, auf der angegebenen Webseite gezeigtem unterscheidet. Es sei zu beachten, dass ich die Eingabedateien leicht modifiziert habe, da sich Sablotron mit dem gegebenen Beispiel nicht abfinden wollte. Mit den Modifikationen können nun beide XSLT-Prozessoren leben.

Hier nochmal die Details:

Datei: Source.xml:

<?xml version="1.0"?>
<?xml-stylesheet href="./TransformRules.xsl" encoding="input-encoding" type="text/xsl"?>
<A>
 <B>
  <C />
 </B>
</A>

Datei: TransformRules.xsl:

<?xml version="1.0"?>
<xsl:stylesheet version="1.0"
     xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="A">
 <html>
 <body>
 <p>Der Inhalt von B wird ausgelassen,
 stattdessen folgt der Inhalt von C:</p>
 <p>"<xsl:apply-templates select="C" />"</p>
 </body>
 </html>
</xsl:template>
<xsl:template match="B">
 Anfang B
 <xsl:apply-templates/>
 Ende B
</xsl:template>
<xsl:template match="C">
 Dies ist der Inhalt von C
</xsl:template>
</xsl:stylesheet>

Datei: Destination.html (erzeugt durch xmlstarlet-1.0.1):

<html><body>
<p>Der Inhalt von B wird ausgelassen,
 stattdessen folgt der Inhalt von C:</p>
<p>""</p>
</body></html>

Datei: Destination.html (erzeugt durch Sablot-Win-1.0.3):

<html><body><p>Der Inhalt von B wird ausgelassen,
 stattdessen folgt der Inhalt von C:</p><p>""</p></body></html>

Kommandozeilenbefehl für xmlstarlet:

xml tr "C:\XSLT-Tutorial\TransformRules.xsl" "C:\XSLT-Tutorial\Source.xml" > "C:\XSLT-Tutorial\Destination.html"

Kommandozeilenbefehl für Sablot:

sabcmd "file://C:\XSLT-Tutorial\TransformRules.xsl" "file://C:\XSLT-Tutorial\Source.xml" "file://C:\XSLT-Tutorial\Destination.html"

Hab ich irgendwo einen Denkfehler ?
Wer hilft mir auf die Sprünge ?

Vielen Dank im Vorraus.
--141.41.37.250 15:53, 5. Okt 2006 (CEST)

XSLT 2.0 ist seit Januar kein "Candidate" mehr. Wer diesen Sachverhalt mal aktualisieren.(nicht signierter Beitrag von 195.202.38.116 (Diskussion) 10:01, 11. Jun. 2007)

Links

Hi, Links zu Software, die massiv Einsatz von XML/XSLT wären informativ, z.b. http://cocoon.apache.org http://forrest.apache.org da XML/XSLT auch gerne zum Webpublishing benutzt wird. Gruß Chris(nicht signierter Beitrag von 84.155.191.187 (Diskussion) 10:27, 27. Okt. 2006)

Hab ich etwas verpasst?

"XSLT-Prozessoren sind auch in vielen modernen Webbrowsern integriert, so Opera (ab Version 9), Firefox, Internet Explorer Version 5 (erst seit Version 6 mit vollständiger XSLT-1.0-Unterstützung) oder Mozilla."

Ich war der Meinung, dass der Firefox doch zu Mozilla gehört oder hat sich da etwas geändert? :X (nicht signierter Beitrag von 79.195.201.190 (Diskussion | Beiträge) 08:07, 5. Mär. 2010 (CET))

Du wirst hier vermutlich nicht mehr nachschauen, aber da hat sich was verändert. IE 5/6 sind nicht mehr modern, und den Webbrowser Mozilla gibt es nicht mehr als solchen. – Gorlingor (Diskussion) 16:52, 19. Sep. 2011 (CEST)

Firefox hat keinen vollstaendigen XSLT support

Und zwar geht es um die Transformation von HTML Fragmenten welche in XML gewrappt sind.

Dazu wird dringend das disable-output-escaping Attribut benoetigt welches in der Firefox Implementation jedoch fehlt. Anstatt den HTML Code zu rendern wird er von Firefox escaped und angezeigt.

Dasselbe gilt fuer alle Mozilla Browser (Seamonkey, Fennec, etc.)

Der Bug ist seit 2001 bekannt: https://bugzilla.mozilla.org/show_bug.cgi?id=98168

...wird aber ignoriert da die Art und Weise wie Firefox mit XML als Dateityp umgeht es scheinbar in zuviel Arbeit ausarten lassen wuerde diese wichtige Funktionalitaet entsprechend der W3C Spezifikationen umzusetzen. (nicht signierter Beitrag von 78.94.41.76 (Diskussion) 10:32, 6. Nov. 2011 (CET))

Bugs findet man bei allen Browsern. z.B. Chrome: XSL Bugs. Du darfst davon ausgehen, dass es beim IE auch jede Menge Bugs gibt, nur hast du keinen Zugriff auf die Bugliste. Im übrigen hat nicht jeder Bug gleich eine Auswirkung die von durchschnittlichen Benutzern überhaupt bemerkt wird.--Boshomi 13:40, 6. Nov. 2011 (CET)

Die W3C Spezifikation sagt zu disable-output-escaping ([Kapitel 16.4]): "An XSLT processor is not required to support disabling output escaping.". Also ist der "Bug" nichteinmal ein Bug. --Sebastian.Dietrich ✉ 16:02, 6. Nov. 2011 (CET)

Dann ist es eben die uebliche Mozilla Idiotie. Denen ist eh nicht mehr zu helfen. Seit 10 Jahren sabotieren die schon XSL dadurch das dieses extrem wichtige Feature fehlt. Die "Nein-machen-wir-nicht-weil-blablabla" Ausfluechte in deren Bug Forum sind schon 100x laenger als der Patch. Absolut laecherlich. Ein Zwang keine HTML Fragmente im XML zu wrappen ist so eine uebertriebene Spinnerei das haelt man im Kopf nicht aus. Da will man VirtualBox installieren um IE zu benutzen. Ich gebe dann mal nach und orientiere mich in Zukunft an Chromium. (nicht signierter Beitrag von 79.194.247.31 (Diskussion) 19:08, 6. Nov. 2011 (CET))

Generische Programmiersprachen - watt is'n dütt?

Ich habe aus dem Artikel ein Auftreten der "generischen Programmiersprachen"-Formulierung rausgenommen. Eine steht aber noch drin - als Abschnitts-Überschrift. Es wäre nett, wenn jemand der besser als ich weiss, was eine generische Programmiersprache ist, (ich denke das heisst hier wohl so etwas wie "normale Programmiersprachen" oder "andere Programmiersprachen") den Begriff verlinkt, erklärt oder umformuliert.

(Ich persönlich glaube ja, dass die Verwendung der Formulierung "Generische Programmiersprachen" hier einfach Unsinn ist, aber ich weiss auch dass es viele Leute gibt, die auf das Wort "generisch" grosse Stücke halten. Deswegen meine einzige Änderung an sicherer Stelle und meine Appell an die Kenner des Generischen, die Sache klarer zu Formulieren) -- Wortverdreher 22:45, 8. Feb. 2012 (CET)

Hier ist mit generischer Programmiersprache "beliebige, nicht spezifische Programmiersprache" gemeint. D.h. so wie die meisten Programmiersprachen, die nicht für eine spezielle Aufgabe wie z.B. Spracherkennung entwickelt wurden. Hab das "generisch" im Artikel entfernt. --23:15, 8. Feb. 2012 (CET)

Danke für das schnelle Eingreifen! Aber ein, zugegebenermassen etwas haarspalterisches, Problem ist jetzt dazugekommen: Der Satz "Außerdem ist die Entwicklung einer Transformation in XSLT in der Regel mit erheblich weniger Aufwand verbunden als die Entwicklung einer Transformation in einer Programmiersprache" beisst sich jetzt mit der Behauptung, dass XSLT eine Programmiersprache sei (ganz am Anfang des Artikels) --Wortverdreher 00:59, 9. Feb. 2012 (CET)

Ja ist mir auch aufgefallen - wie wärs mit "...in einer anderen Programmiersprache" und Kapitelüberschrift "Andere Programmiersprachen"? --Sebastian.Dietrich ✉ 08:27, 9. Feb. 2012 (CET)

Ich glaube, dass der Satz, der von erheblich weniger Aufwand spricht, inzwischen nicht mehr stimmt. Viele Programmiersprachen haben inzwischen XML-Funktionalität integriert (z.B. Groovy, Scala und E4X), so dass sich auch mit diesen Sprachen XML-Transformationen leicht beschrieben lassen. Aber das eigentliche Problem ist, dass die meisten Leser denken "Es gibt richtige Programmiersprachen wie C,C++ und Java und es gibt XSLT, das nur 'irgendwie' ein Programmiersprache ist". Diese Logik ist die Grundlage für viele Formulierungen im Artikel. Was hier fehlt, ist eine Klarstellung dessen, was jetzt eine richtige (a.k.a. normale, andere oder generische) Programmiersprache ist, und was für eine Art Programmiersprache XSLT im Gegensatz dazu ist. Interessant wäre auch zu wissen, welche Programmiersprachen das Schicksal von XSLT teilen, und deshalb nicht wirklich als Programmiersprache wahrgenommen werden. -- Wortverdreher 10:33, 9. Feb. 2012 (CET)

Vereinfachung des Artikels

Liebe Mitstreiter Ich bin hier gelandet, weil ich eine "xml" Datei in Word 2013 öffnen wollte Und Word zunächst fordert, daß ich eine XSL Datei öffnen soll die ich nicht habe, bzw. wofür es keine Muster gibt.

Der Artikel beschreibt XSL recht gut, aber es fehlt der praktische Bezug, wie er oben schon mehrfach beschrieben wurde. Mir fehlen folgende Sätze.

Kurzbeschreibung Mit XSL Transformation kann man XML Dateien aufbereiten, um sie besser Bearbeiten oder betrachten zu könne. Dieses Darstellungsfunktion kann wird auch in xml geschrieben.

Und dann fehlt mir noch der Bezug zu. Z.B. Cristal.

--178.13.153.190 16:48, 17. Feb. 2014 (CET)

Alternativen sind keine

diesen Abschnitt würde ich löschen, den genannten Alternativen fehlt inzwischen jegliche Relevanz. Evtl wäre Omnimark eine Erwähnung wert... (nicht signierter Beitrag von 88.153.6.23 (Diskussion) 17:39, 27. Aug. 2016 (CEST))

Ausgestorben

Vielleicht sollte man erwähnen, dass xslt ausgestorben ist. Mir ist seit 20 Jahren kein praktisches Beispiel mehr untergekommen (nicht signierter Beitrag von 77.11.8.72 (Diskussion) 20:56, 25. Jun. 2021 (CEST))

Hmm - ich hab auch seit 20 Jahren keinen Elefanten mehr gesehen. Sind die vielleicht ausgestorben?

Jetzt aber im Ernst: Wenn etwas heute angeblich nicht mehr in der Entwicklung verwendet wird, dann ists deshalb nicht ausgestorben (weils in legacy Software noch immer existiert und die wird ja sogar noch gewartet). Und wenn du nur schreiben willst, dass das heutzutage nicht mehr in der Entwicklung verwendet wird, dann brauchst dafür Belege. Ohne Belege glaubt dir das niemand... --Sebastian.Dietrich  ✉  12:08, 27. Jun. 2021 (CEST)

Im EDI Umfeld wird XLST zwar selten benutzt, aber es ist dennoch existent und hat seine eigene Nische --212.23.147.218 15:40, 16. Feb. 2023 (CET)