xsl:result-document

(Auszug aus "XSLT 2.0 & XPath 2.0" von Frank Bongers, Kapitel 6.)

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z

 

Die Instruktion xsl:result-document wird benötigt, wenn im Zuge einer Transformation ein oder mehrere sekundäre Ergebnisdokumente erzeugt werden müssen. Hierbei können der URI dieses Dokuments bestimmt und jeweils ein (benanntes) Ausgabeformat xsl:output zugewiesen werden.

Klassifizierung	Instruktion
Funktionsgruppe	Sekundäres Ergebnisdokument
Einführung	XSLT 2.0

Position im Stylesheet und erlaubte Inhalte:

Die Instruktion xsl:result-document tritt in beliebiger Häufigkeit im Inneren von Template-Regeln auf, jedoch nicht in XSLT-Elementen, die einen temporären Baum erzeugen, wie xsl:variable, oder wie xsl:message, einen Baum, der nicht als Dokument serialisiert wird.

Die Instruktion enthält einen Templateinhalt in Form eines Sequenzkonstruktors, der eine Sequenz aus Knoten erzeugt, die den Dokumentbaum des sekundären Ergebnisdokuments ergibt.

Attribute:

Es gelten die Standardattribute. Die Instruktion xsl:result-document besitzt dazu noch zwanzig optionale elementspezifische Attribute, die (mit Ausnahme des Attributs use-character-maps) sämtlich Attributwert-Templates enthalten dürfen. Ein Teil der Attribute entspricht den in der Spezifikation »XSLT 2.0 and XQuery 1.0 Serialization« eingeführten Serialisierungsparametern, wie sie auch in der Deklaration xsl:output festgelegt werden.

Hinweis: Bezieht sich eine xsl:result-document-Instruktion über ihr format-Attribut auf eine benannte Deklaration xsl:output, so haben ihre gleichnamigen Attribute gegebenenfalls Vorrang vor jenen der Output-Deklaration. Dasselbe gilt, wenn kein format-Attribut eingesetzt wird, nur dass in diesem Fall Bezug auf die unbenannte Output-Deklaration genommen wird.

byte-order-mark

Wert	{"yes" | "no"} (auch als AVT)
Verwendung	optional
Einführung	XSLT 2.0

Mit Hilfe des byte-order-mark-Attributs wird festgelegt, ob am Anfang der ausgegebenen Datei eine Byte-Order-Marke (BOM) gesetzt werden soll, oder nicht. Die Wertübergabe per Attributwert-Template ist gestattet.

Das Attribut von xsl:result-document hat Vorrang vor dem gleichnamigen Attribut derjenigen xsl:output-Deklaration (oder gegebenenfalls dessen Defaultwert), die über das format-Attribut der Instruktion festgelegt ist, bzw. der unbenannten Output-Deklaration, falls kein format-Attribut gesetzt ist.

Mittels des byte-order-mark-Attributs kann das Setzen einer BOM also stets erzwungen oder (sofern das Setzen in der Output-Deklaration eigentlich vorgesehen ist) stets unterdrückt werden.

Die Byte-Order-Marke besteht aus dem Unicode-Zeichen U+FEFF (zero width no-break space), das an den Anfang der Ressource gesetzt wird. Je nach Kodierung wird dieses Zeichen durch eine bestimmte Bytefolge umgesetzt, aus der das Encoding für eine verarbeitende Anwendung ersichtlich ist (siehe folgende Tabelle).

Aufgabe der Marke ist es, einer Anwendung, die die Ressource einliest, Auskunft über deren Encoding zu geben (oft kann die Anwendung dies auch selbstständig aus den ersten Zeichen der Ressource entnehmen). Bedeutsam ist dies vor allem bei den Encodings UTF-16 (zwei Bytes pro Zeichen) und UTF-32 (vier Bytes pro Zeichen), wo zwischen »Big Endian« und »Little Endian« Encoding unterschieden werden muss. (Anmerkung: Intel-CPUs verwenden zur Speicherorganisation intern das Little Endian Format, diejenigen von Motorola dagegen Big Endian. Auch die Programmiersprache Java favorisiert Big Endian.)

Hierbei geht es um die Reihenfolge, in der die Bytes, aus denen sich ein Zeichen zusammensetzt, gespeichert werden – höchstwertige (Big Endian) oder niederwertige Bits zuerst (Little Endian). In UTF-32 werden zwei der hier vier Bytes durch Nullwerte aufgefüllt.

Anmerkung: UTF-32 ist quasi identisch mit dem in ISO 10646 geregelten UCS-4 – eine BOM besitzt also die gleiche Form.

Kodierung	Bytefolge des BOM
UTF-8	EF BB BF
UTF-16, big-endian	FE FF
UTF-16, little-endian	FF FE
UTF-32/UCS-4, big-endian	00 00 FE FF
UTF-32/UCS-4, little-endian	FF FE 00 00

Tabelle: BOM-Bytefolgen in verschiedenen Zeichenkodierungen (Quelle: Wikipedia).

Hinweis: Ist das Encoding UTF-16, so lautet der Defaultwert "yes", ist es UTF-8 so ist der Wert abhängig von der vorliegenden Implementierung (UTF-8 benötigt kein BOM). Für alle anderen Encodings lautet der Defaultwert "no". In Nicht-Unicode-Formaten existieren keine BOM.

cdata-section-elements

Wert	{qnames} (auch als AVT)
Verwendung	optional
Einführung	XSLT 2.0

Das cdata-section-elements-Attribut ist in Verbindung mit method="xml" erlaubt. Die Wertübergabe per Attributwert-Template ist gestattet. Das Attribut nennt in Form einer durch Leerzeichen getrennten Liste die QNames all jener Elemente, deren enthaltene Textnodes im des sekundären Ergebnisdokuments innerhalb von CDATA-Sections ausgegeben werden sollen:

<![CDATA[ ... Textnode ... ]]>

Das Definieren von CDATA-Sections ist sinnvoll, wenn für Teilabschnitte des Inhalts keine Maskierung von Markup, Sonder- oder Steuerzeichen gewünscht wird, oder um Inhalte auszugeben, die die Wohlgeformtheit des Ergebnisdokuments beeinträchtigen könnten (z.B. Javascript-Code). Speziell für die Ausgabe von XHTML-Dokumenten gilt dies für die Container <script> und <style>.

Hinweis – Kein Überschreiben der Output-Deklaration für dieses Attribut:
Der Wert des cdata-section-elements-Attributs überschreibt in diesem Fall nicht eine eventuelle Angabe der betreffenden Output-Deklaration (löscht sie also nicht), sondern die hier übergebenen Elementnamen wirken zusätzlich zu den bereits festgelegten. Die Gesamtwirkung entspricht also der Vereinigungsmenge (union) beider Attributwerte.

doctype-public

Wert	{string} (auch als AVT)
Verwendung	optional
Einführung	XSLT 2.0

Das doctype-public-Attribut benennt in Verbindung mit dem doctype-system-Attribut den zusätzlichen, optionalen PUBLIC-Identifier einer Doctype-Deklaration des sekundären Ergebnisdokuments. Die Wertübergabe per Attributwert-Template ist gestattet.

Das Attribut kann sinnvoll in Zusammenhang mit allen Ausgabemethoden eingesetzt werden, die eine Doctype-Deklaration zulassen, also für "xml", "html" und "xhtml". Andernfalls wird es ignoriert.

Das Attribut von xsl:result-element überschreibt gegebenenfalls das gleichnamige Attribut der Output-Deklaration, wird aber ignoriert, wenn nicht gleichzeitig (egal, ob bei xsl:result-document oder der zugehörigen xsl:output-Deklaration) eine doctype-system-Angabe gesetzt ist.

doctype-system

Wert	{string} (auch als AVT)
Verwendung	optional
Einführung	XSLT 2.0

Das doctype-system-Attribut dient zur Vergabe eines potenziellen SYSTEM-Identifiers in Form eines URI-Strings, der in der Doctype-Deklaration des sekundären Ergebnisdokuments verwendet werden soll. Die Wertübergabe per Attributwert-Template ist gestattet.

Das Attribut kann sinnvoll in Zusammenhang mit allen Ausgabemethoden eingesetzt werden, die eine Doctype-Deklaration zulassen, also "xml", "html" und (seit XSLT 2.0) "xhtml". Andernfalls wird es ignoriert.

Das Attribut von xsl:result-element überschreibt gegebenenfalls das gleichnamige Attribut der Output-Deklaration. Ist ein doctype-system-Attribut gesetzt, so kann zusätzlich (egal, ob es bei xsl:result-document oder der zugehörigen xsl:output-Deklaration gesetzt ist) das doctype-public-Attribut wirksam werden.

encoding

Wert	{string} (auch als AVT)
Verwendung	optional
Einführung	XSLT 2.0

Das encoding-Attribut legt das im erzeugten sekundären Ergebnisdokument gültige Zeichen-Encoding fest, das die Binärkodierung der Zeichendaten beschreibt (Beispiel: UTF-8, ISO-8859-1). Die Wertübergabe per Attributwert-Template ist gestattet.

Das Attribut von xsl:result-element überschreibt gegebenenfalls das gleichnamige Attribut der Output-Deklaration. Die erlaubten Werte nennen gültige Encodingformate (charsets), wie sie nach RFC 2278 bei der IANA registriert sind. Charset-Bezeichner werden unabhängig von ihrer Schreibweise mit Groß- oder Kleinbuchstaben erkannt, d.h. der Attributwert ist nicht »case-sensitive« (Beispiel: UTF-8 und utf-8 sind äquivalent).

Wird das gewünschte Encoding nicht erkannt oder vom XSLT-Prozessor nicht unterstützt, so wird auf UTF-8 als Standard-Encoding zurückgegriffen. Die Verwendung des encoding-Attributs ist in Zusammenhang mit allen Werten von method zulässig.

escape-uri-attributes

Wert	{"yes" | "no"} (auch als AVT)
Verwendung	optional
Einführung	XSLT 2.0

Das escape-uri-attributes-Attribut legt fest, ob die Werte von Attributen vom Typ xs:anyURI in sekundären HTML- oder XHTML-Ergebnisdokumenten escaped werden oder nicht. Die Wertübergabe per Attributwert-Template ist gestattet.

Im Allgemeinen wird ein Escaping als sinnvoll erachtet – der Defaultwert des Attributs ist daher "yes".

Escaping wird gemäß der in RFC 2396 (Section 2.4.1) empfohlenen Methode vorgenommen. Nicht darstellbare Zeichen werden also durch ein Hexzahlenpärchen mit vorangestelltem %-Zeichen ersetzt (Beispiel: ein Leerzeichen wird zu %20). Neben Leerzeichen müssen Steuerzeichen und innerhalb eines URIs als Trenner (Delimiter) benötigte Zeichen escaped werden, wenn man sie in ihrer literalen Form benötigt, darunter auch das Prozentzeichen selbst: <, >, #, %, ".

format

Wert	{qname} (auch als AVT)
Verwendung	optional
Einführung	XSLT 2.0

Der Wert des format-Attributs muss ein QName sein, der dem Bezeichner einer benannten xsl:output-Deklaration entsprechen muss. Die Wertübergabe per Attributwert-Template ist gestattet. Die Bezeichner werden in ihrer expandierten Form verglichen. (Bei gleichem lokalen Bezeichner und unterschiedlichen Präfixes werden zwei Namen also dennoch als gleich angesehen, wenn sie sich auf den gleichen Namensraum beziehen.)

Ist der übergebene Wert kein gültiger QName, oder existiert keine Output-Deklaration des geforderten Namens, so meldet der Prozessor einen Laufzeitfehler (ERR XTDE1460). Wird der Bezeichner nicht im Rahmen eines AVT übergeben, so kann der Fehler auch statisch gemeldet werden.

Nennt das format-Attribut eine gültige Output-Deklaration, so wird diese zur Serialisierung des entsprechenden Dokuments herangezogen und verwendet deren Serialisierungsparameter (d.h. die Attributwerte oder deren Defaults), solange diese nicht punktuell durch gleichnamige Attribute von xsl:result-document überschrieben wurden.

Wird das format-Attribut weggelassen, so bezieht sich die xsl:result-document-Instruktion in gleicher Weise auf die namenlose xsl:output-Deklaration. Ist keine solche vorhanden, so wird das sekundäre Dokument anhand der für xsl:output vorgesehenen Defaultwerte serialisiert.

href

Wert	{uri-reference} (auch als AVT)
Verwendung	optional
Einführung	XSLT 2.0

Das href-Attribut dient dazu, den Dateinamen des Dokuments und dessen Pfad absolut oder relativ zum Basis-URI des XSLT-Stylesheet festzulegen. Die Wertübergabe per Attributwert-Template ist gestattet.

Beim Attributwert muss es sich um einen relativen oder absoluten URI-String handeln, wobei der XSLT-Prozessor gehalten ist, jeden syntaktisch korrekten URI-String zu akzeptieren.

Ein in diesem Sinne korrekter URI ist auch der leere String (als gültiger relativer URI-String), der als Defaultwert dient, falls kein href-Attribut verwendet wird. Auf diesem Wege kann auch absichtlich ein namenloses Dokument erzeugt werden, das als URI den Basis-URI aus dem statischen Kontext erhält.

Es darf nur maximal eine xsl:result-document-Instruktion ohne href-Attribut auftreten. Dies folgt zwingend daraus, dass kein zwei derartigen Instruktionen dasselbe Zieldokument besitzen dürfen (d.h. nicht den gleichen – auch keinen – Wert für das href-Attribut).

include-content-type

Wert	{"yes" | "no"} (auch als AVT)
Verwendung	optional
Einführung	XSLT 2.0

Mit Hilfe des include-content-type-Attributs kann festgelegt werden, ob der XSLT-Prozessor dem sekundären Ergebnisdokument einen Meta-Tag mit einer content-type-Description ähnlich dem folgenden hinzufügen soll:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

Die Wertübergabe per Attributwert-Template ist gestattet. Das Attribut kann für HTML- oder XHTML-Output verwendet werden, der Defaultwert ist "yes".

indent

Wert	{"yes" | "no"} (auch als AVT)
Verwendung	optional
Einführung	XSLT 2.0

Das indent-Attribut legt fest, ob im Quelltext des sekundären Ergebnisdokuments Einrückungen erfolgen sollen oder nicht. Die Wertübergabe per Attributwert-Template ist gestattet. Der Defaultwert ist "yes" für die Ausgabe in den Formaten »html« und »xhtml«. Für die Ausgabe als »xml« ist der Defaultwert hingegen "no", da Whitespace hier zunächst stets als »inhaltlich relevant« betrachtet wird. Für die Ausgabemethode »text« ist das indent-Attribut nicht anwendbar.

Die für Einrückungen erforderliche, gezielte Einfügung von Whitespace-Nodes darf (ohne das Dokument inhaltlich zu verändern) ohnehin nur zwischen Elementen vorgenommen werden. Hierbei können dort bereits vorhandene Whitespace-Nodes gegebenenfalls ersetzt werden.

Innerhalb von oder angrenzend an Textnodes dürfen Einrückungen dagegen nicht erfolgen, da das Hinzufügen von Whitespace in diesem Fall den Inhalt verändern würde (ganz trivial z.B. die Zeichenzahl eines Textnodes).

Ebenso wenig darf Whitespace in jenen Abschnitten des Ergebnisdokuments hinzugefügt werden, für die ein xml:space-Attribut mit Wert "preserve" gilt. Darüber hinaus hat das indent-Attribut keinen Einfluss auf bereits im Ergebnisdokument vorhandenen Leerraum, nimmt also im Vorfeld einer erfolgenden Einrückung weder eine Normalisierung noch ein Whitespace-Stripping vor.

media-type

Wert	{string} (auch als AVT)
Verwendung	optional
Einführung	XSLT 2.0

Das media-type-Attribut dient dazu, dem sekundären Ergebnisdokument eine entsprechende MIME-Typangabe beizufügen, die beispielsweise bei einer Übertragung des Dokuments per HTTP erforderlich sein kann. Die Wertübergabe per Attributwert-Template ist gestattet. Das Attribut kann in Zusammenhang mit allen Werten von method eingesetzt werden. Es beeinflusst nicht den Inhalt des Ergebnisdokuments, sondern, in Abhängigkeit von der Laufzeitumgebung, lediglich dessen Dateieigenschaften für Speicherung bzw. Weitergabe.

Für alle Ausgabeformate liegen Defaultwerte vor, die dann in Kraft treten, wenn das Setzen des media-type-Attributs unterbleibt. Der Defaultwert lautet für XML-Ausgabe "text/xml", für HTML- und XHTML-Ausgabe ist es "text/html", für reine Textausgabe "text/plain".

method

Wert	{"xml" | "xhtml" | "html" | "text" | qname-but-not-ncname} (auch als AVT)
Verwendung	optional
Einführung	XSLT 2.0

Das method-Attribut legt den Dokumenttyp des sekundären Ergebnisdokuments fest. Als Vorgabewerte sind hier "xml", "xhtml", "html" und "text" gestattet. Die Wertübergabe per Attributwert-Template ist gestattet.

Wird kein method-Attribut spezifiziert, so wird automatisch das Format "xml" ausgegeben, es sei denn, der Name des Wurzelelements des Ausgabebaums (final result tree) lautet <html>. In diesem Fall wird das Format "html" gewählt. Befindet sich jenes Wurzelelement zusätzlich im XHTML-Namensraum, so lautet das Format "xhtml" (erst ab XSLT 2.0; für Styleshees in XSLT 1.0 weicht der Prozessor auf das Formar "xml" aus).

Hinweis: Weitere, durch QName mit Namensraumpräfix benannte Ausgabe­formate, können durch den jeweiligen Hersteller des XSLT-Prozessors imple­mentiert werden – hierfür existiert die Option qname-but-not-ncname. Wird das Attribut eingesetzt, ihm aber keiner der festgelegten Werte und auch kein QName mit Präfix übergeben, so ist dies ein statischer Fehler (ERR XTSE1570).

method="xml"
Dieser Attributwert dient dazu, explizit XML als Ausgabe­format zu fordern. Grundsätzlich ist XML allerdings ohnehin Defaultausgabe­format für all jene Fälle, in denen das Wurzelelement des auszugebenden Dokuments nicht <html> lautet. In jenem Fall entscheidet der Namensraum des Wurzelelements, ob es, falls kein method-Attribut vorliegt, als "xhtml" oder "html" ausgegeben wird.

Die Ausgabemethode "xml" ist erforderlich, wenn XML-Dokumente oder »external general parsed Entities« erzeugt werden sollen, die einen XML-Prolog bzw. eine Textdeklaration erhalten sollen.

Default-Mediatype in Zusammenhang mit dem Ausgabeformat "xml" ist "text/xml". Mittels des doctype-system- und doctype-public-Attributes kann eine Doctype-Deklaration hinzugefügt werden (nicht jedoch eine interne Untergruppe einer DTD).

method="xhtml"
In XSLT 1.0 konnten XHTML-Doku­mente nur über den Umweg method="xml" erzeugt werden, da auch diese das Wurzelelement <html> besitzen und hierdurch nicht ohne weiteres vom Aus­gabetyp "html" unterschieden werden konnten. Der lokale Name html des Wurzelelements muss, anders als beim Format "html", zwingend in Klein­buchstaben geschrieben sein.

In XSLT 2.0 liegt ein eigenständiger Ausgabetyp "xhtml" vor, wobei der Namensraum des auszugebenden Wurzelelements berücksichtigt wird: Ent­spricht dieser mit "http://www.w3.org/1999/xhtml" dem XHTML-Namens­raum, dann ist der Default-Output auch ohne ausdrückliche Formatnennung "xhtml".

Will man XHTML-Dokumente der Typen »strict«, »transitional« oder »frameset« ausgeben, die einen von diesem Standardnamensraum abweichenden Namensraum verwenden, so empfiehlt sich daher die tatsächliche Angabe von method="xhtml".

Der Mediatype nimmt genau wie für "html" den Defaultwert "text/html" an. Alternativ kann über das Attribut media-type auch der Wert "text/xml", "application/xhtml+xml" oder "application/xml" gewählt werden. Es wird ein Meta-Tag zur Contentbe­schreibung mit diesem Mediatyp eingefügt, falls nicht das include-content-type-Attribut mit Wert "no" verwendet wird:

<meta http-equiv="Content-Type" content="text/html; charset= EUC-JP">

Als charset-Attributwert steht der Wert des encoding-Attributs, der auch in der XML-Deklaration des XHTML-Dokuments berücksichtigt wird.

Die Ausgabe der leeren HTML-Tags erfolgt – anders als beim Format "html" – XML-konform. Der Prozessor ist (derzeit) angehalten, vor dem abschlie­ßenden Slash ein Leerzeichen in die Marke einzufügen, um Abwärtskompatibili­tät zu gewährleisten.

Beispiel: <br /> statt <br/>.

Elemente, deren Inhaltsmodell nicht EMPTY ist, sollen jedoch keinesfalls in verkürzter Form dargestellt werden, auch wenn von ihnen eine leere Instanz erzeugt wird.

Beispiel: leerer Absatz immer als <p></p>, nie als <p />.

Im Gegensatz zu reinem XML-Output soll der Prozessor Zeilenumbrüche inner­halb von erzeugten oder kopierten Attributwerten entfernen und zu einem Leerzeichen normalisieren.

Leerzeichen und Sonderzeichen innerhalb von Werten von URI-Attributen wie href oder src werden automatisch gemäß den Richtlinien für URI-Escaping (RFC 3236) maskiert. Auf Wunsch kann dies mittels des Attributs escape-uri-attributes auch deaktiviert werden. (Dies macht nur dann Sinn, wenn über die XPath 2.0-Funktion fn:escape-html-uri() eine vom Standard-Escaping abweichende Variante gewählt werden soll.)

Eine Ausgabe konform zu XHTML Strict, XHTML Transitional, XHTML Frame­set oder XHTML Basic zu gewährleisten, ist Aufgabe des Stylesheet-Autors. Für den Prozessor stellen Abweichungen hiervon keinen zu meldenden Fehler dar. Mittels doctype-public und doctype-system können allerdings entspre­chende Doctype-Deklarationen eingefügt werden, um eine anschließende Vali­dierung des Ergebnisdokuments zu ermöglichen.

method="html"
Das Ausgabeformat "html" ist dann Defaultwert, wenn das Wurzelelement des Ergebnisdokuments einen Null-Namensraum und den Bezeichner <html> hat, wobei dieser sich beliebig aus Groß- und Kleinbuchsta­ben zusammensetzen darf. Innerhalb des Ergebnisdokuments werden alle Ele­mente mit Null-Namensraum wie HTML-Elemente nach HTML 4.0 ausgege­ben.

Leere HTML-Elemente werden nicht nach XML-Regeln, sondern ohne Endtag ausgegeben, sodass das Ergebnis in der Regel kein wohlgeformtes XML sein wird – die Erkennung der hierfür in Frage kommenden Elemente soll unabhän­gig von ihrer Schreibweise im Quelldokument oder Stylesheet sein (z.B. <BR/>, <br></br>, <br/> werden gleichermaßen als <br> ausgegeben).

An jenen Stellen, an denen laut HTML 4.0 minimierte (boolesche) Attribute erlaubt sind, werden diese minimiert ausgegeben

Beispiel: <hr noshade="noshade"/> ergibt <hr noshade>.

Steuerzeichen oder Zeichen, die im gewählten Ausgabe-Encoding nicht enthal­ten sind, werden durch die entsprechenden HTML-Entities ersetzt. Existiert kein solches Entity, wird das Zeichen durch ein (numerisches) Character Entity wiedergegeben. Innerhalb von auszugebenden <script>- oder <style>-Ele­menten soll ein solches Escaping jedoch unterbleiben. 

method="text"
Das Ausgabeformat "text" gibt den Stringwert des Wur­zelelements des Queldokuments aus, mit anderen Worten den Textinhalt aller Elemente in Dokumentreihenfolge. Ein Escapen von Sonderzeichen findet nicht statt. Abgesehen von den Textknoten des Quelldokuments werden alle anderen Knotentypen – also auch Attributwerte – ignoriert. Das Zeichen, das ein Zeilenende repräsentiert, wird in Abhängigkeit von der Systemumgebung gewählt, in der das Dokument erzeugt wird. 

In Zusammenhang mit method="text" werden als weitere Attribute lediglich media-type, encoding und unicode-normalisation erkannt. Sind andere Attribute gesetzt, so werden sie ignoriert.

Das media-type-Attribut nimmt den Defaultwert "text/plain" an, für das encoding-Attribut ist der Defaultwert in diesem Zusammenhang systemabhän­gig. Enthält der auszugebende Text Zeichen, die im gewählten Encoding (oder dem Default-Encoding) nicht enthalten sind, wird jedoch in jedem Fall ein Feh­ler gemeldet.

Keine »external general parsed entities« mit method="text" erzeugbar
»External general parsed entities«, die aus Plaintext mit einer voran­gestellten Textdeklaration ähnlich <?xml version="1.0"?> bestehen, können als sekundäres Ergebnisdokument nicht mit der Ausgabemethode "text", sondern müssen mit der Methode "xml" erzeugt werden. Die Möglichkeit, in Zusammen­hang mit dem Ausgabeformat "text" eine Textdeklaration auszugeben, besteht nicht.

normalisation-form

Wert	{"NFC" | "NFD" | "NFKC" | "NFKD" | "fully-normalized" | "none" | nmtoken} (auch als AVT)
Verwendung	optional
Einführung	XSLT 2.0

Mit Hilfe des Attributs normalisation-form kann eine bestimmte, für die Normalisierung des sekundären Ergebnisdokuments gewünschte Normalisierungsform angegeben werden. Die Wertübergabe per Attributwert-Template ist gestattet.

Es muss ein Nametoken aus der oben angegebenen Liste übergeben werden, oder ein NMTOKEN, das eine implementierte Normalisierungsform des Prozessors aktiviert. Der Defaultwert ist "none". Das Attribut darf in Zusammenhang mit allen Ausgabeformaten eingesetzt werden.

Wählbar sind vier verschiedene Formen der Unicode-Normalisierung, sowie die W3C-eigene Normalisierung FULLY-NORMALIZED. Auch prozessoreigene Normalisierungen sind wählbar – es ist jedoch nicht festgelegt, was geschieht, wenn das geforderte Format nicht unterstützt wird (die XPath-Funktion fn:normalize-unicode() meldet in vergleichbaren Fall einen Fehler).

Normalisierungsformen:
Der Standard verlangt von einer Applikation lediglich die Unterstützung der (meistverbreitetsten) Normalisierung nach NFC (Unicode Normalisation Form C, Kanonische Komposition), die auch vom W3C favorisiert wird:

• NFC – Unicode Normalisation Form C, kanonische Komposition 

Neben NFC existieren weitere Vorschriften, deren Bezeichnungen der Applikation bekannt sein können (aber nicht müssen):

• NFD – Unicode Normalisation Form D, kanonische Dekomposition
• NFKC – Unicode Normalisation Form KC, kanonisch-kompatible Komposition
• NFKD – Unicode Normalisation Form KD, kanonisch-kompatible Dekomposition

Nicht zum Unicode-Standard gehört eine weitere, möglicherweise durch Anwendungen unterstützte Form:

• FULLY-NORMALIZED – die Normalisierungsvorschrift des W3C; beschrieben in »Character Model for the World Wide Web 1.0«. Diese Form entspricht im Wesentlichen NFC, erlaubt jedoch als erstes Zeichen des Strings nur so genannte Base Characters (Unicode Combining Class 0). Tritt am Stringanfang ein Kombinationszeichen auf, beispielsweise ein Akzentzeichen, wird diesem (zusätzlich, als Base Character) im Zuge der Normalisierung ein Leerzeichen vorangestellt, um das Kombinationszeichen zu tragen.

Sinnvoll normalisierbar ist jeder String, der zusammengesetzte Unicode-Zeichen (Kompositzeichen) enthält. Hierunter fallen beispielsweise Ligaturen, akzentierte Zeichen oder Umlaute – so kann z.B. der Kleinbuchstabe ä mittels des einzelnen Zeichens U+00E4 LATIN SMALL LETTER A WITH DIAERESIS oder als Kombination der beiden Zeichen U+0061 LATIN SMALL LETTER A und U+0308 COMBINING DIAERESIS dargestellt werden. Die möglichen Varianten können das Ergebnis eines direkten Stringvergleichs zweier (auch im Grunde als gleich zu betrachtenden) Zeichenketten quasi unvorhersehbar machen.

Im Rahmen der Normalisierung wird zunächst eine Dekomposition zusammengesetzter Zeichen vorgenommen, anschließend deren Ersetzung durch eine kanonische (einer gleichförmigen Regel entsprechenden) Kompositdarstellung. Treten Sonderzeichen als sogenannte Singleton-Zeichen auf, die aus nur einem Unicode-Symbol bestehen (beispielsweise Å als Zeichen für »Ångstrom«), so werden sie durch ihre entsprechende kanonische Kompositform ersetzt.

Reiner ASCII-Text, und damit jeder Programm-Quellcode, bleibt bei einer erfolgenden Unicode-Normalisierung unverändert (ASCII enthält keine Kompositzeichen) – schädlich ist eine Normalisierung hier demzufolge also zwar nicht, sondern lediglich überflüssig.

Durch Unicode-Normalisierung betroffene Zeichen:
Vergleichstabellen aller von Unicode-Normalisierung betroffenen Zeichen aller Zeichensätze.

omit-xml-declaration

Wert	{"yes" | "no"} (auch als AVT)
Verwendung	optional
Einführung	XSLT 2.0

Das omit-xml-declaration-Attribut legt fest, ob die dem sekundären Ergebnisdokument durch den XSLT-Prozessor normalerweise hinzugefügte XML-Deklaration unterlassen werden soll. Die Wertübergabe per Attributwert-Template ist gestattet. Das Attribut ist nur für method="xml" zulässig und wird für andere Ausgabeformate ("text" oder "html") ignoriert Der Defaultwert ist "no". Für "yes" unterbleibt die XML-Deklaration in jedem Fall.

Die XML-Deklaration kann zusätzlich eine standalone-Deklaration umfassen, falls das entsprechende Attribut gesetzt wird. In jedem Fall ist das version-Attribut und ein entsprechendes encoding-Attribut (in der Regel mit Wert "UTF-8", falls nicht im encoding-Attribut von xsl:output anders festgelegt) enthalten.

Hinweis: Das Attribut kann nicht dazu eingesetzt werden, um für reinen Textoutput method="text" eine XML-Deklaration in Form einer sogenannten »Textdeklaration« zu erzwingen. Für ein solches »XML-Fragment« muss das Ausgabeformat auf method="xml" gesetzt sein.

output-version

Wert	nmtoken
Verwendung	optional
Einführung	XSLT 2.0

Das output-version-Attribut dient zusammen mit dem method-Attribut zur näheren Beschreibung des Versionsstandes des Ausgabeformats nach W3C-Richtlinien. Es korrespondiert mit dem version-Attribut der zugehörigen xsl:output-Deklaration (Achtung, dies ist nicht das Standardattribut version!) und überschreibt gegebenenfalls dessen Wert. Eine Wertübergabe an das Attribut per Attributwert-Template ist gestattet.

Das Attribut kann nur in Verbindung mit den Ausgabeformaten "xml", "html" und "xhtml" eingesetzt werden. Hierbei sollten ausschließlich gültige Versionsstände verwendet werden, so in Zusammenhang mit method="xml" derzeit output-version="1.0" oder output-version="1.1". Für das Ausgabeformat "text" ist output-version nicht anwendbar und wird ignoriert.

Ansonsten gelten die Defaultwerte des version-Attributs der Output-Deklaration – für method="xml" und method="xhtml" ist es version="1.0", für method="html" ist es version="4.0".

standalone

Wert	{"yes" | "no" | "omit"} (auch als AVT)
Verwendung	optional
Einführung	XSLT 2.0

Das standalone-Attribut ist in Verbindung mit method="xml" zulässig. Es bestimmt, ob und mit welchem Wert dem XML-Prolog des sekundären Ergebnisdokuments eine standalone-Deklaration hinzugefügt wird. Die Wertübergabe per Attributwert-Template ist gestattet.

Das Attribut überschreibt gegebenenfalls den Wert des gleichnamigen Attributs standalone der Output-Deklaration. Für den Wert "yes" wird der XML-Deklaration das Pseudoattribut standalone="yes" beigefügt, analog bei "no" der Wert standalone="no". Setzt man den Wert des Attributs auf "omit", so wird für das sekundäre Ergebnisdokument das Einfügen des standalone-Pseudoattributs unterdrückt (einfaches Weglassen des Attributs bewirkt hingegen das Inkrafttreten des Output-Attributs bzw. dessen Defaultwerts!).

type

Wert	QName
Verwendung	optional
Einführung	XSLT 2.0

Da der erzeugte Dokumentknoten selbst keinen Typ besitzt, wird das type-Attribut nicht unmittelbar auf diesen angewendet. Der hier übergebene QName eines Schema-Datentyps bezieht sich vielmehr auf den Typ des primären Knotens des erzeugten Dokumentbaums, also dessen Wurzelelementknoten.

Eine Wertübergabe per Attributwert-Template ist für dieses Attribut nicht gestattet. Es ist ein statischer Fehler, wenn keine Deklaration mit dem übergebenen QName existiert (ERR XTSE1520).

Das folgende Verfahren des Validierung des Wurzelelementknotens entspricht dem für Elementknoten üblichen (Anmerkung: Eine formale, allerdings recht theoretische Beschreibung des Verfahrens finden Sie in der Spezifikation zu XML Schema, Teil 1, Abschnitt 3.3.4): Ist die Validierung erfolgreich, d.h. hat das validity-Property des entsprechend erzeugten PSVI für den Knoten den Wert "valid", so wird der übergebene Datentyp mit dem Element verknüpft, andernfalls wird die Verarbeitung des Stylesheets abgebrochen (ERR XTTE1540).

undeclare-prefixes

Wert	{"yes" | "no"} (auch als AVT)
Verwendung	optional
Einführung	XSLT 2.0

Dieses Attribut wird für XML-Output verwendet, falls die auszugebende XML-Version des sekundären Ergebnisdokuments neuer als 1.0 ist (also mindestens 1.1: Für Dokumente vom Typ XML 1.0 ist eine Namensraum-Undeklaration grundsätzlich nicht möglich). Die Wertübergabe per Attributwert-Template ist gestattet.

Ab XML 1.1 kann die Tatsache, dass für ein Element weniger Namensräume im Scope sein sollen als für sein Parent-Element, bei der Serialisierung durch eine sogenannte Namensraum-Undeklaration berücksichtigt werden. Dies geschieht durch Überschreiben des zu löschenden Namensraums durch einen Null-Namensraum (leerer Namensraum-URI) im entsprechenden Element. Das Attribut undeclare-prefixes wird hierfür auf den Wert "yes" gesetzt. Wird keine Undeklaration gewünscht, so wird der Wert "no" verwendet. Das Defaultverhalten ist anhängig von der jeweiligen Implementierung des Prozessors.

use-character-maps

Wert	qnames
Verwendung	Optional
Einführung	XSLT 2.0

Das Attribut use-character-maps nennt in Form einer Tokenliste die QNames benannter xsl:character-map-Deklarationen, die in Verbindung mit der Output-Deklaration verwendet werden sollen. Das Attribut ist in Verbindung mit allen Ausgabeformaten einsetzbar. Eine Wertübergabe per Attributwert-Template ist für dieses Attribut nicht gestattet.

Ein Character-Mapping ermöglicht während der Serialisierung die Ersetzung eines beliebigen direkt verwendeten oder im Quelldokument oder Stylesheet durch ein Character Entity dargestellten Zeichens durch einen definierbaren Ausgabestring.

Innerhalb von benannten Charactermaps kann ein Zeichen jeweils einem String zugeordnet werden. So kann das Entity &#160; (geschütztes Leerzeichen) unmittelbar durch den String &amp;nbsp; ersetzt werden. Ebenfalls möglich ist so die Kontrolle des Zeilenumbruchs, indem der LF-Zeilenumbruchbefehl &#xA; für Windows-Umgebungen durch den String &#xD;&#xA; (Folge aus CR und LF) ersetzt wird.

Es ist zu beachten, dass bei der Durchführung des Character-Mappings nicht geprüft wird, ob das Ergebnis gegen die Wohlgeformtheitsregeln verstößt, da die Strings literal »wie sie sind« eingesetzt werden.

Hinweis – Kein Überschreiben der Output-Deklaration für dieses Attribut:
Der Wert des use-character-maps-Attributs überschreibt in diesem Fall nicht eine eventuelle Angabe der betreffenden Output-Deklaration (löscht sie also nicht), sondern die hier übergebenen Charactermap-Bezeichner wirken zusätzlich zu den bereits festgelegten. Die Gesamtwirkung entspricht also der Vereinigungsmenge (union) beider Attributwerte.

validation

Wert	"strict" | "lax" | "preserve" | "strip"
Verwendung	optional
Einführung	XSLT 2.0

Das validation-Attribut bestimmt, ob und gemäß welcher Vorschrift das Wurzelelement des Dokumentknotens des erzeugten Dokumentbaums validiert wird. Eine Wertübergabe per Attributwert-Template ist für dieses Attribut nicht gestattet.

Es gibt dabei keinen direkten Defaultwert: Bei Abwesenheit des Attributs wird stattdessen der Wert des default-validation-Attributs des Stylesheetelements (xsl:stylesheet oder xsl:transform) verwendet, in dem sich die Instruk­tion befindet. Ist das default-validation-Attribut im Stylesheetelement nicht gesetzt, so gilt dessen Defaultwert "strip".

Die vier möglichen expliziten Werte des validation-Attributs sind strict, lax, preserve und strip – sie haben im Einzelnen folgende Wirkung:

validation="strict"
Der Wert strict erzwingt eine strikte Validierung des Wurzelelements des Dokumentbaums gemäß eines Schemas. Das ent­sprechende Wurzelelement und sein erlaubter Inhalt müssen also in einem Schema deklariert sein, das an dieser Stelle mit Hilfe der in XML Schema üblichen Methoden zur Verfügung stehen muss. Dies kann beispielsweise implizit über den verwendeten Namensraum oder explizit für dessen Ele­mente über ein ihnen beigefügtes xsi:schemaLocation-Attribut geschehen. Das so für den Knoten ermittelte validity-Property im Rahmen des ent­sprechenden PSVI muss den Wert "valid" besitzen – in diesem Fall erhält das Wurzelelement die entsprechende Typbindung. Bestehende Typbindun­gen innerhalb des Dokumentbaums bleiben erhalten.

Hat das Property den Wert "invalid" oder "notKnown", so schlägt die Transformation an dieser Stelle mit einem Typfehler (type error) fehl. Ein Typfehler tritt ebenfalls auf, wenn der Inhalt des Dokumentknotens neben einem einzigen Elementknoten (dem Wurzelelement) nicht ausschließlich aus Kommentar und PI-Knoten besteht.

validation="lax"
Der Wert lax erfordert eine Validierung des Wurzel­elements des Dokumentbaums gemäß eines zur Verfügung stehenden Sche­mas – allerdings ist es kein Fehler, wenn kein solches Schema zur Verfügung steht oder das Wurzelelement im Rahmen eines vorhandenen Schemas nicht deklariert ist. Das für den Knoten ermittelte validity-Property darf also neben "valid" auch den Wert "notKnown" besitzen. In letzterem Fall wird dem (nicht validierten) Wurzelelement der Typ xdt:untyped zugewiesen. Die bestehenden Typbindungen innerhalb des Dokumentbaums bleiben erhalten.

Hat das validity-Property dagegen den Wert "invalid", so schlägt die Transformation an dieser Stelle mit einem Typfehler (type error) fehl. Ein Typfehler tritt ebenfalls auf, wenn der Inhalt des Dokumentknotens neben einem einzigen Elementknoten (dem Wurzelelement) nicht ausschließlich aus Kommentar und PI-Knoten besteht.

validation="preserve"
Der Wert preserve erhält im validierten Dokumentbaum die Bindung von Elementen und Attributen an bestimmte Datentypen, sofern diese explizit erfolgt ist. Eine explizite Bindung kann bei­spielsweise durch Verwendung des validation-Attributes bei xsl:element oder xsl:copy-of vorgenommen worden sein. Für alle anderen Element- und Attributknoten wird eine eventuelle Typbindung aufgelöst – ihnen wird der Datentyp xs:anyType für Elemente und xs:anySimpleType für Attri­bute zugewiesen. Dies entspricht für diese Knoten dem Verhalten bei vali­dation="none".

validation="strip"
Der Wert strip löst für alle Knoten innerhalb des validierten Dokumentbaums jegliche erfolgte Datentypbindung und weist allen Elementknoten den Typ xs:untyped und allen Attributknoten den Typ xs:anySimpleType zu.

Verwendungszweck:

Die Instruktion xsl:result-document wird eingesetzt, um neben dem, während der Transformation primär erzeugten, Ergeb­nisbaums (principal result tree) noch weitere sogenannte sekundäre Ergebnis­bäume zu erzeugen. Sie schließt hiermit eine in XSLT 1.0 lange schmerzlich bemerkte Lücke, für die es allerdings eine Reihe von proprietären, prozessorbe­zogenen Lösungen in Form von Erweiterungsfunktionen gab (xt:document für XT, saxon:output für Saxon, exslt:document im Rahmen der EXSLT-Erweite­rungen).

Mittels der xsl:result-document-Instruktion ist es nunmehr möglich, Doku­mente zu erstellen oder zu verändern, ohne auf prozessorspezifische Erweite­rungen zurückgreifen zu müssen. Das so erzeugte Dokument muss nicht zwangsläufig ein XML-Dokument sein – in Verbindung mit benannten xsl:output-Deklarationen, auf die verwiesen werden kann, ist es genauso möglich, einfache Textdateien zu erzeugen (seien es CSV-Dateien, SQL-Anwei­sungen oder ähnliches).

Keine Auswirkung im primären Ergebnisbaum
Zum primären Ergebnis­baum trägt die xsl:result-document-Instruktion nichts bei (technisch ausge­drückt gibt sie in die seiner Serialisierung zugrunde liegende Sequenz eine leere Sequenz aus), sodass diesem Baum durch Auswertung der Instruktion keine Knoten hinzugefügt werden (können).

Keine Ausgabe in temporäre Bäume möglich
Eine wesentliche Einschrän­kung in Bezug auf den Einsatz der xsl:result-document-Instruktion besteht darin, dass sie ihren Ergebnisbaum nicht als tempörären Baum, sondern nur in Form eines finalen sekundären Ergebnisbaums erzeugen kann. Dies soll gewährleisten, dass Stylesheets und die von ihnen erzeugten Ergebnisse auch dann konstant bleiben, wenn die Reihenfolge der Auswertung der xsl:result-document-Instruktionen verändert wird (z.B. im Zuge einer Per­formance-Optimierung).

Innerhalb von XSLT-Instruktionen, deren Ergebnis ein temporärer Baum ist, kann die Instruktion xsl:result-document daher nicht angewendet werden. Hierzu zählen xsl:variable, xsl:param und xsl:function. (Muss ein validierbares Dokument als temporärer Baum erzeugt werden, so kann dies mittels der Instruktion xsl:document geschehen.)

Weitere Instruktionen, in denen die Instruktion verboten ist, sind xsl:with-param, xsl:attribute, xsl:comment, xsl:processing-instruction, xsl:namespace und xsl:message.

URI des sekundären Dokumentbaums
Jede xsl:result-document-Instruk­tion erzeugt bei ihrer Instanziierung einen Document Node und hängt an die­sen den durch den Sequenzkonstruktor innerhalb der Instruktion erzeugten Baum an. Mittels des optionalen href-Attributs kann ein URI des Dokument­baums festgelegt werden. Dies kann ein absoluter oder ein relativer URI sein. Befindet sich bereits eine Datei am angegebenen Ziel, so wird sie bei der Seri­alisierung überschrieben, andernfalls wird, sofern entsprechende Schrei­brechte bestehen, eine neue Datei erstellt.

Innerhalb eines Stylesheets dürfen allerdings keine zwei xsl:result-docu­ment-Instruktionen den gleichen URI verwenden. Ist der übergebene URI-Wert ein relativer URI (auch der leere String), so wird er gegenüber dem Basis-URI des statischen Kontextes aufgelöst.

Validierung des Ergebnisbaums:
Die Validierung eines sekundären Ergeb­nisbaums ist möglich. Sie geschieht vor der Serialisierung des Baums und wird vom Wert des validation-Attributes bestimmt oder, falls kein solches vorhan­den ist, von dem des default-validation-Attributs des xsl:stylesheet-Ele­ments.

Ist der Wert des validation-Attributs "strict" oder "lax", so wird dann ein Typfehler gemeldet, wenn der Inhalt des Dokumentknotens nicht aus genau einem Elementknoten besteht sowie optional aus zusätzlichen Kommentar- und PI-Knoten in beliebiger Zahl und Reihenfolge.

Die eigentliche Validierung erfolgt nicht in Bezug auf den Dokumentknoten, sondern auf sein Child-Element, das Dokumentelement. Nur dieses wird vali­diert – seine im Baum vorhandenen Kindknoten werden jedoch ohne weitere Änderung übernommen. Liegen vom zugrunde gelegten Schema her Bedingun­gen (constraints) für das validierte Element vor (in Form von xs:key-, xs:key­ref- oder xs:unique-Definitionen im Schema), so werden diese berücksichtigt und ihre Einhaltung muss gewährleistet sein.

Zeitpunkt und Format der Serialisierung:
Jedes dieser sekundären Doku­mente wird erst dann serialisiert, wenn die Gesamttransformation abge­schlossen ist. Dies beugt erstens der Möglichkeit vor, dass nach der Instanziie­rung einer xsl:result-document-Instruktion die Transformation fehlschlägt. Zweitens besteht außerdem die Möglichkeit, ein und dasselbe XML-Dokument über die document()-Funktion als Datenquelle und – nach erfolgter Transfor­mation - mittels xsl:result-document wiederum als Schreibziel zu verwen­den.

Das format-Attribut kann darüber hinaus die der Serialisierung zu Grunde zu legende xsl:output-Deklaration nennen. Dies ermöglicht, aus einer einzigen Transformation Ergebnisdokumente verschiedenen Typs zu generieren. Es wäre somit denkbar, gleichzeitig einen HTML-Frameset mit entsprechenden Inhaltseiten (mit method="html" oder "xhtml" und media-type="text/html") und zusätzlich darin eingebettete Illustrationen im SVG-Format (mit method="xml" und media-type="image/svg+xml") zu erstellen.

Hinweis – Sekundäre Ergebnisdokumente und Schreibrechte:
Die Erzeugung von mehreren Ergebnisdokumenten im Zuge einer Transformation wird in der Regel auf Umgebungen beschränkt sein, die dem XSLT-Prozessor Schreibrechte auf das Dateisystem gewähren. Dies wird voraussichtlich bei browsergestützter XSLT-Transformation (wie sie von Internet Explorer und Mozilla unterstützt werden) problematisch sein.

Beispiele:

Beispiel 1 – Erzeugung eines HTML-Framesets:

XML-Dokument:

<beispiel>Hallo Welt!</beispiel>

Stylesheet:

<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
  <xsl:output method="html"/>
  <xsl:output name="inhalt" method="html" indent="no"/>
  <xsl:template match="/">
    <!-- Frameset schreiben: -->
    <html>
      <frameset rows="*,*">
        <frame name="oben" src="oben.html" />
        <frame name="unten" src="unten.html" />
      </frameset>
    </html>
    <!-- Inhalte schreiben: -->
    <xsl:result-document format="inhalt" href="oben.html">
      <html>
        <body bgcolor="red">
          <h1><xsl:apply-templates/></h1>
        </body>
      </html>
    </xsl:result-document>
    <xsl:result-document format="inhalt" href="unten.html">
      <html>
        <body bgcolor="blue">
          <p><xsl:apply-templates/></p>
        </body>
      </html>
    </xsl:result-document>
  </xsl:template>
</xsl:stylesheet>

Dieses Stylesheet erzeugt als primäres Ergebnisdokument zunächst ein Framesetdokument und anschließend mittels xsl:result-document zwei sekundäre Ergebnisdokumente, die als Inhaltsdokumente in ersterem referenziert sind. Für die Inhaltsdokumente wird eine benannte xsl:output-Deklaration eingesetzt.

Beispiel 2 – Update einer in XML gespeicherten Information:

Datenquelle 'zaehler.xml':

<zaehler>100</zaehler>

Stylesheet:

<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <xsl:variable name="zaehler" select="number(document('zaehler.xml')/zaehler)"/>
    <html>
      <body>
        <p><xsl:text>Der aktuelle Z&#228;hlerstand ist: </xsl:text><!-- Zaehlerstand auslesen --><xsl:value-of select="$zaehler"/></p>
      </body>
    </html>
    <xsl:result-document href="zaehler.xml">
      <!-- neuen Zaehlerstand schreiben -->
      <zaehler><xsl:value-of select="$zaehler + 1"/></zaehler>
    </xsl:result-document>
  </xsl:template>
</xsl:stylesheet>

Hier wird dasselbe XML-Dokument gleichermaßen als Datenquelle wie als Ziel des Schreibvorgangs verwendet. Dies kann auch parallel zu einer Transforma­tion geschehen, die ein primäres Ergebnisdokument erzeugt und auf diesem Wege beispielsweise die Anzahl der Aufrufe des Stylesheets dokumentiert.

Dieses Beispiel beschränkt sich darauf, eine kleine XML-Datei, die den Zähler­stand beinhaltet, mittels der document()-Funktion einzulesen und in einer Variable abzulegen. Diese Variable wird beim Instanziieren von xsl:result-document ausgelesen, der Zählerstand wird inkrementiert und ein neues XML-Dokument mit dem geänderten Zählerstand erzeugt, der das ursprüngliche überschreibt und damit ersetzt.

Elementdefinition:

XSLT 1.0:

Element in XSLT 1.0 nicht verfügbar.

XSLT 2.0:

<!-- Category: instruction -->
<xsl:result-document
  format? = {qname}
  href? = {uri-reference}
  validation? = "strict" | "lax" | "preserve" | "strip"
  type? = qname
  method?={"xml" | "html" | "xhtml" | "text" | qname-but-not-ncname}
  byte-order-mark? = {"yes" | "no"}
  cdata-section-elements? = {qnames}
  doctype-public? = {string}
  doctype-system? = {string}
  encoding? = {string}
  escape-uri-attributes? = {"yes" | "no"}
  include-content-type? = {"yes" | "no"}
  indent? = {"yes" | "no"}
  media-type? = {string}
  normalization-form?={"NFC" | "NFD" | "NFKC" | "NFKD" | "fully-normalized"|"none"|nmtoken}
  omit-xml-declaration? = {"yes" | "no"}
  standalone? = {"yes" | "no" | "omit"}
  undeclare-prefixes? = {"yes" | "no"}
  use-character-maps? = qnames
  output-version? = {nmtoken}>

  <!-- Content: sequence-constructor -->
</xsl:result-document>

Hinweis: Alle zwanzig Attribute von xsl:result-document sind optional. Lediglich die Attribute type, use-character-maps und validation lassen kein Attributwert-Template zu. Bis auf die Attribute format, href, type und validation korrespondieren alle Attribute mit einem gleichnamigen Attribut einer Output-Deklaration xsl:output und überschreiben gegebenenfalls dessen Wert. Einzig output-version korrespondiert bei xsl:output aus historischen Gründen mit dessen version-Attribut.

   

<< zurück

vor >>