XML-Glossar

(Auszug aus "XSLT 2.0 & XPath 2.0" von Frank Bongers, Anhang C.)

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

 

Im Glossar finden sich Kurzerläuterungen zu einer Reihe von Fachausdrücken und Konzepten, die im Gesamtzusammenhang von XML bzw. XSLT von Bedeutung sind. Einen Anspruch auf Vollständigkeit erhebt diese Auflistung nicht. Wo möglich, wurden weiterführende Links angegeben.

A

Abbreviated Syntax

→ Abgekürzte Schreibweise (Achsen)

Abgekürzte Schreibweise (Achsen)

Im Rahmen eines → Location-Steps kann die jeweilige Bewegungsrichtung (→ Achse) entweder in vollständiger Schreibweise oder in abgekürzter Schreibweise (abbreviated syntax) geschrieben werden. Ein Location-Step, der auf ein Attribut beliebigen Namens zielt, wird in vollständiger Schreibweise beispielsweise attribute::* notiert. Die entsprechende abgekürzte (abbreviated) Schreibweise wäre in diesem Fall @*. Andere Kürzel sind . für self::, .. für parent:: und // für descendant-or-self::. Die gekürzte Schreibweise für child:: besteht im Weglassen des Achsenbezeichners vor dem → NameTest, was die Child-Achse implizit zur Default-Achse (Vorzugsrichtung) macht.

Absoluter Location Path

→ Location Path, absoluter

Achse

Unter Achsen (Axis) versteht man in XPath die definierten Bewegungsrichtungen beim Traversieren von Dokumentbäumen. Es gibt insgesamt dreizehn unterscheidbare Achsen, von denen – ausgehend von einem beliebigen Kontextknoten – drei die Bewegung abwärts im Baum beschreiben (Child-, Descendant-, Descendant Or-Self-Achse), drei die Bewegung aufwärts (Parent-, Ancestor-, Ancestor-Or-Self-Achse), eine (die Self-Achse) nur den Kontextknoten umfasst und je zwei in bzw. gegen die Dokumentreihenfolge alle benachbarten Knoten derselben Hierarchie-Ebene (Following-Sibling-, Preceding-Sibling-Achse) oder alle vorausgehenden oder folgenden Knoten (Following- bzw. Preceding-Achse) umfassen. Eine weitere Achse umfasst die Attributknoten (→ Attributachse) und eine die Namensraumknoten (→ Namespace-Achse). Default-Achse ist die → Child-Achse.

Aktueller Knoten

→ Current Node

Aktueller Nodeset

→ Nodeset, aktueller

Ancestor-Achse

Die Ancestor-Achse (ancestor::) umfasst alle Vorfahren des → Kontextknotens, nicht aber diesen selbst. Sie zielt in Gegenrichtung zur → Dokumentreihenfolge (document order) in Richtung auf den → Document Node, den sie ebenfalls beinhaltet. Für diese Achse existiert keine → abgekürzte Schreibweise.

Ancestor-Or-Self-Achse

Die Ancestor-Or-Self-Achse (ancestor-or-self::) umfasst alle Vorfahren des → Current Node und auch diesen selbst. Sie zielt in Gegenrichtung zur → Dokumentreihenfolge (document order) in Richtung auf den → Document Node, den sie ebenfalls beinhaltet. Für diese Achse existiert keine → abgekürzte Schreibweise.

Attribut

→ Attributknoten

Attribut-Achse

Die Attribut-Achse (attribute::) zielt von einem Element in Richtung auf dessen Attribute, die sie alle erfasst. Im Gegensatz zu einer → Nodesequenz aus Elementen gibt es für die Zusammenstellung einer Nodesequenz aus Attributen keine definierte (d.h. vorhersagbare) Reihenfolge. Es ist jedoch Konvention, dass Attributknoten in der Reihenfolge abgearbeitet werden, in der sie im Quelltext im Starttag des Elements auftreten. Die → abgekürzte Schreibweise für den Attribut-Achsenbezeichner lautet @.

Attributknoten

Ein Attribut eines Elements wird im Dokumentbaum durch einen Attributknoten repräsentiert, dessen → QName dem Attributnamen und dessen Stringwert dem Attributwert entspricht. Dieser Knotentyp unterscheidet sich von den restlichen Knotentypen (mit Ausnahme der → Namespace-Knoten) dadurch, dass er nicht als Kindknoten seines Elternelements gilt. Aus diesem Grund ist er von seinem Elternelement nicht über die → Child-Achse, sondern über eine separate → Attributachse erreichbar. Ein Element gilt dagegen durchaus als → Parent seines Attributs. Der Wert eines Attributs kann typisiert sein, d.h. über ein → Schema mit einem → Datentyp verknüpft werden.

Attributset

Unter einem Attributset versteht man eine Kollektion von Attributen, die als Gesamtes vom → XSLT-Prozessor einem Element im Ergebnisdokument beigegeben werden kann. Definiert wird ein Attributset mit der Deklaration xsl:attribute-set und aufgerufen über ihren, dort mit name-Attribut vereinbarten Bezeichner. Mehrere Attributsets können gleichzeitig auf ein Element angewendet werden und addieren sich dann. Ihre Bezeichner werden in diesem Fall in Form einer → Tokenliste übergeben.

Attribute Value Template

→ Attributwert-Template

Attributwert-Template

Mit dem Begriff Attributwert-Template (Attribute Value Template, AVT) wird ein Konstrukt bezeichnet, das es dem → XSLT-Prozessor ermöglicht, zur Laufzeit einen XPath-Ausdruck (→ Expression) zu verarbeiten, der stellvertretend für einen zu ermittelnden Wert eines Attributs innerhalb eines → Literal Result Elements oder bestimmter Attribute einiger XSLT-Instruktionen steht. Ein Attributwert-Template wird von geschweiften Klammern umgeben, die selbst aber nicht zum auszuwertenden XPath-Ausdruck gehören: attributname="{expression}".

Ausdruck, XPath-Ausdruck

→ Expression

AVT, AWT

→ Attributwert-Template

Axis

→ Achse

nach oben

B

Base64

Das Format Base64 ist eine Codierung für Binärdaten, ursprünglich zur Übertragung von E-Mail-Textkörpern. Base64 besteht lediglich aus 64 Codierungszeichen (A-Z, a-z, 0-9, +, /), die eine Teilmenge von US-ASCII darstellen. Es gehört als base64Binary zu den in → XML Schema integrierten Datentypen.

Base-URI

→ Basis-URI

Basic XSLT Processor

→ XSLT-Prozessor

Basis-URI

Der Basis-URI stellt den absoluten Adressbezugspunkt für einen Knoten dar. Im Falle eines Elementknotens handelt es sich um die absolute Adresse der Dokument-Entität, die das betrachtete Element enthält. Im Allgemeinen ist dies identisch mit der absoluten Adresse des Dokuments, kann für dieses jedoch auch mittels des xml:base-Attributs beliebig festgelegt werden (W3C Recommendation zu XML Base).

Ist das betrachtete Element Teil einer externen, eingebundenen Entität, so entspricht sein Basis-URI dem der externen Entität. Ein Attribut erbt seinen Basis-URI von dem Element, zu dem es gehört.

Das Konzept des Basis-URI ist von elementarer Bedeutung bei der Auflösung von URIs zu externen → unparsed Entities mittels der Funktion unparsed-entity-uri(). Diese bedient sich eben des Basis-URI, um eine auswertbare Relation zwischen Dokument und externer Ressource zu gewährleisten. Ebenso beziehen sich relative XLinks eines XML-Dokuments auf den Basis-URI.

Baum

→ Dokumentbaum

boolean

→ Boolescher Wert

Boolesche Ausdrücke

Ein Boolescher Ausdruck ist ein XPath-Ausdruck, dessen Auswertung einen Booleschen Wert (true oder false) ergibt. Innerhalb eines booleschen Ausdrucks können logische Operatoren wie and und or mehrere Operanden verknüpfen, die selbst boolesche Werte darstellen.

Boolesche Negation

In XPath wird die boolesche Negation (Verneinung) eines Ausdrucks mit der Funktion not() erzielt, als deren Argument der zu verneinende Ausdruck dient. Dies entspricht dem unären Operator !, wie er in verschiedenen Programmiersprachen verwendet wird. Man sollte sich jedoch des Unterschieds zwischen den Ausdrücken not(a = b) und a != b bewusst sein, der dann zu Tage tritt, wenn einer der Operanden nicht existiert.

Boolescher Wert

Der boolesche Wert, auch als Wahrheitswert bezeichnet, gehört zu den sogenannten primitiven Datentypen. Er kann nur die beiden Werte »wahr« (true) und »unwahr« (false) annehmen. Diese beiden Werte gehören zu den unveränderlichen Literalen. In XPath-Ausdrücken sind die Werte nicht direkt einsetzbar, sondern werden durch die Funktionen fn:true() bzw. fn:false() als deren Rückgabewerte zur Verfügung gestellt. Durch die Funktion fn:boolean() kann ein beliebiger Datentyp in einen booleschen Wert umgewandelt werden. Dasselbe geschieht implizit mit den Ergebnissen von XPath-Ausdrücken in entsprechendem Kontext, beispielweise dem test-Attribut von xsl:if oder xsl:when. Die → Predicates innerhalb eines Location-Steps ergeben stets einen booleschen Wert.

Built-In Template Rule

Template-Regeln, eingebaute

nach oben

C

CDATA

Unter CDATA (Character Data) sind alle in Unicode gültigen Zeichen zu verstehen, die im Rahmen von Textknoten und Attributwerten erlaubt sind. Welche Zeichen der XML-Parser erlaubt, hängt auch vom vereinbarten Zeichensatz, der sogenannten → Encodierung ab. Im Rahmen von → DTDs wird mit CDATA das liberalste → Inhaltsmodell für Attribute beschrieben, das eine Zeichenkette aus sämtlichen erlaubten Zeichen inklusive → Whitespace-Zeichen zulässt.

CDATA-Abschnitte

CDATA-Abschnitte, auch als CDATA-Blöcke bezeichnet, dienen in XML-Dokumenten dazu, solche Textbereiche zu markieren, die nicht geparst werden sollen. Innerhalb dieser Bereiche werden also die üblichen Steuerzeichen wie normale Textzeichen behandelt und demzufolge weder Entities expandiert noch Markup erkannt. Ein CDATA-Bereich braucht nicht deklariert zu werden, sondern wird, vergleichbar mit einem Kommentar durch eine festgelegte Zeichenfolge, eingeleitet und beendet: <[CDATA[ ... der CDATA-Bereich ... ]]>.

Analog zur Regelung bei → Kommentaren darf die beendende Zeichenfolge ]]> nicht im Inhalt des markierten Bereichs auftreten; CDATA-Bereiche können aus diesem Grund nicht verschachtelt werden. Eine Einsatzmöglichkeit besteht darin, Quellcode-Abschnitte oder Programmcode in XML-Dokumenten einzufügen, die sonst gegen das Wohlgeformtheitsgebot verstoßen würden.

Character Data

→ CDATA

Character Reference

Eine Character Reference kann, analog zu einer Entity-Referenz, verwendet werden, um in einem XML-Dokument Zeichen einsetzen zu können, die nicht in dessen, durch sein encoding-Attribut (→ Encodierung) zugelassenen Zeichensatz erlaubt sind. Die allgemeine Schreibweise einer Character Reference entspricht der einer Entity-Referenz, wobei anstelle des Entity-Bezeichners der (wahlweise) dezimal oder hexadezimal geschriebene Unicode-Bezeichner des gewünschten Zeichens steht, beispielsweise &#169; (dezimal) oder &#xA9; (hexadezimal) für das Copyright-Symbol ©.

Child-Achse

Die Child-Achse (child::) umfasst, ausgehend von einem Kontextknoten, alle dessen → Kindknoten, aber nicht den Kontextknoten selbst. Die abgekürzte Schreibweise der Child-Achse besteht im Weglassen des Achsenbezeichners im Location Step. Anstelle von child::beispiel kann man daher einfach beispiel schreiben. In diesem Fall erfasst man damit alle Elemente <beispiel>, die Kindknoten des Kontextknotens sind.

Collation

Mit Hilfe einer Collation kann eine explizite Steuerung des Verhaltens des XSLT-Prozessors für Stringvergleiche vorgenommen werden. Soll der Prozessor vom Standardverhalten abweichen (weil etwa Texte in einer bestimmten, dies erfordernden Sprache verarbeitet werden), so können entsprechende Vorschriften in Form einer Collation eingebunden werden. Hierfür steht in vielen, der für Stringverarbeitung verwendeten XPath-Funktionen (ab XPath 2.0) ein entsprechendes optionales Argument zur Verfügung, mit dem ein Collation-Bezeichner, in der Regel in der Form eines URI, übergeben wird.

Mit Hilfe einer Collation wird das Ergebnis von Stringvergleichen beschrieben, auf denen die Sortierung von Zeichenketten oder die Bestimmung ihrer Gleichheit entsprechend der definierten Regeln (z.B. »Jäger« = »Jaeger«) beruhen. Wird keine Collation eingebunden, so verwenden die Funktionen eine entsprechende Default-Collation der Systemumgebung oder aber die Unicode Codepoint Collation, wie vom W3C folgendermaßen identifiziert: www.w3.org/2003/11/xpath-functions/collation/codepoint (Wie jeder Namensraum-URI zeigt dieser URI nicht auf eine reale Ressource.)

Comment Node

→ Kommentarknoten

Current Destination Node

Der Current Destination Node ist der (Element-)Knoten, in den aktuell beim Serialisieren eines Ergebnisdokuments geschrieben wird. Ein im Ergebnisbaum erzeugter Knoten wird zum Kindknoten des Current Destination Nodes. Existiert im Augenblick eines Schreibvorgangs kein Current Destination Node, so wird ein Document Node für einen neuen Ergebnisbaum erzeugt.

Current Node

Unter Current Node (aktueller Knoten) ist der momentan vom XSLT-Prozessor verarbeitete Knoten einer zuvor durch xsl:apply-templates oder xsl:for-each zusammengestellten Nodesequenz zu verstehen. Seine Position innerhalb der → aktuellen Knotenliste (Current Node List) kann mit der Funktion fn:position() festgestellt werden. Der Current Node (bzw. allgemeiner, das Current Item) ist über die → Self-Achse mit self::node() oder dem Kürzel . erreichbar. In den meisten Fällen, ausgenommen in XPath-Predicates, ist er mit dem Kontextknoten identisch, kann in Zweifelsfällen aber mit der Funktion current() von diesem unterschieden werden.

Context Node

→ Kontextknoten

Context Position

→ Kontextposition

Context Size

→ Kontextgröße

Current Node List

→ Knotenliste, aktuelle

Current Output Destination

Unter Current Output Destination ist der Ausgabebaum zu verstehen, in den aktuell geschrieben wird, bzw. ein dort offenes Element (→ Current Destination Node). In der Regel wird dies der Baum des → Ergebnisdokuments sein, es kann sich allerdings, beispielsweise beim Auswerten des Templatekörpers einer Variable xsl:variable auch um einen temporären Baum (→ Result Tree Fragment) handeln, der nicht sofort in das Ergebnisdokument gelangt. Ab XSLT 2.0 sind mit Hilfe von xsl:result-document auch mehrere Ergebnisbäume möglich (unter XSLT 1.0 nur mit Erweiterungsinstruktionen).

Current Template Rule

Unter Current Template Rule (aktuelle Template-Regel) ist das Template-Element zu verstehen, dessen match-Attribut auf einen Knoten passt, der im Rahmen eines durch xsl:apply-templates zur Verarbeitung angebotenen wird. Für die Laufzeit der Verarbeitung dieses Knotens, der damit zum Current Node wird, gilt das Template als »aktuelles« Template. Durch Aufruf eines benannten Templates mit xsl:call-template wechselt das aktuelle Template (und damit der Current Node) nicht.

nach oben

D

Datentypen

XPath 2.0 ist, im Gegensatz zu XPath 1.0, eine stark typisierte (strong typed) Sprache. Funktionen und Operatoren erwarten entsprechend bestimmte Datentypen für ihre Eingangswerte und brechen die Verarbeitung bei Verstoß gegen den erwarteten Eingangstyp mit einem → Typfehler (type error) ab.

Die in XPath 2.0 gültigen Datentypen entsprechen den aus → XML Schema bekannten Typen xs:anySimpleType, xs:string, xs:float, xs:double, xs:decimal, xs:duration, xs:yearMonthDuration, xs:dayTimeDuration, xs:dateTime, xs:time, xs:date, xs:gYearMonth, xs:gYear, xs:gMonthDay, xs:gDay, xs:gMonth, xs:boolean, xs:base64Binary, xs:hexBinary, xs:anyURI, xs:QName und xs:NOTATION. Als Ergänzung zu den Typen aus XML Schema existieren die (ursprünglich in XPath mit Präfix xdt definierten) Datentypen xs:anyAtomicType, xs:untyped, xs:untypedAtomic.

Um diese Typen als zu XML Schema gehörig zu kennzeichnen, werden sie mit dem Präfix xs versehen, das an den Namensraum-URI von XML Schema gebunden ist: xmlns:xs="http://www.w3.org/2001/XMLSchema"

Default Namespace

Der Default Namespace gilt innerhalb von XML-Dokumenten für alle Elemente, die keine besondere Kennzeichnung durch ein → Namensraumpräfix mit zugeordnetem → Namensraum-URI besitzen. Der URI für den Default-Namensraum wird durch das Attribut xmlns="defaultnamensraum-URI" vereinbart, er gilt für das Element, in dem er steht, und für alle in diesem enthaltenen präfixlosen Elemente, nicht aber für dessen Attribute. Gewöhnlich wird der Default-Namensraum im → Wurzelelement eines Dokuments vereinbart.

Descendant-Achse

Die Descendant-Achse (descendant::) umfasst alle Kindknoten des Kontextknoten und deren Kinder und Kindeskinder – mit anderen Worten, alle vom Kontextknoten in → Dokumentreihenfolge ausgehenden Zweige des Dokumentbaums mit allen ihren Knoten (ausgenommen Attributknoten und Namensraumknoten). Der Kontextknoten selbst ist in dieser Menge nicht enthalten. Für diese Achse existiert keine → abgekürzte Schreibweise.

Descendant-Or-Self-Achse

Die Descendant-Or-Self-Achse (descendant-or-self::) umfasst den Kontextknoten selbst und alle seine Kinder und Kindeskinder – mit anderen Worten, einschließlich des Kontextknotens alle von diesem in → Dokumentreihenfolge ausgehenden Zweige des Dokumentbaums mit allen ihren Knoten (ausgenommen Attributknoten und Namensraumknoten). Die → abgekürzte Schreibweise für die Descendant-Or-Self-Achse ist //.

Deserialisierung

Unter Deserialisierung versteht man das Aufbauen eines → Dokumentbaums aus einem Quelltext. Die in → Dokumentreihenfolge auftretenden Tag-Container werden in hierarchisch angeordnete Knoten umgesetzt.

Defaultwert

Ein Defaultwert ist eine, oft implizite Voreinstellung eines Werts – mit anderen Worten ein Vorgabewert. Vorgabewerte findet man beispielsweise bei Attributen, sie werden in diesem Falle in der → DTD festgelegt. Im Rahmen von XSLT werden Defaultwerte in Zusammenhang mit durch xsl:param definierten Parametern verwendet. Diese erhalten meist einen von außen (z.B. durch xsl:with-param) übergebenen Wert. Andernfalls greifen sie, falls kein Wert übergeben wird, auf einem, im select-Attribut definierten Defaultwert zurück, der durch einen XPath-Ausdruck definiert wird.

DocBook

Die zum anerkannten Standard gewordene DocBook-Spezifikation umfasst DTD und DSSSL/XSL-Stylesheets zum Modellieren und Konvertieren von Handbüchern oder anderen umfangreichen Druckwerken. Ursprünglich Eigentum der Davenport Group, ist DocBook jetzt im Besitz von → OASIS.

Deklarationen, XSLT-Deklarationen

→ Toplevel-Element

Document Element

Wurzelelement

Document Node

Der Document Node (Dokumentknoten; engl. root node) ist der (namenlose) Knoten, der die Wurzel jedes XML-Dokumentbaums bildet und damit das Dokument selbst repräsentiert. Er besitzt (bei wohlgeformten Dokumenten) genau einen Kindknoten, nämlich das → Wurzelelement des XML-Dokuments (dieser wird auch als document element bezeichnet). Der → Basis-URI des Document Nodes stellt den Bezugs-URI des Dokuments während der Verarbeitung dar.

Document Object Model

DOM

Document Order

→ Dokumentreihenfolge

Document Type Declaration

Im → Prolog eines XML-Dokuments darf maximal eine Document Type Declaration stehen, die eine Document Type Definition (→ DTD) benennt, die an das Dokument gebunden werden soll. Diese DTD tritt entweder als »internal Subset« in der Deklaration selbst auf oder wird als »external Subset« durch einen URI referenziert. Die allgemeine Form einer Document Type Declaration lautet: <!DOCTYPE dtd-name SYSTEM "dtd-URI" [ ... internal Subset ... ]>. Als Name der DTD (hier dtd-name) wird im Allgemeinen der Bezeichner des → Wurzelelements des XML-Dokuments verwendet.

Document Type Definition

→ DTD

Dokumentbaum

Ein Dokumentbaum, wie er bei der DOM-orientierten XML-Verarbeitung als Metapher dient, entspricht topologisch einem gerichteten, nicht zyklischen Graphen. Dies bedeutet, dass es nur einen Wurzelknoten gibt, von dem alle Zweige ausgehen (sonst zerfiele der Baum in zwei oder mehr Teilbäume), und dass kein Zweig nach einer Gabelung in sich selbst zurücklaufen darf. Dies führt zwischen den Knoten des Baums zu einer eindeutigen Eltern-Kind-Beziehung (parent-child relationship), was das Konzept ideal zur Abbildung der Dokumenthierarchie macht.

Im Diagramm dargestellt wird der Baum traditionell mit oben liegender Wurzel, von dem aus die Zweige nach unten abgehen. Verbindungen zwischen zwei Knoten werden auch als »Kanten« bezeichnet, die am Ende eines Zweigs liegenden Knoten als »Blätter« oder »leaf nodes«.

Dokumentelement

→ Wurzelelement

Dokumentknoten

→ Document Node

Dokumentreihenfolge

Unter der Dokumentreihenfolge (document order) ist die auf den Dokumentbaum übertragene Quelltext-Leserichtung des Dokuments zu verstehen. Sie entspricht der Reihenfolge der Starttags der Elemente des Dokuments, d.h. das erste Element in Dokumentreihenfolge ist das Wurzelelement des Dokuments, das zweite sein erstes Kindelement, das dritte wiederum dessen erstes Kindelement und so fort bis zum Ende (leaf node) dieses Zweigs. Nächstes Element ist der Geschwisterknoten jenes Elements an der letzten Gabelung des Zweigs; dieser Zweig wird ebenfalls bis zum Ende verfolgt. In dieser Weise werden alle Knoten des Baums durchwandert (traversiert), bis man zuletzt wieder beim Wurzelknoten ankommt.

DOM

Das DOM (Document Object Model) ist ein objektorientiertes Datenmodell, das als Interface zur Bearbeitung (lesen, ändern, löschen, hinzufügen) der Bestandteile eines Dokuments dient. Dieses wird hierfür in einen → Dokumentbaum umgewandelt. Als Interface ist DOM universal konzipiert, kann also prinzipiell mit verschiedenen Programmiersprachen (Java, C++, Visual Basic etc) genutzt werden. Ein DOM wird aus einem XML-Objekt mit Hilfe eines DOM-Parsers (z.B. Xerxes) erstellt. Die Spezifikationen des W3C zu DOM.

DSSSL

Das Kürzel DSSSL steht für Document Style Semantics and Specification Language, eine komplexe Stylesheet-Sprache für SGML-Dokumente. An DSSSL angelehnt sind andere Stylesheet-Sprachen wie CSS und → XSL-FO entstanden.

DTD

Die Document Type Definition (DTD) legt restriktiv Wortschatz und Grammatik einer Markup-Sprache fest. In ihr sind die erlaubten Elemente und Attribute, die in einem dieser DTD entsprechenden Dokument (→ typgültig) erlaubt sind, deklariert. Die Deklaration erstreckt sich zum einen auf den Bezeichner des Elements bzw. Attributs, zum anderen auf sein → Inhaltsmodell, das festlegt, welche Inhalte in welcher Reihenfolge oder Häufigkeit auftreten dürfen. Die Syntax von DTDs ist nicht XML-kompatibel, was, neben einiger weiterer Defizite, zur Einführung von XML Schema führte, das denselben Aufgabenbereich abdeckt. Vorläufig, aufgrund der weiten Verbreitung und teilweise einfacheren Anwendung, werden DTDs dennoch in Gebrauch bleiben. Die übliche Dateiendung für (externe) DTD-Dateien ist .dtd.

nach oben

E

EDI

Unter EDI (Electronic Data Interchange) ist eine Methode zum Datenaustausch zwischen Firmen per Intranet oder Internet zu verstehen. Ein EDI-Standard für den Electronic Commerce ist EDIFACT (ISO 9735).

Element, Elementknoten

Ein Element eines XML-Dokuments wird im Dokumentbaum durch einen Elementknoten repräsentiert, in dem Start- und Endtag des Element-Containers zusammenfallen. Der Name des Elementknotens entspricht dem Bezeichner des Elements, sein Inhalt manifestiert sich im Baum durch einen vom Elementknoten in Descendant-Richtung abgehenden Zweig: Den Elementinhalt bilden als Kindknoten in diesem enthaltene Text-, Kommentar-, Processing-Instruction- und Elementknoten. Nicht zu den Kindknoten des Elements zählen zum Element gehörende Attribut- oder Namensraumknoten (die folglich nicht dem Elementinhalt zugerechnet werden dürfen).

Elementachsen

Die Elementachsen bilden einen Sammelbegriff für diejenigen → Achsen, für die der Elementknoten den → Principal Node Type darstellt. Darunter fallen benahe alle Achsen: Child-, Descendant-, Descendant-Or-Self-, Parent-, Ancestor-, Ancestor-Or-Self-, Self-, Following-Sibling-, Preceding-Sibling-, Following- und Preceding-Achse. Lediglich die Attributachse und die Namespace-Achse zählen nicht zu den Elementachsen.

Embedded Stylesheet

Neben der üblichen Methode, ein XSLT-Stylesheet als separate XML-Datei zu gestalten, gibt es die Möglichkeit, ein xsl:stylesheet-Element mitsamt enthaltenen Template-Regeln in das zu verarbeitende XML-Dokument einzubetten. Diese Lösung wird als embedded Stylesheet bezeichnet, allerdings nicht von allen XSLT-Prozessoren unterstützt. Das Stylesheetelement erhält einen Identifier vom Typ ID (z.B. id="mein_style"), auf den von der <?xml-stylesheet>-Processing-Instruktion des XML-Dokuments mit einem Fragmentidentifier Bezug genommen wird (z.B. href="#mein_style"). Abgesehen von der Problematik, dass dieses eingebettete Stylesheet schwer oder gar nicht zur Verarbeitung anderer XML-Dokument zu nutzen ist, muss Sorge getragen sein, dass es sich bei der Verarbeitung nicht versehentlich selbst mitverarbeitet.

Encodierung

Die Encodierung (Kodierungsdeklaration) eines XML-Dokuments teilt dem XML-Parser den im Dokument verwendeten → Unicode-Zeichensatz mit. Dies geschieht durch das encoding-Attribut in der → XML-Deklaration, die das Dokument einleitet. Unterlässt man eine explizite Nennung der Encodierung, so nimmt der Parser automatisch → UTF-8 oder UTF-16 als Zeichensatz an. Hierbei wird gegebenenfalls, wenn eine XML-Deklaration vorliegt, die einleitende, festgelegte Zeichenfolge <?xml zu Hilfe genommen. Die Unterscheidung zwischen UTF-8 und UTF-16 kann nach den ersten vier eingelesenen Bytes dieser Zeichenkette getroffen werden. In Westeuropa sollte der Wert → ISO-8859-1 als Encodierung eingesetzt werden, um zuverlässig Umlaute darstellen zu können.

Entities, externe

Im Rahmen einer DTD können in Form von externen Entities Zeiger auf externe Dateien deklariert werden, die durch Referenzen in den Verarbeitungsprozess des XML-Dokuments eingebunden werden können. Handelt es sich um textbasierte Dateien (ASCII-Text mit oder ohne Markup), so wird der Inhalt geparst und anstelle der → Entity-Referenz in das XML-Dokument eingefügt (expandiert), wobei das → Wohlgeformtheitskriterium nicht verletzt werden darf. Dateien mit Binärdaten werden als → unparsed Entities eingebunden. Sie können nicht ins Dokument eingefügt werden, stattdessen wird die Zeigerreferenz beibehalten.

Entity

Entities (Entitäten) sind in der DTD deklarierte, benannte Ersetzungsvorschriften bzw. Verweise auf externe Dateien (→ Entities, externe), auf die im Dokument durch → Entity-Referenzen Bezug genommen werden kann. Man unterscheidet zwischen internen und externen Textentities, die vom Parser verarbeitet werden, und unparsed Entities (Binärdaten, die nicht geparst werden dürfen). Darüber hinaus gibt es fünf vordefinierte Entities, die nicht deklariert werden müssen, sondern grundsätzlich zur Verfügung stehen, um Steuerzeichen umschreiben zu können.

Entity-Referenz

Eine Entity-Referenz nimmt innerhalb eines XML-Dokuments Bezug auf ein in der → DTD deklariertes Entity. Eine Referenz erfolgt durch den in der DTD vereinbarten Bezeichner des Entitys, mit vorangestelltem Ampersand »&« und folgendem Semikolon »;« – z.B. &mein_entity;. Der Ersetzungstext eines geparsten Entitys wird anstelle der Referenz in das Dokument eingefügt (das Entity wird »expandiert«). Eine Referenz auf ein nicht geparstes Entity kann dagegen nur in einem Attribut vom Typ ENTITY erfolgen. In diesem Fall darf als Attributwert nur der Bezeichner des Entitys stehen, & und Semikolon werden nicht verwendet.

Ergebnisbaum

Der Ergebnisbaum wird im Rahmen einer XSLT-Transformation aufgebaut. Zunächst wird sein → Document Node erzeugt, an den sukzessive weitere Knoten durch Ausführung der Template-Regeln des XSLT-Stylesheets angehängt werden. Hierbei kann es sich um → Literal Result Elements handeln oder um durch xsl:element bzw. xsl:attribute erzeugte Element- oder Attributknoten. Der Ergebnisbaum gilt als → Current Output Destination, der aktuell geschriebene Knoten wird als → Current Destination Node bezeichnet.

Ergebnisdokument

Das Ergebnisdokument erhält man durch → Serialisierung des Ergebnisbaums, also dessen Ausgabe in eine Datei. Abhängig von der Output-Methode, kann es sich hierbei um ein XML-Dokument handeln oder um ein HTML-Dokument (nach HTML 4.0) bzw. ein Textdokument beliebiger Art (z.B. Plaintext, CSV, RTF oder LaTeX-Format). Seit XSLT 2.0 ist XHTML als unmittelbares Ausgabeformat eingeführt, was bisher nur über den Umweg als XML-Format möglich war.

Erweiterungsfunktion

Die im Rahmen von XPath 1.0 bzw. XPath 2.0/XQuery vordefinierten Funktionen können durch benutzerdefinierte Funktionen erweitert werden. Diese können als Erweiterungsfunktion im XSLT-Prozessor implementiert sein und müssen dann durch einen entsprechenden Namensraum gekennzeichnet werden. Die Verfügbarkeit einer Erweiterungsfunktion in einer Laufzeitumgebung kann durch die XPath-Funktion function-available() geprüft werden. Im Rahmen von EXSLT werden auch Pakete mit Erweiterungsfunktionen zur Verfügung gestellt. In XSLT 2.0 gibt es darüber hinaus die Möglichkeit, mit dem neuen → Toplevel-Element xsl:function zur Laufzeit eigene Funktionen (sogenannte → Stylesheet-Funktionen) zu deklarieren und im XSLT-Stylesheet einzusetzen.

Erweiterungsinstruktion

Die vordefinierte Menge der XSLT-Instruktionen kann durch proprietäre Instruktionen des Herstellers des XSLT-Prozessors erweitert werden, die im XSLT-Stylesheet entsprechend eingesetzt werden können. Hierbei muss eine solche Erweiterungsinstruktion einen Namensraum besitzen, der sich vom → XSLT-Namensraum unterscheidet, aber auch keinen → Null-Namensraum (leeren Namensraumstring) darstellt. Der Namensraum für Erweiterungsinstruktionen muss jedoch angemeldet werden; dies geschieht mit dem Attribut extension-element-prefixes von xsl:stylesheet. Alternativ kann der Namensraum mit demselben Attribut auch in der Erweiterungsinstruktion selbst bekannt gegeben werden, dann aber in der Form xsl:extension-element-prefixes. Die Verfügbarkeit einer Erweiterungsinstruktion in der Laufzeitumgebung des Stylesheets kann mit der XPath-Funktion element-available() geprüft werden. Bekannte Erweiterungsinstruktionen, die in vielen Umgebungen einbindbar sind, stehen als EXSLT zur Verfügung. Viele ihrer Funktionalitäten sind in XSLT 2.0 eingearbeitet.

Expanded Name

Der expandierte QName (expanded Name) eines Knotens ist der vom XSLT-Prozessor während der Verarbeitung eigentlich verwendete, nicht der aus Präfix und → Local Name zusammengesetzte → QName, wie er im Quelltext des Dokuments steht. Unter »Expansion« des QName versteht man die Ersetzung des Namensraumpräfixes durch den URI-String, den er repräsentiert. Stehen daher mehrere Präfixe in einem Dokument für den selben Namensraum-URI, so kann der Prozessor dies einem expanded Name nicht ansehen. Bei Verwendung der Funktion name() gibt er daher im Zuge der Rückumwandlung (Namespace Fixup) einen beliebigen der vereinbarten Präfixe des Namensraums aus. Für die Notation eines expandierten Namens gibt es keine allgemein festgelegte Schreibweise. Man kann ihn sich (nach James Clark) in der Form {http://www.example.org/beispielnamensraum}beispiel vorstellen. Ebenfalls üblich ist die Schreibweise "http://www.example.org/beispielnamensraum^beispiel" wobei beispiel jeweils den lokalen Bezeichner (Local Name) darstellt.

Expression

Eine XPath Expression, auch XPath-Ausdruck genannt, ist die allgemeine Bezeichnung für ein Konstrukt, das entsprechend der XPath-Syntax aufgebaut ist und dessen Auswertung entweder einen String, eine Zahl, einen booleschen Wert oder eine Sequenz (XPath 1.0: ein Nodeset) ergibt. XPath-Ausdrücke werden innerhalb bestimmter Attribute von XSLT-Instruktionen ausgewertet, wie dem select-Attribut in xsl:value-of, xsl:for-each oder dem test-Attribut von xsl:if oder xsl:when, um nur einige zu nennen (Beispiel: select="$ausdruck"). Zur Laufzeit des Stylesheets wird der Ausdruck durch seinen Ergebniswert ersetzt. Ebenfalls erlaubt sind Expressions innerhalb von Attributwert-Templates, die als Attributwerte von → Literal Result Elements gestattet sind. Sie haben die Form mein_attribut="{$ausdruck}". Die geschweiften Klammern selbst zählen nicht zur Expression, sondern dienen als Begrenzer. Sie müssen in diesem Kontext escaped werden (statt { steht dann {{), wenn sie im Inneren des Ausdrucks verwendet werden sollen.

Extension Element

→ Erweiterungsinstruktion

Extension Function

→ Erweiterungsfunktion

Externe Entities

→ Entities, externe

nach oben

F

Fallback

Auf das Prinzip des Fallback greift der XSLT-Prozessor zurück, falls er zur Laufzeit nicht in der Lage ist, einen Ausdruck oder eine Instruktion innerhalb einer Template-Regel auszuwerten. In diesem Fall kann ein ansonsten übersprungener alternativer Templateblock ausgeführt werden, der in einem xsl:fallback-Element steht. Dieser Fall tritt beispielsweise auf, wenn eine geforderte → Erweiterungsinstruktion nicht vorhanden oder ein Element einer höheren Sprachversion gefordert ist. Alternativ kann auch im Rahmen eines Tests durch element-available() oder function-available() geprüft werden. Fallback erstreckt sich nicht auf unerkannte → Toplevel-Elemente, die stattdessen einfach ignoriert werden.

Filterausdruck

→ Predicate

Following-Achse

Die Following-Achse (following::) umfasst alle in → Dokumentreihenfolge auf den → Kontextknoten folgenden Knoten, nicht aber den Kontextknoten selbst. Auch die Nachfahren des Kontextknotens sind nicht enthalten. In Quelltext betrachtet, gehören in die Following-Menge all jene Elemente, deren Starttag nach dem Endtag des Kontextelements steht bzw. die in jenen Elementen enthalten sind (z.B. Text- und Kommentarknoten). Für diese Achse existiert keine → abgekürzte Schreibweise.

Following-Sibling-Achse

Die Following-Sibling-Achse (following-sibling::) umfasst alle in → Dokumentreihenfolge auf den → Kontextknoten folgenden Knoten der gleichen Hierarchieebene, nicht aber den Kontextknoten selbst. Für diese Achse existiert keine → abgekürzte Schreibweise.

Formatting Objects (FO) XSL

Formatting Objects (XSL-Formatierungsobjekte) oder kurz XSL-FO ist eine in XML formulierte Beschreibungssprache zur druckseitenorientierten Ausgabe von XML-Dokumenten. Es steht hierin in der Tradition von CSS und → DSSSL, von dem sie den Begriff »flow objects« entlehnt, ist in Bezug auf Sprachunterstützung, Schreibrichtung etc. aber universaler angelegt, was die Spezifikation sehr umfangreich macht. XSL-FO kann als die Weiterführung des ursprünglichen XSL betrachtet werden, das zunächst sowohl die inzwischen eigenständige Transformationssprache XSLT als auch Ausgabeformatierung in den Sprachspezifikationen vereinte. Technisch ist ein XSL-FO-Dokument Ergebnis einer XSLT-Transformation eines XML-Dokuments, muss aber in einer weiteren Verarbeitungsstufe an eine Ausgabeapplikation übergeben werden (etwa als PDF-Dokument). Ein Beispiel für einen FO-Prozessor ist FOP von James Tauber.

Forwards-Compatible Processing

Das Prinzip des Forwards-Compatible Processing soll die bestmögliche Verarbeitung von XSLT-Stylesheets durch einen XSLT-Prozessor auch dann ermöglichen, wenn der Versionsstand des Stylesheets ganz oder in einzelnen Instruktionen höher als der durch den Prozessor unterstützte ist. In diesem Falle sollen unbekannte → Toplevel-Elemente ignoriert und für unerkannte → Instruktionen ein → Fallback ausgeführt werden. Weiterhin sollen unbekannte → Attribute von Instruktionen oder Toplevel-Elementen ignoriert werden. Erst wenn dies fehlschlägt, soll ein dynamischer Fehler (Laufzeitfehler) gemeldet werden.

Fragment Identifier

Ein Fragment Identifier ist der Teil eines URI, der eine Referenz auf einen Bereich eines Dokuments bildet, der durch einen Identifier gekennzeichnet ist. Ein einfaches Beispiel für das Prinzip eines Fragment Identifiers ist der HTML-Name-Anker und seine Referenzierung: <a name="mein_anker"> und <a href="#mein_anker">. Im XML-Kontext werden Fragment Identifier in der Spezifikation von XPointer beschrieben, das als Erweiterung von XPath betrachtet werden kann.

Funktion

Teile eines XPath-Ausdrucks können Aufrufe von Funktionen sein, die entweder in XPath oder in XSLT definiert sein können. Seit XPath 2.0 werden die XPath-Funktionen gemeinsam mit jenen von XQuery beschrieben, das die neue Obergruppe von XPath darstellt. Funktionen können seit XPath 2.0 auch als → Stylesheetfunktionen innerhalb des Stylesheets definiert oder als → Erweiterungsfunktionen vom XSLT-Prozessor zur Verfügung gestellt werden. Nach Auswertung eines Funktionsaufrufs wird der Rückgabewert der Funktion in den XPath-Ausdruck eingesetzt. Rückgabewert kann in XPath 1.0 ein String, ein boolescher Wert, eine Zahl oder ein Nodeset sein. In XPath 2.0 ist der allgemeinere Begriff → »Sequenz« an die Stelle von »Nodeset« getreten, und alle Datentypen von → XML Schema werden unterstützt.

nach oben

G

Gemischter Inhalt

→ Mixed Content

Globale Parameter

→ Parameter

Globale Variablen

→ Variable

Glyphen

Unter einem Glyphen ist die rein optische Repräsentierung eines bestimmten Zeichens (Buchstabe, Zahl oder Symbol) zu verstehen, das in ASCII, Unicode oder anders bestimmt sein kann. Ein Zeichen kann durch unterschiedliche Glyphen vertreten sein, je nachdem, mit welcher Schriftfamilie, Schriftgröße oder -schnitt es wiedergegeben werden soll.

Gültigkeit (von XML-Dokumenten)

→ Typgültigkeit

Gültigkeitsbereich von Variablen und Parametern

Der Gültigkeitsbereich (Scope) einer → Variablen oder eines → Parameters wird in XSLT durch die Position ihrer Einführung (Deklaration) festgelegt. Man unterscheidet globale und lokale Variablen und Parameter. Gemeinsam ist beiden, dass sie in Bezug auf ihre Deklaration mit xsl:variable bzw. xsl:param innerhalb aller Elemente der → Following-Sibling-Achse nach der Deklaration referenziert werden können. Eine globale Variable bzw. ein globaler Parameter, wo die Deklaration als → Toplevel-Element steht, gilt damit in allen auf die Deklaration folgenden → Template-Regeln, lokale Variablen und Parameter gelten dagegen nur innerhalb der Template-Regel, in der sie (als → Instruktion) deklariert sind. Lokale Variablen und Parameter haben in ihrer Template-Regel Vorrang vor namensgleichen globalen Variablen und Parametern (shadowing); der Wert der globalen Größe ist damit dort unerreichbar.

nach oben

H

HTML

Die Hyper Text Markup Language (HTML) ist, wie XML, von der Metasprache SGML abgeleitet, gehört selbst aber nicht in die Gruppe der XML-Sprachen (besser: XML-Anwendungen). HTML ist aber ein gängiges Ergebnisformat von XSLT-Transformationen, das implizit durch Verwendung von <html> als → Wurzelelement des → Ergebnisdokuments oder durch Nennung als Zielformat im method-Attribut von xsl:output mittels method="html". In Form einer XML-Anwendung wurde HTML durch → XHTML nachgebildet und weiterentwickelt, das ab XSLT 2.0 ebenfalls mit method="xhtml" als eigenständiges Ausgabeformat zur Verfügung steht.

nach oben

I

IANA

Die IANA (Internet Assigned Numbers Association) beaufsichtigte anfangs die Zuteilung von Internetadressen, Domain-Namen und die Vergabe von Parametern des Internetprotokolls, wie TCP- und UDP-Ports, Ethernet-Nummern und Service-Namen. Mittlerweile sind diese Aufgaben an die ICANN (Internet Corporation for Assigned Names and Numbers, seit 1998) abgegeben worden. Eine wichtige Aufgabe ist nach wie vor die Registrierung von → Languagecodes und → MIME-Types.

ID

Ein Identifier (ID) ist ein Attributtyp, der ein dergestalt deklariertes Attribut als einzigartiges Erkennungsmerkmal für die Elementinstanz, in der es verwendet wird, einsetzbar macht. Der Attributwert eines ID-Attributs muss eindeutig und einzigartig im Dokument sein. Es dürfen daher niemals zwei ID-Attribute denselben Wert besitzen (auch wenn sie verschiedene Bezeichner haben und verschiedenen Elementen zugeordnet sind!). Der Bezeichner eines solchen Attributs muss dagegen nicht notwendigerweise id sein, dieser wird aber aus Gründen der Eindeutigkeit oft so gewählt. Ausschlaggebend ist die Deklaration in der → DTD oder im Schema, beispielsweise mit <!ATTLIST beispiel id-attribut ID #REQUIRED> wo für ein Element <beispiel> ein obligatorisches Attribut vom Typ ID mit Namen id-attribut deklariert wird. XPath stellt eine Funktion id() zur Verfügung, die Elemente mit ID-Attribut anhand des Identifierwerts findet.

Importpräzedenz

Die Importpräzedenz legt für modulare XSLT-Stylesheets, die sich aus einem Hauptstylesheet und mit xsl:import importierten externen Stylesheetmodulen zusammensetzen, im Falle eines Konflikts fest, welche Template-Regel vorrangig instanziiert werden soll. Ein Konflikt tritt auf bei namensgleichen → benannten Templates oder bei identischen → Template-Regeln. Template-Regeln, die im Hauptstylesheet stehen, besitzen Vorrang, was als »höhere Importpräzedenz« bezeichnet wird. Importierte Stylesheets besitzen die niedrigere Importpräzedenz, von diesen importierte wiederum eine niedrigere. Template-Regeln aus eingefügten (inkludierten) externe Stylesheets besitzen dagegen die gleiche Präzedenz wie die Regeln des Hauptstylesheets, was auf deren Überschreibung hinausläuft, da sie auf Grund der Position der xsl:include-Anweisung als vor diesen geschrieben betrachtet werden.

Inhaltsmodell

Das Inhaltsmodell eines Elements bestimmt Art und Zusammensetzung des für dieses Element erlaubten Inhalts (content). Festgelegt werden können im Rahmen einer → DTD für reinen Elementinhalt die Art (Bezeichner), Reihenfolge (Sequenz) und, wenn auch ungenügend, die Häufigkeit (Kardinalität) von Kindelementen. Alternativ kann reiner Textinhalt #PCDATA (→ PCDATA) oder sogenannter gemischter Inhalt (→ Mixed Content) gestattet werden. Die Defizite von DTDs in Bezug auf die Definition von Inhaltsmodellen sind in → XML Schema überwunden, allerdings um den Preis einer wesentlich komplexeren Formulierung derselben.

Instanziieren

Der Begriff Instanziieren wird beim Ausführen einer Template-Regel gebraucht. Hierbei werden zum einen im Templateblock enthaltene → Literal Result Elements in das Ergebnisdokument kopiert und zum anderen weitere XSLT-Instruktionen des Templateblocks ausgeführt.

Instruktion

Unter dem Begriff Instruktionen versammelt man diejenigen XSLT-Elemente, die nicht als → Toplevel- oder Root-Elemente verwendet werden bzw. die nur innerhalb von Template-Regeln (in xsl:tem¬plate-Containern) eingesetzt werden dürfen. In XSLT 1.0 gibt es 21 Instruktionen, in XSLT 2.0 ist die Menge auf 29 angewachsen. Überschneidungen gibt es bei xsl:param und xsl:variable, die auch als Toplevel-Elemente auftreten können.

ISO

Die ISO (International Organization for Standardization) ist eine unabhängige Organisation, die sich mit der Festlegung international gültiger Standards befasst. In der ISO sind 145 Länder vertreten (Deutschland durch das Deutsche Institut für Normung, DIN). Derzeit werden ca. 14.000 Standards verwaltet. Im XML/XSLT-Rahmen bedeutsam sind die Zeichensatzstandards der ISO (ISC-Feld 35.040: »Character sets and information coding«), von denen eine Teilmenge zur Festlegung der → Encodierung von XML-Dokumenten verwendet werden (→ ISO-8859).

ISO-8859

Die ISO-8859-Familie fasst in ihren Untergruppen verschiedene Zeichensätze zusammen, die zur → Encodierung von XML-Dokumenten dienen können. Die aus unserer Sicht wichtigste Untergruppe ist ISO-8859-1 (Latin-1), die den westeuropäischen Zeichensatz beschreibt. Außerdem gibt es noch ISO-8859-2 (Osteuropa; Latin-2), ISO-8859-3 (Südeuropa, restliche europäische Sprachen; Latin-3), ISO-8859-4 (Skandinavien, Baltikum; Latin-4), ISO-8859-5 (kyrillisch), ISO-8859-6 (arabisch), ISO-8859-7 (griechisch), ISO-8859-8 (hebräisch), ISO-8859-9 (türkisch) und ISO-8859-10 (lappländisch, Eskimo).

Item

Der Begriff Item beschreibt in XPath 2.0 allgemein ein Element einer → Sequenz. Ein Item kann ein sogenannter atomarer Wert sein, also ein String, eine Zahl oder ein → boolescher Wert (aber auch ein Datumswert) oder ein Knoten (Node). Sequenzen, die nur aus einem einzigen Item bestehen, werden Singleton-Sequenzen genannt.

nach oben

J

JAXP

Die Java API für XML Processing (JAXP) ist der XML-Parser von SUN, der früher unter der Bezeichnung Project-X (XDOM) bekannt war. Das Paket ist zuständig für das Parsen und die Transformation von XML-Dokumenten und unterstützt → SAX 2.0, → DOM Level 2 und XSLT.

JDK

Das Java Development Kit (JDK) von Sun enthält ab der Version JDK 1.4 (Java 2) das komplette Paket aller für Parsing und Verarbeitung von XML/XSLT erforderlichen Java-Klassen.

nach oben

K

Kardinalität

Unter Kardinalität versteht man die Häufigkeit des Auftretens beispielsweise eines Knotens im Rahmen eines Inhaltsmodells. Die Kardinalität wird gewöhnlich durch einen dem Bezeichner nachgestellten Indikator verdeutlicht (? für ein- oder keinmaliges, + für ein- oder mehrmaliges, * für kein-, ein- oder mehrmaliges Vorkommen).

Key-Definition

Unter einer Key-Definition versteht man die Definition eines Schlüssels (Key), der, ähnlich einer Look-up-Tabelle, die Relation zwischen Elementknoten innerhalb eines oder mehrerer während eines Verarbeitungsprozesses gemeinsam eingebundener XML-Dokumente festlegt. Die Key-Definition wird im XSLT-Stylesheet mit Hilfe des Toplevel-Elements xsl:key deklariert und benannt und kann anschließend unter Verwendung des bei der Definition eingeführten Bezeichners des Schlüssels in XPath-Ausdrücken mit der XSLT-Funktion key() referenziert werden. Vorteil ist die Speicherung der Relationen im Vorfeld der Verarbeitung, was gegenüber der unmittelbaren Abfrage durch XPath in einem Geschwindigkeitsgewinn bei der Verarbeitung resultiert.

Kindknoten

Unter Kindknoten versteht man alle (einem Element) als Inhalt untergeordneten Knoten. Hier sind eingeschlossen alle Elemente, Textknoten, Kommentarknoten und Processing-Instructions, die im Quelltext zwischen Start- und Endmarke des betrachteten Elements stehen. Sie alle sind, ausgehend vom Element, über die → Child-Achse erreichbar. Der → Namensraumknoten und die → Attributknoten eines Elements zählen nicht zu dessen Kindknoten. Sie sind deshalb nur über eigene Achsen, die → Attributachse und die → Namespace-Achse erreichbar.

KindTest

Der Begriff KindTest stammt aus XQuery/XPath und bezeichnet eine Untergruppe des → Nodetests in einem → Location Step. Ein KindTest bezieht sich auf den Typ des Knotens, ohne Berücksichtigung seines Bezeichners. Normalerweise ist der KindTest deshalb für → namenlose Knoten erforderlich, kann aber auch auf benannte Knoten angewendet werden. Die andere Untergruppe des Nodetest ist der → NameTest.

Knoten

→ Node

Knotenliste, aktuelle

→ Node-Sequenz, aktuelle

Knotentyp

→ Nodetyp

Kommentar

Ein Kommentar wird in XML wie in → SGML mit der Zeichenfolge <!-- eingeleitet und mit --> beendet: <!-- Dies ist ein XML-Kommentar -->. Er kann in XML-Dokumenten an beliebiger Stelle im Inhalt von Elementen und auch im → XML-Prolog eingesetzt werden, allerdings nicht innerhalb eines Tags (um beispielsweise ein einzelnes Attribut auszukommentieren). Kommentare dürfen nicht verschachtelt werden, nicht die Zeichenfolge -- enthalten (die das Kommentarende einleitet!), können sich aber über beliebig viele Quellcodezeilen erstrecken. Im → Dokumentbaum wird ein Kommentar durch einen → Kommentarknoten repräsentiert.

 

In XPath sind (seit XPath 2.0) ebenfalls Kommentare möglich, die mit der Zeichenfolge (: eingeleitet und mit :) beendet werden: (: Dies ist ein XPath-Kommentar :). In erster Linie sollen so komplexere XPath-Ausdrücke annotiert werden können, es ist jedoch auch möglich, auf diesem Wege Quellcode stillzulegen. Im Gegensatz zu XML-Kommentaren dürfen XPath-Kommentare verschachtelt werden. Sie sind überall dort zugelassen, wo in XPath-Ausdrücken Weißraumzeichen erlaubt sind.

Kommentarknoten

Ein Kommentarknoten repräsentiert im → Dokumentbaum einen Kommentar. Er ist dem Element, das den Kommentar enthält, als Kindknoten untergeordnet, also über die → Child-Achse erreichbar. Aufgrund der → eingebauten Template-Regeln wird ein Kommentarknoten vom XSLT-Prozessor nicht ins → Ergebnisdokument kopiert oder anders ausgewertet, solange nicht eine explizite Template-Regel hierfür vorliegt. Ein Kommentarknoten ist namenlos, kann aber durch den → Nodetest comment() erkannt werden. Sein Stringwert entspricht dem auskommentierten Textinhalt.

Kontextgröße

Unter der Kontextgröße ist die Zahl der Items in der → aktuellen Sequenz zu verstehen. Dies ist notwendigerweise stets eine Ganzzahl, die durch die XPath-Funktion last() ermittelt werden kann.

Kontextknoten

Der Kontextknoten ist der Knoten, der zum Zeitpunkt der Auswertung eines XPath-Ausdrucks dessen Bezugspunkt bildet. In den meisten Fällen fällt der Kontextknoten daher mit dem → Current Node zusammen. Ausnahme ist die Auswertung von XPath-Predicates (→ Predicate), wo der jeweils im Rahmen des Predicates geprüfte Knoten zum Kontextknoten wird.

Kontextposition

Unter der Kontextposition ist die Position des → Current Items innerhalb der → aktuellen Sequenz zu verstehen. Diese kann mit der XPath-Funktion position() ermittelt werden, deren Rückgabewert eine Ganzzahl darstellt, die der Position des Knotens in der Liste entspricht. Das erste Item hat die Position 1, das letzte Item eine Position gleich der → Kontextgröße.

nach oben

L

Languagecode

Der Languagecode bezeichnet die für einen Elementinhalt verwendete Sprache. Diese wird mittels des xml:lang-Attributs für das Element, das das Attribut erhält und dessen Nachfahren festgelegt. Eine Sprachdefinition wird durch ein Buchstabenkürzel bezeichnet, das aus einer zweibuchstabigen Hauptgruppenbezeichnung und einer optionalen, durch Bindestrich abgetrennten Untergruppenbezeichnung besteht: fr-CA für Frankokanadisch (Hauptgruppe Französisch fr, Untergruppe Kanadisch CA). Die Kürzel sind in ISO 639 festgelegt bzw. bei der → IANA. Darüber hinaus können auch userdefinierte Kürzel verwendet werden.

Leserichtung

→ Dokumentreihenfolge

Literal

Unter einem Literal ist die Benennung eines Werts zu verstehen, das Literal steht also für den eigentlichen Wert. Der String "Hallo!" ist das Textliteral für den Wert Hallo! (ohne Stringbegrenzer). Ein Literal ist dabei ein sogenannter elementarer Ausdruck, der sich dadurch auszeichnet, dass er nicht in weitere Teilausdrücke zerlegt werden kann (oder braucht). Primitive Werte treten als Literale auf, so Strings in Form von Textliteralen, boolesche Werte als Boolean-Literale, von denen es genau zwei gibt, nämlich true und false. Bei Zahlenliteralen spricht man dagegen korrekter von »Numeralen« (Beispiel: Das Numeral 17.5 steht für die Zahl 17,5).

Literal Result Element

Unter Literal Result Elements versteht man diejenigen Elemente innerhalb von → Template-Bodies, die mit ihren Inhalten, sofern es sich dabei nicht um XSLT-Instruktionen handelt, unverändert in das → Ergebnisdokument kopiert werden. Literal Result Elements müssen innerhalb ihres Templates den → Wohlgeformtheitsregeln Genüge tun. Sie dürfen außerdem nicht im → XSLT-Namensraum sein oder in einem für → Erweiterungsinstruktionen vereinbarten, können aber einem beliebigen anderen Namensraum (oder dem → Default-Namensraum) angehören. Dieser Namensraum wird, sofern er nicht davon ausgeschlossen ist, ebenfalls in das Ergebnisdokument kopiert. Textknoten werden ebenfalls kopiert, und deshalb oft den Literal Result Elements hinzugeschlagen. Korrekter werden sie aber als »Literal Data Characters« bezeichnet.

Local Name

Unter Local Name (lokaler Bezeichner) ist im Allgemeinen der Teil eines → QNames zu verstehen, der dem → Namensraumpräfix folgt. Es muss sich hierbei um einen XML-Namen, nicht notwendigerweise aber um einen → NCNamen handeln. Man kann die XPath-Funktion local-name() verwenden, um den lokalen Bezeichner eines Knotens zu erhalten. Auf Element- und Attributknoten angewendet gibt die Funktion deren Namen, bei → namenlosen Knoten einen leeren String zurück. Auf Namensraumknoten angewendet, gibt die Funktion das bzw. ein Präfix zurück, mit dem der entsprechende Namensraum-URI verbunden ist. Der Local Name einer → Processing-Instruction ist der Name ihrer Target-Applikation.

Location Path

Ein Location Path ist ein XPath-Ausdruck, der einen Knoten oder eine Gruppe von Knoten in einem Dokument beschreibt. Man unterscheidet → absolute und → relative Location Paths. Ein Location Path setzt sich aus einem oder mehreren → Location Steps zusammen, die jeweils durch Slash / getrennt sind. Die Ergebnismenge umfasst alle diejenigen Knoten, die, ausgehend vom Bezugspunkt (dem → Document Node oder dem → Kontextknoten), über den Location Path erreicht werden. Sie kann einen oder mehrere Knoten enthalten, aber auch leer sein.

Location Path, absoluter

Ein absoluter Location Path ist ein → Location Path, der den → Document Node als Bezugspunkt verwendet. Hierfür wird dem ersten Location Step der Slash / vorangestellt, der den Document Node vertritt. Die Auswertung eines absoluten Location Paths ergibt daher unabhängig vom aktuellen Kontext stets die gleiche Ergebnismenge. Beispiel: /element1/element2.

Location Path, relativer

Ein relativer Location Path ist ein → Location Path, der beim Kontextknoten beginnt. Er beginnt unmittelbar mit dem ersten → Location Step. Die Auswertung eines relativen Location-Paths ergibt, abhängig vom aktuell gültigen Kontextknoten, jeweils verschiedene Ergebnismengen. Beispiel: element1/element2.

Locationpfad

→ Location Path

Location Step

Der Location Step ist der Baustein für einen → Location Path, der aus mindestens einem Location Step besteht. Ein Location Step setzt sich zusammen aus einem Achsenbezeichner (→ Achse), der die Richtung des Schrittes bestimmt, und einem → Nodetest, der die Knoten auf der gewählten Achse prüft. Bei Bestehen des Tests wird ein gefundener Knoten der Ergebnismenge hinzugefügt. Zusätzlich können mit Hilfe von → Predicates ein oder mehrere Filterkriterien definiert werden, die zusätzlich zum Nodetest von Knoten der Kandidatenmenge erfüllt werden müssen. Beispiel: descendant::node()[name()='beispiel'], wobei descendant:: der Achsenbezeichner, node() der Nodetest und [name()='beispiel'] ein Predicate ist.

Lokale Variable

→ Variable

Lokaler Parameter

→ Parameter

nach oben

M

Metadaten

Informationen über Art und Eigenschaften von Daten, dienen also zur Beschreibung der Daten und beinhalten selbst keine konkret zu verwendenden Werte. Metadaten stellen eine höhere Stufe der Abstraktion dar und erhöhen die Nutzbarkeit von in einem Informationssystem vorhandenen Datenstrukturen. In XML-Dokumenten beschreiben Metadaten in Form der Elementbezeichner die in den jeweiligen Containern enthaltenen Informationen und stellen somit Metainformationen dar.

Metainformationen

→ Metadaten

MIME-Type

Ein MIME-Type (Multipurpose Internet Mail Extension) dient als Typdefinition einer Datei. Ursprünglich aus Sendmail stammend (RFC2045, RFC2046), werden der Begriff und die Definitionen inzwischen allgemein in HTTP verwendet. Einige Beispiele für MIME-Types sind text/html, text/css und text/xml. Ein eigener MIME-Type text/xsl für XSLT wurde diskutiert und verworfen; inzwischen wurde er in der Form application/xslt+xml realisiert.

Eine Liste der für MIME-Types als gültig anerkannten Werte wird von der → IANA geführt, wo sie auch registriert werden müssen. Der gelegentlich eingesetzte MIME-Type text/xslt ist nicht registriert, und daher eigentlich nicht gültig! Ein Beispiel für die Verwendung eines MIME-Types in XML ist jene Processing-Instruction, die eine Referenz zu einem verarbeitenden XSLT-Stylesheet definiert: <?xml-stylesheet type="text/xml" href="notiz.xsl"?>. Insgesamt gibt es folgende registrierte, im XML-Kontext stehende MIME-Types: text/xml, application/xml, application/xslt+xml, text/xml-external-parsed-entity, application/xml-external-parsed-entity und application/xml-dtd (siehe RFC 3023).

Mixed Content

Unter gemischtem Inhalt (Mixed Content) versteht man das → Inhaltsmodell für Elemente, nach dem neben Text auch bestimmte und namentlich festlegbare Elemente vorkommen dürfen. Das Inhaltsmodell ist allerdings insoweit liberal, als dass es keine eindeutige Forderung nach Reihenfolge oder Häufigkeit der erlaubten Inhaltstypen zulässt. Im Rahmen einer DTD-Deklaration wird gemischter Inhalt durch eine wiederholbare Gruppe alternativer Elemente realisiert, wobei als erste Alternative grundsätzlich #PCDATA stehen muss: <!ELEMENT beispiel (#PCDATA | xxx | yyy | zzz)*>. In → XML Schema wird gemischter Inhalt im Rahmen von »complex types« beschrieben. Der reine PCDATA-Inhalt, der bei DTDs auch als »mixed content« geführt wird, zählt hier allerdings zu den »simple types«.

Mode

→ Template-Mode

Modularisierung

Das Prinzip der Modularisierung findet sich sowohl bei XML als auch bei XSLT. XML-Dokumente können modular sein und in verschiedene Dokumente oder Dokumentfragmente zerfallen, die über → Entity-Referenzen mit einem Hauptdokument verbunden sind. XSLT-Stylesheets können ebenfalls modular sein, der Mechanismus der Verknüpfung funktioniert aber üblicherweise mittels Import oder Inkludierung externer Stylesheetdateien in ein Hauptstylesheet mittels xsl:import bzw. xsl:include. Weitere Inhalte oder Inhaltsmodule können mittels der Funktion document() in eine XSLT-Verarbeitung hineingezogen werden.

nach oben

N

Named Template
 

→ Template, benanntes

Namenlose Knoten

Zu den namenlosen Knoten zählen diejenigen drei Knotentypen, die keine individuellen Bezeichner besitzen. Dies sind der → Document Node und alle → Text- und → Kommentarknoten. Für diese Knoten geben die XPath-Funktion name() und local-name() daher den leeren String zurück. Die → Processing-Instructions zählen hingegen nicht zu den namenlosen Knoten. Hier gilt der Name ihrer Target-Applikation als Bezeichner des Knotens.

Namensraum

Namensräume gehören zu den zentralen Prinzipien in XML, die Konflikte (sogenannte Kollisionen, name clashes) zwischen den frei wählbaren Bezeichnern verhindern sollen. Dies ist insbesondere dann wichtig, wenn Module verschiedener Quellen zusammengeführt werden, bei denen es möglich ist, dass gleiche Bezeichner für verschiedene Konzepte verwendet werden (z.B. table als 'Tisch' oder als 'Tabelle'). Gleichzeitig können Namensräume dazu dienen, solche Elemente unmissverständlich zu kennzeichnen, die in bestimmten Umgebungen Befehlscharakter haben sollen (so z.B. für XSLT-Instruktionen). Als Kennzeichnung für einen Namensraum wurde ein → URI-String gewählt, da dieser per Definition einzigartig ist (auch andere Lösungen wären denkbar, da an den URI keine Ressource gebunden sein muss). Dieser URI-String wird auf das → Präfix eines → QNames abgebildet. Dies ist erforderlich, da URIs Zeichen enthalten können, die in XML-Namen nicht erlaubt sind, der URI also nicht direkt Teil eines Namens sein kann.

Namensraum. Default

→ Default-Namensraum

Namensraumdeklaration

Ein Namensraum wird im Rahmen einer Namensraumdeklaration mit Hilfe eines hierfür reservierten Attributs an ein Element gebunden und dabei deklariert. Dieses Attribut ist xmlns für den Default-Namensraum oder xmlns:mein_prefix für einen Namensraum, der an ein Präfix (in diesem Fall mein_prefix:) gebunden werden soll. Bei der Deklaration wird ein URI-String an das Präfix gebunden bzw. als Default-Namensraum eingesetzt: xmlns="http://www.defaultnamensraum.org/default" bzw. xmlns:mein_prefix="http://www.mein_namensraum.net/ns". Der URI wird hierbei nicht als wirkliche Adresse, sondern nur als Zeichenkette betrachtet. Das Präfix wird dem lokalen Bezeichner jener Elemente vorangestellt, die sich im deklarierten Namensraum befinden sollen, z.B. in der Form mein_prefix:beispiel, und bildet zusammen mit dem lokalen Bezeichner (hier beispiel) den sogenannten → QName des Elements. Der Namensraum gilt für das Element, in dessen Starttag die Deklaration erfolgt und für alle seine Abkömmlinge.

Namensraumknoten

Ein Namensraumknoten repräsentiert den für ein Element gültigen Namensraum. Er gehört unmittelbar zu seinem Element und bezieht sich nicht auf dessen Nachfahren (anders als der Gültigkeitsbereich eines Namensraums, mit dem der repräsentierende Knoten jedoch nicht verwechselt werden darf). Der Stringwert eines Namensraumknotens ist der → Namensraum-URI seines Namensraums, sein → Local Name entspricht dem verwendeten → Namensraumpräfix. Ein Namensraumknoten ist nur über die → Namespace-Achse erreichbar.

Namensraumpräfix

Ein Namensraumpräfix dient als Platzhalter für den → Namensraum-URI, der durch eine → Namensraumdeklaration an das Präfix gebunden ist. Der → QName, aus Präfix und → Local Name gebildet, wird allerdings bei der Verarbeitung expandiert, d.h. das Präfix prozessorintern durch den repräsentierten URI ersetzt (→ Expanded Name). Das Präfix muss ein sogenannter → NCName sein, darf also keinen Doppelpunkt als Zeichen enthalten. Die Buchstabenkombination »xml« als Beginn eines Präfixnamens ist – unabhängig von Groß-/Kleinschreibweise (wie Xml, XML, xMl etc.) – für das W3C reserviert.

Namensraum-URI

Der Namensraum-URI (auch: Namensraumname) stellt den eigentlichen Namensraum dar, für den das verwendete Präfix nur einen Platzhalter darstellt. An ein und denselben Namensraum-URI dürfen daher auch mehrere Präfixe gebunden sein, die vom XSLT-Prozessor dann aber nicht unterscheidbar sind, da dieser sich stets auf den → Expanded Name bezieht, der den URI selbst beinhaltet. Der Namensraum-URI für XSLT-Elemente ist 'http://www.w3.org/1999/XSL/Transform' wobei der URI als Zeichenkette betrachtet wird, die für einen XSLT-Prozessor die zu verarbeitenden Befehle eindeutig kennzeichnet. Eine Abweichung von der erwarteten Zeichenkette führt dazu, dass Instruktionen nicht erkannt werden. (Hinweis: Früher gab es das Problem, dass Microsoft mit 'http://www.w3.org/TR/WD-xsl' eine von der offiziellen W3C-Empfehlung abweichende verwendete, wodurch entsprechende Stylesheets nicht ohne Änderung des Namensraums durch andere Prozessoren verarbeitet werden konnten. Dies ist aber inzwischen angeglichen.)

Namespace

→ Namensraum

Namespace-Achse

Die Namespace-Achse (namespace::node()) enthält den oder die → Namensraumknoten des → Kontextknotens, falls es sich bei diesem um ein Element handelt. In allen anderen Fällen ist die Achse leer. Auf der Achse befindet sich nicht nur ein Knoten für den an das Element unmittelbar gebundenen Namensraum, sondern ebenfalls Namensraumknoten für Namensräume, die an Elemente auf der → Ancestor-Achse des Kontextknotens gebunden sind, sofern der Kontextknoten auch in deren Gültigkeitsbereich ist. Für die Namespace-Achse existiert keine → abgekürzte Schreibweise. In XPath 2.0 und XQuery ist diese Achse abgeschafft; es steht Anwendungen lediglich frei, sie zu unterstützen. Eine Vorschrift in dieser Hinsicht besteht nicht.

NameTest

Der Begriff NameTest stammt aus XQuery/XPath und bezeichnet eine Untergruppe des → Nodetests. Ein NameTest prüft Knoten auf ihre Bezeichner, ist also nur auf benannte Knoten wie Elemente oder Attribute anwendbar. Der Wert, gegen den der NameTest prüft, kann ein Name (→ QName) sein, aber auch ein → Wildcard. Die andere Untergruppe des Nodetests ist der → KindTest.

NaN

Der Wert NaN ist das Kürzel bzw. stellvertretendes Literal für den Ausdruck »Not a Number«, der das Ergebnis des Versuchs einer numerischen Operation mit einem oder mehreren nicht numerischen Operanden darstellt. NaN zählt zwar selbst zu den Zahlenwerten, steht aber außerhalb der Zahlenfolge, weshalb ein numerischer Vergleich mit NaN auch mit sich selbst fehlschlägt. In XPath 1.0 ist NaN meist das Ergebnis einer numerischen Operation mit Strings, für die eine Typumwandlung in eine Zahl (number), die in solchen Fällen versucht wird, fehlschlägt.

NCName

Ein NCName (non-colonized name) ist ein Bezeichner, der keinen Doppelpunkt (colon) enthält, also kein Namespace-Präfix beinhalten kann. Ein vollständiger → QName kann deshalb selbst nie ein NCName sein, setzt sich aber in diesem Sinne aus zwei NCNames zusammen, von denen einer das → Namensraumpräfix und der andere den lokalen Bezeichner (→ Local Name) darstellt. Obwohl es gestattet ist, in XML-Namen, und damit auch im Local Name den Doppelpunkt zu verwenden, ist hiervon abzuraten, da der XSLT-Prozessor (fälschlicherweise) den Teil des Namens vor dem ersten Doppelpunkt als (obendrein nicht deklariertes) Namensraumpräfix ansehen wird.

Node

Ein Node (Knoten) ist die Repräsentation eines informationstragenden Bestandteils eines (XML-)Dokuments in der dem Dokument entsprechenden Baumstruktur. Knoten sind in einem Baum hierarchisch geordnet, wobei untergeordnete Knoten den ihnen übergeordneten als Inhalt zugerechnet werden. Den verschiedenen Typen von Dokumentbestandteilen werden so viele → Nodetypen zugeordnet wie im → Dokumentbaum über sogenannte → Achsen zugänglich sind.

Node-Sequenz, aktuelle

Die aktuelle Node-Sequenz (current node sequence) ist das Ergebnis eines Aufrufs der Instruktionen xsl:apply-templates oder xsl:for-each. Sie setzt sich zusammen aus all jenen Knoten, die die Ergebnismenge des XPath-Patterns des select-Attributs der jeweiligen Instruktion darstellen. Die Reihenfolge der Knoten in der Sequenz entspricht der → Dokumentreihenfolge, sofern sie nicht durch xsl:sort verändert wurde. In dieser Reihenfolge wird die Liste auch abgearbeitet, jeder ihrer Knoten wird sukzessiv zum → Current Node.

Nodeset

Ein Nodeset ist ein aus XPath 1.0 stammender Begriff, der eine per Definition ungeordnete Sammlung von Knoten bezeichnet. Der Nodeset wird mittels XPath-Pattern aus einem oder mehreren → Dokumentbäumen zusammengestellt. Er kann homogen (Knoten einer einzigen Gattung umfassen), heterogen (verschiedene Knotengattungen) oder leer sein, also keine Knoten enthalten. In XPath 2.0 entspricht dem Nodeset annähernd ein Spezialfall der → Sequenz, die sich ausschließlich aus Knoten zusammensetzt: die Node-Sequenz. Im Gegensatz zu Nodesets gilt eine Sequenz als geordnet, auch kann in Sequenzen ein Knoten prinzipiell mehrfach repräsentiert sein. Solche Dubletten werden jedoch bei der Verarbeitung der Sequenz entfernt, um die Abwärtskompatibilität zum XPath 1.0-Nodeset zu erhalten.

Nodetest

Der Nodetest ist der Teil eines → Location Steps, der alle auf der gewählten → Achse liegenden Knoten prüft. Alle Knoten, die den Nodetest bestehen, werden der Ergebnismenge des Steps hinzugefügt. Der Nodetest kommt in Form eines Namenstests (→ NameTest, Prüfung des Node-Namens) und in Form eines Knotengattungstests (→ KindTest, Prüfung der Knotenart) vor.

Der Namenstest (engl. NameTest) kann aus einem Bezeichner (→ QName) bestehen (z.B. child::beispiel wählt alle Elemente <beispiel> auf der → Child-Achse), aber auch aus sogenannten → Wildcards (Platzhaltern), bei denen der Bezeichner durch einen Stern * substituiert ist: child::* wählt, ausgehend vom Kontextknoten, alle Elemente der Child-Achse, unabhängig von deren Namen aus.

Für namenlose Knoten wird ein Knotengattungstest (engl. KindTest) verwendet, der äußerlich einer Funktion ähnelt. Mit einem KindTest werden die Knoten auf der gewählten Achse anhand der Zugehörigkeit zu einer Gattung ausgewählt. So wählt comment() alle Kommentarknoten, processing-instruction() alle PI-Knoten, text() alle Textknoten; der Test node() schließlich ganz allgemein alle Knoten unabhängig ihres Typs. Für Namensraumknoten existiert kein eigener KindTest.

In XPath 2.0 kommen weitere KindTests für den Dokumentknoten document-node() sowie allgemeine KindTests für Elementknoten element() und Attributknoten attribute() hinzu. Letztere können Argumente übernehmen, die mittels Bezeichner element(bezeichner) und/oder Schema-Typ element(bezeichner, typangabe) bzw. Inhaltsmodell für eine noch genauere Bestimmung modellieren können.

Nodetyp

XPath kennt sieben verschiedene Knotengattungen (Nodetypen), aus denen sich ein → Dokumentbaum zusammensetzt. Eine eigene Gattung für sich bildet der → Document Node. Weiter unterscheidet man → Elementknoten, → Attributknoten, → Textknoten, → Kommentarknoten, → Processing-Instruction-Knoten und → Namensraumknoten. Attribut- und Namensraumknoten sind nur über ihre jeweiligen → Achsen zugänglich, alle anderen Knoten sind auf den sogenannten → Elementachsen zu finden. Zur Unterscheidung von Knotengattungen im Rahmen eines → Location Steps existieren die Node-Test-Funktionen (→ Nodetest), mit denen eine Gattungsprüfung (KindTest) vorgenommen werden kann.

Non Colonized Name

→ NCName

Normalisierung

Unter Normalisierung versteht man das Entfernen von überflüssigen Weißraumzeichen (→ Whitespace) aus einer Zeichenkette. Dabei werden führende und folgende Weißraumzeichen entfernt und Folgen aus mehreren Weißraumzeichen im Inneren des Strings zu einem Leerzeichen zusammengefasst. XPath stellt mit normalize-space() eine Funktion zur Verfügung, die explizit zur Normalisierung von Strings angewendet werden kann. Normalisierung bezieht sich stets auf Strings. Die Entfernung kompletter, ausschließlich aus Whitespaces zusammengesetzter Textknoten zwischen Elementen wird dagegen als → Whitespace-Stripping bezeichnet.

Null-Namensraum

Unter einem Null-Namensraum (null namespace) ist ein Namensraum zu verstehen, dem ein leerer URI-String zugeordnet wurde. Dies ist laut der W3C-Spezifikation für Namensräume nur für den mit xmlns deklarierten Default-Namensraum zulässig, nicht jedoch für Namensräume, denen ein → Namensraumpräfix zugeordnet ist. Folgende Deklaration ist also erlaubt: xmlns="", nicht jedoch: xmlns:mein_prefix="". Die Zuweisung des Null-Namensraums an den Default-Namensraum entspricht der Nichtdeklaration (undeclaration) eines Default-Namensraums.

Number

Der Datentyp Number (number) entspricht in XPath 1.0 einer Gleitkommazahl (floating point number) nach IEEE 754. In XPath 2.0 gibt es, entsprechend der Spezifikation XML Schema Datatypes, drei unterscheidbare Basis-Zahlentypen: xs:decimal (davon abgeleitet: xs:integer), xs:float und xs:double. Sie werden oft gemeinsam unter dem Sammelbegriff numeric angeführt, der jedoch keinen eigenen Zahlentypbezeichner darstellt.

nach oben

O

OASIS

OASIS ist die Abkürzung für Organisation for the Advancement of Structured Information Standards, einer Organisation, die sich mit der Entwicklung und Schaffung von Normen für XML befasst. OASIS ist unter anderem bekannt als Initiator und Eigentümer des → DocBook-Standards.

Output-Methode

In einem XSLT-Stylesheet ist es möglich, mittels der xsl:output-Deklaration die Eigenschaften des Ergebnisdokuments (des Outputs) näher zu bestimmen. Festgelegt werden können mittels des method-Attributs dessen Dokumenttyp (xml, html, text – seit XSLT 2.0 auch xhtml) und mittels des encoding-Attributs die → Encodierung. Darüber hinaus ist eine Vielzahl weiterer Eigenschaften definierbar. In XSLT 2.0 können mittels der Instruktion xsl:result-document mehrere Ergebnisdokumente erzeugt werden, wobei jeweils eine Referenz auf eine benannte xsl:output-Deklaration erfolgen kann.

nach oben

P

Parameter

Ein Parameter wird in XSLT mit xsl:param deklariert und kann als lokaler Parameter innerhalb eines Templates, oder – im Fall der Deklaration als → Toplevel-Element – als globaler Parameter auftreten. Er entspricht in der Verwendung und dem → Gültigkeitsbereich im Wesentlichen einer mit xsl:variable deklarierten Variablen, mit dem Unterschied, dass er von außen mit einem Wert belegt werden kann. Dies geschieht für globale Parameter beim Aufruf des Stylesheets (z.B. durch einen Query-String), bei lokalen Parametern durch die Instruktion xsl:with-param. Wird kein Wert übergeben, so nimmt der Parameter den Wert eines mit dem select-Attribut festgelegten Defaultwerts an.

Eine Neuerung in XSLT 2.0 stellen die sogenannten Tunnelparameter dar, die in einer beliebigen Template-Regel innerhalb eines Aufrufs nachgeordneter Template-Regeln mittels der Instruktion xsl:with-param und dem Attribut tunnel="yes" erzeugt werden. Derart erzeugte Tunnelparameter bilden einen Stream, der auch allen dem aufgerufenen Template nachgeordneten Templates quasi global zur Verfügung steht, ohne diesen jedoch explizit übergeben werden zu müssen. Die Parameter im Tunnel-Stream können dabei jederzeit durch gleichnamige mit anderem Wert überschrieben werden, was gewissermaßen einer Wertneuzuweisung gleichkommt.

Parent-Achse

Die Parent-Achse (parent::) gehört zu den → Elementachsen. Sie zeigt vom → Kontextknoten entgegen der → Dokumentreihenfolge in Richtung auf den übergeordneten Knoten, den Parent-Knoten, den er als Ergebnismenge beinhaltet. Parent-Knoten ist stets ein Elementknoten, da nur dieser Knotentyp Kindknoten besitzen kann. Ein Element gilt auch als Parent seiner Attribut- und Namensraumknoten, die ihrerseits allerdings nicht zu dessen Kindknoten zählen, da sie nicht den Elementachsen angehören. Die → abgekürzte Syntax der Parent-Achse ist »..«.

Parser

→ XML-Parser

Parser, validierender

→ XML-Parser

Path Expression

Unter einer Path Expression (Pfadausdruck) versteht man einen Ausdruck (→ Expression), der eine Nodesequenz (→ Sequenz) aus dem → Quelldokument selektiert. Er hat einen Bezugspunkt, der entweder (relativer Pfadausdruck) aus dem → Kontextknoten besteht oder (absoluter Pfadausdruck) aus dem Dokumentknoten. Die Auswertung führt über einen oder mehrere → Location Steps zu einer Ergebnis-Sequenz.

Pattern

Ein XPath-Pattern ist eine Untergruppe der XPath-Ausdrücke (→ Expressions), die als Vergleichsmuster für Nodes dient. Mittels eines Patterns wird die Zugehörigkeit eines Knotens zu einer Gruppe von Knoten bestimmter Eigenschaften (Wert, Name, Position im Dokument) festgestellt. Bei der Abarbeitung einer Nodesequenz werden daher Pattern verwendet, um die → Template-Regel zu bestimmen, die die Verarbeitung eines anstehenden Knotens vornehmen soll. Das Pattern befindet sich in diesem Fall im match-Attribut der Template-Regel.

PCDATA

Unter PCDATA (#PCDATA, Parsed Character Data) versteht man solche (Text-)Bereiche in XML-Dokumenten, die vom XML-Parser verarbeitet (geparst) und in denen dabei → Entity-Referenzen expandiert werden. Der XSLT-Prozessor verarbeitet bereits geparste Dokumente, in denen Entities entsprechend durch ihren Expansionstext bzw. die Ersatzzeichen ersetzt sind. Dies gilt auch für das XSLT-Stylesheet und in ihm enthaltene XPath-Ausdrücke, die selbst deshalb auch Entities enthalten dürfen.

Platzhalter

→ Wildcard

Portabilität

Unter Portabilität versteht man die Übertragbarkeit eines Programms oder einer Anwendung auf eine andere Plattform. In diesem Sinne sind XSLT-Stylesheets in hohem Maße portabel, da sie auf allen Plattformen lauffähig sind, für die XML-Parser und XSLT-Prozessoren existieren.

Präfix

→ Namensraumpräfix

Präzedenz

→ Importpräzedenz

Precedence

→ Importpräzedenz

Preceding-Achse

Auf der Preceding-Achse (preceding::) befinden sich, entgegen der → Dokumentreihenfolge gezählt, alle diejenigen Knoten, deren Endtags vor dem Starttag des → Kontextknotens stehen. Sie umfasst daher weder den Kontextknoten selbst noch seine Vorfahren (ancestors). Für diese Achse existiert keine → abgekürzte Schreibweise.

Preceding-Sibling-Achse

Die Preceding-Sibling-Achse (preceding-sibling::) umfasst alle Vorgänger des → Kontextknotens, die sich auf der gleichen hierarchischen Dokumentebene befinden wie dieser, nicht aber den Kontextknoten selbst. Die Achse stellt damit eine Teilmenge der → Preceding-Achse dar. Für diese Achse existiert keine → abgekürzte Schreibweise.

Predicate

Ein Predicate ist ein in XPath formuliertes Filterkriterium, das auf die Ergebnismenge eines → Location Steps angewendet werden kann. Die allgemeine Form lautet: achsenbezeichner::node-test[predicate]*, wobei ein oder mehrere Predicates auf einen Step angewendet werden können. Die Auswertung eines Predicates in Bezug auf einen Kanditatenknoten für die Ergebnismenge resultiert in einem booleschen Wert. Ist der Wert true, so wird der geprüfte Knoten der Ergebnismenge hinzugefügt. Während der Auswertung eines Predicates wird der geprüfte Knoten zum → Kontextknoten. In allen anderen Fällen ist der Kontextknoten stets auch gleichzeitig → Current Node.

Prefix

→ Namensraumpräfix

Principal Node Typ

Der Principal Node Type ist der auf einer → Achse vorherrschende Knotentyp. Auf der → Attributachse ist es der Attributknoten, auf der → Namespace-Achse der Namensraumknoten (andere Knotentypen kommen dort jeweils auch nicht vor). Für alle anderen Achsen ist der Elementknoten der Principal Node Type. Da auf diesen Achsen auch andere Knotentypen (Text-, Kommentar- und Processing-Instruction-Knoten) vorkommen, existieren Node-Test-Funktionen (→ Nodetest), die auf diesen Achsen bei Bedarf den Knotentyp testen können.

Priorität (von Template-Regeln)

Die Priorität von Template-Regeln tritt in solchen Fällen in Kraft, in denen mehrere Template-Regeln auf einen zur Verarbeitung anstehenden Knoten angewendet werden können. Da jeweils nur ein Template → instanziiert werden kann, muss definiert werden, welches Template in diesem Fall den Vorrang erhält. Grundsätzlich ist dies das Template mit der spezielleren Regel (match-Attribut), allgemeinere Regeln, die z.B. → Wildcards beinhalten, haben generell niedrigere Priorität. Dies gilt erst recht für die → eingebauten Template-Regeln, die die niedrigste Priorität besitzen. Explizit kann die Priorität einer Template-Regel mit einer Zahl über ihr priority-Attribut festgelegt werden, wobei eine höhere Zahl auch eine höhere Priorität bedeutet.

Priority

→ Priorität (von Template-Regeln)

Processing-Instruction

Processing-Instructions (PIs, Verarbeitungsanweisungen) dienen der Weitergabe von Informationen aus dem XML-Dokument an eine Anwendung. Sie wird eingeleitet mit der Zeichenfolge <? und beendet mit ?>. Der Name der Processing-Instruction ist in der Regel identisch mit dem Namen der Anwendung. Nach einem Leerzeichen folgt ein (optionaler) String, der die weiterzugebenden Daten enthält. PIs werden nicht vom Parser verarbeitet, sondern an die Zielanwendung weitergereicht. Ebenso wie Kommentare zählen sie nicht zum Informationsinhalt des XML-Dokuments. Im Gegensatz zu Kommentaren werden PIs allerdings in jedem Fall weitergegeben. Die allgemeine Form einer PI lautet: <?zielanwendung datenstring?>, wobei der Datenstring Leerzeichen enthalten darf und rein äußerlich auch einer Folge von Attributen ähneln kann. Dies ist beispielsweise der Fall in der PI, die ein XML-Dokument an ein bestimmtes XSLT-Stylesheet bindet: <?xml-stylesheet type="text/xsl" href="mein_stylesheet.xsl"?>. Trotz der optischen Gleichheit wird die → XML-Deklaration nicht zu den Processing-Instructions gezählt. Im → Dokumentbaum werden PIs durch Processing-Instruction-Knoten repräsentiert, die als Kindknoten desjenigen Elements gelten, in dem sie enthalten sind. Der Name der PI entspricht dem der Zielanwendungsangabe, ihr → Stringwert dem zu übergebenden Datenstring.

Prozessanweisung

→ Processing-Instruction

Prolog (des XML-Dokuments)

Der Teil eines XML-Dokuments, der vor dessen → Wurzelelement erscheinen kann, wird als Prolog bezeichnet. Das eigentliche Dokument (Wurzelelement mit Inhalt) stellt den Dokumentrumpf (body) dar. Der Prolog darf entfallen, sollte aber besser zumindest eine → XML-Deklaration enthalten. Darüber hinaus kann der Prolog eine → Dokumenttyp-Deklaration sowie → Kommentare und → Processing-Instructions enthalten.

PSVI

Unter PSVI (Post Schema Validation Infoset) ist der im Anschluss an XML-Parsing und Validierung gemäß eines → XML Schemas erweiterte Dokumentbaum zu verstehen, dessen Knoten anhand des ver´arbeiteten Schemas mit Typbindungen versehen wurden. Der PSVI stellt gewissermaßen das Bindeglied zwischen den Instanzen der Knoten, die einer Applikation zugänglich gemacht werden, und den ihnen zugeordneten »Klassen« (Schema-Typen) dar, gemäß des objektorientierten Paradigmas des Schemas.

Ein ansatzweise implementiertes (internes) Interface für PSVI ist in XNI (Xerces Native Interface) des Apache-Projekts Xerxes 2 enthalten: org.apache.xerces.xni.psvi.

nach oben

Q

QName

Unter einem QName (Qualified Name) ist ein Bezeichner zu verstehen, der sich aus einem lokalen Bezeichner und einem optionalen vorangestellten Namensraumpräfix zusammensetzt. Beide Teile des Namens müssen sogenannte → NCNames sein und werden durch einen Doppelpunkt voneinander getrennt: prefix:local_name. Der XSLT-Prozessor verwendet QNames in ihrer expandierten Form (→ Expanded Name).

Qualified Name

→ QName

Quelldokument

Als Quelldokument wird die XML-Instanz bezeichnet, die im Zuge einer XSLT-Transformation verarbeitet wird. Das XML-Dokument als Instanz entspricht nicht notwendigerweise einer einzelnen XML-Datei, sondern ist als logisches Objekt zu verstehen, das sich aus allen durch den XML-Parser zusammengefügten Teildokumenten (Entities) zusammensetzt. Ein Quelldokument muss bei einer XSLT-Verarbeitung auch dann vorliegen, wenn die in ihm enthaltenen Informationen von Stylesheet nicht benötigt werden. Mit Hilfe der XSLT-Funktion document() oder der XPath 2.0-Funktion fn:doc() durch das Stylesheet in die Verarbeitung hineingezogene XML-Dokumente zählen nicht zum Quelldokument.

nach oben

R

Result Tree

→ Ergebnisbaum

Result Tree Fragment

Unter einem Result Tree Fragment versteht man in XSLT/XPath 1.0 das Ergebnis der Auswertung des Templateblocks einer Variablen. Auch wenn dieses einer Knotenmenge (Nodeset) entspricht, so kann es nicht mit Mitteln von XPath als Nodeset ausgewertet werden, sondern nur so, »wie es ist«, in das Ergebnisdokument kopiert werden. Man spricht deshalb besser von einem »temporären Baum«. Das Defizit bei der Auswertung von RTFs während der Verarbeitung führte zur Entwicklung von Erweiterungsfunktionen wie node-set() (in Saxon), die RTFs in echte Nodesets umwandeln können.

In XPath 2.0 sind vergleichbare Funktionen bereits integriert. (Obendrein ist das Konzept des Result Tree Fragments abgeschafft.)

Reverse Document Order

Die Reverse Document Order ist der → Dokumentreihenfolge entgegengerichtet, die ansonsten die Vorzugsrichtung darstellt. Sie ist für verschiedene Achsen gültig, etwa für die → Ancestor-Achse, die → Parent-Achse, die → Preceding-Achse und für von diesen abgeleitete Achsen.

Root Elements

Speziell im XSLT-Kontext werden die beiden Elemente xsl:stylesheet und xsl:transform als Root Elements bezeichnet, da sie allein die → Wurzelelemente eines XSLT-Stylesheets bilden können. Der Begriff ist nicht zu verwechseln mit → Root Node.

Root Node

Der Begriff Root wurde im XSLT-Kontext ursprünglich für den → Document Node verwendet. Er ist gleichzeitig aber auch für das → Wurzelelement von XML-Dokumenten (dann: root element) gebräuchlich. Document Node und Wurzelelement sind aber nicht identisch und müssen deshalb unbedingt auseinander gehalten werden. Im XSLT-Kontext sollte daher stets der Begriff Document Node verwendet werden, um Verwechselungen vorzubeugen.

nach oben

S

Scalable Vector Graphics

SVG

Schema

Unter den Begriff Schema fallen alle Beschreibungsformen für Form und Inhalt von XML-Dokumenten, etwa → DTDs oder → XML Schema. Darüber hinaus gibt es noch Ansätze wie XML-Data Reduced (Microsoft) und weitere, die entweder überholt oder proprietär sind.

Schema-Aware XSLT Processor

→ XSLT-Prozessor

Schlüsseldefinition

→ Keydefinition

Scope

→ Gültigkeitsbereich von Variablen

Self-Achse

Die Self-Achse (self::) umfasst nur einen einzelnen Knoten, nämlich den Kontextknoten selbst. Die abgekürzte Syntax ist ».«. Dieser ist in der Regel identisch mit dem → Current Node, der auch Rückgabewert der XPath-Funktion current() ist. Eine Ausnahme hierzu besteht innerhalb von → Predicates, bei deren Auswertung der jeweils getestete Knoten zum Kontextknoten wird.

Sequenz

XPath 2.0 verallgemeinert das Ergebnis von XPath-Ausdrücken zu sogenannten Sequenzen (sequences). Unter einer Sequenz ist eine geordnete Sammlung (collection) aus beliebig vielen (null oder mehr) → Items zu verstehen. Ein Item kann entweder ein einfacher Wert, z.B. ein String, eine Zahl oder ein Wahrheitswert, oder ein Knoten (→ node) sein. Sequenzen können heterogen sein, sich also aus Knoten und einfachen Werten zusammensetzen. Damit stellt der → Nodeset aus XPath 1.0 den Spezialfall einer Sequenz dar, die nur aus Node-Items besteht. Als → Literale dargestellt werden Sequenzen durch runde Klammern (als »ParenthesizedExpr«), die eine kommagetrennte Liste der Items enthalten: (1, 2, 3, 4, 5). Hierbei sind auch Ausdrücke möglich, die eine fortlaufende Zahlenreihe konstruieren (als »RangeExpr«): (1 to 5) ist gleichbedeutend mit der vorherigen Sequenz. Die leere Sequenz wird mit () dargestellt.

Sequenzkonstruktor

→ Template-Body

Serialisierung

Unter Serialisierung versteht man die Ausgabe des Ergebnisbaums als Quelltext in eine Datei. Hierfür wird der → Dokumentbaum »geplättet«, d.h. seine Elementknoten ausgehend vom → Wurzelelement in Start- und Endtag aufgespalten und als Textrepräsentierung mit ihren Inhalten und Attributen in sequenzieller Form in die Ausgabedatei geschrieben. Voraussetzung für eine erfolgreiche Serialisierung ist eine definierte → Dokumentreihenfolge (geordneter Baum), was in XML-Dokumenten die Regel ist. Der umgekehrte Vorgang – der Aufbau eines Baums aus einer serialisierten Datei – wird als → Deserialisierung bezeichnet.

Die Serialisierung von Dokumenten durch XSLT und XQuery ist in einer eigenen W3C-Spezifikation beschrieben: »XSLT 2.0 and XQuery 1.0 Serialization«.

SGML

Die Standardized General Markup Language (SGML) wurde bei IBM 1969 von Ch. Goldfarb, E. Mosher und R. Lorie als GML aus der Taufe gehoben und gilt als Prototyp moderner Markup-Sprachen. In Folge als ISO 8879 standardisiert, dient SGML der Beschreibung von komplexen Informationsstrukturen. SGML gilt als eine extrem mächtige, und daher auch äußerst komplexe Beschreibungssprache, die als Grundlage für die von ihr abgeleiteten Markup-Sprachen dient. Wichtigste Beispiele für von SGML abgeleitete Sprachen sind HTML (im Sinne einer SGML-Anwendung) und XML. Letzteres ist selbst eine Meta-Markup-Sprache, die als vereinfachte Form (Subset) von SGML deren Aufgaben weitgehend übernommen hat.

Simplified Stylesheet

→ Vereinfachtes Stylesheet

SMIL

SMIL ist die Abkürzung von Synchronized Multimedia Integration Language, einem W3C-Standard, der XML zur Beschreibung von Multimedia-Anwendungen verwendet. Man unterscheidet inzwischen die alte Spezifikation SMIL 1.0 (Juni 1998), SMIL 2.0 (Januar 2005) und SMIL 3.0 (Dezember 2008).

Source Document

→ Quelldokument

Sprache (eines Elementinhalts)

→ Language

Standalone

Mit dem standalone-Attribut in der → XML-Deklaration wird dem Prozessor mitgeteilt, ob es erforderlich ist, nach einer DTD-Untermenge (external subset) außerhalb des Dokuments zu suchen. Erlaubte Werte sind "no" (Defaultwert, wenn das Attribut nicht verwendet wird) und "yes". Dabei bedeutet standalone="yes" zusätzlich, dass keine externen Parameter-Entities existieren können, die berücksichtigt werden müssten. Der Wert standalone="no" sagt dagegen aus, dass möglicherweise, aber nicht zwangsläufig, externe DTD-Deklarationen vorhanden sein können.

Step

→ Location Step

String

Ein String (Zeichenkette) gehört zu den → primitiven Datentypen. Er setzt sich aus einer beliebigen Folge von Unicode-Zeichen zusammen, wobei Whitespace-Zeichen als normale Zeichen gelten und als → relevanter Whitespace betrachtet werden. In XSLT 2.0/XPath 2.0 kann ein String als → atomarer Wert ein gleichberechtigter Bestandteil (→ Item) einer → Sequenz sein.

String Value

→ Stringwert

Stringwert

Der Stringwert eines Knotens entspricht seiner enthaltenen Textinformation, deren Form und Aufbau abhängig vom Knotentyp (→ Nodetyp) ist. Der Stringwert eines Kommentars besteht in der enthaltenen auskommentierten Zeichenkette. Der Stringwert des Knotens einer → Processing-Instruction entspricht der an die Zielapplikation übergebenen Zeichenkette, die die Instruktionen enthält. Der Stringwert eines → Namensraumknotens ist der URI des Namensraums. Der Stringwert eines → Textknotens ist der enthaltene Text, der eines → Attributknotens der Attributwert. Der Stringwert eines Elementknotens schließlich entspricht der Verkettung (concatenation) in → Dokumentreihenfolge der Textknoten all seiner → Kindknoten (einfacher ausgedrückt, dem fortlaufenden Textinhalt ohne Berücksichtigung von Element-Markup).

Stylesheet

Unter Stylesheets sind unabhängige, in einer Darstellungsdefinitionssprache geschriebene Anweisungen zu verstehen, die auf ein anderes Dokument angewendet werden, das die zu präsentierenden Informationen beinhaltet. Grundidee hierbei ist die Trennung von Information und Darstellung. Beispiele für Stylesheetsprachen sind → DSSSL, das in Verbindung mit → SGML eingesetzt wird, oder Cascading Stylesheets (CSS). In der Version »CSS Level 2« wird CSS zur Präsentation von XML-Dokumenten verwendet. Hierbei können nur Darstellungsanweisungen gegeben, das Dokument jedoch nicht umgeformt werden.

Auch XSL-Transformationsanweisungen (XSLT) werden traditionell als »Stylesheets« bezeichnet, obwohl sie weniger auf die Präsentation von Informationen zielen, als auf deren Transformation (im Sinne von Umwandlung). Ergebnis einer Transformation kann jedoch ein Dokument in einer Form sein (z.B. HTML oder → XSL-FO), die von einer Zielanwendung unmittelbar präsentiert werden kann. Die Stylesheetmetapher spiegelt sich wider in der Benennung des XSLT-Wurzelelements xsl:stylesheet, für das es aber auch die – eigentlich korrekter bezeichnete – Alternative xsl:transform gibt.

Stylesheetfunktion

Ab XSLT 2.0 ist es dem Programmierer des Stylesheets möglich, mittels der Deklaration xsl:function eigene → Funktionen zu definieren. Diese werden als Stylesheetfunktionen bezeichnet, da sie während der Laufzeit des sie definierenden Stylesheets innerhalb von dessen XPath-Ausdrücken verwendet werden können wie normale XPath-Funktionen auch. Eine solche Stylesheetfunktion muss mit einem → QName mit → Namensraumpräfix benannt werden, der an einen nicht leeren Namensraum-URI gebunden ist. Es sollte durch Fallback-Optionen sichergestellt sein, dass auch ältere Prozessoren das Stylesheet ausführen können.

SVG

SVG ist eine durch das W3C definierte XML-Anwendung zur Beschreibung zweidimensionaler Vektorgrafiken. Neben stufenloser Skalierbarkeit sind Filtereffekte wie z.B. Schattenwurf, Beleuchtung, Weichzeichnung oder Verzerrung möglich. Derzeit benötigt man noch Plugins (z.B. Adobe SVG-Viewer), um in Webseiten eingebettete SVG-Grafiken im Browser betrachten zu können.

System Properties

Unter dem Begriff System Properties (Systemeigenschaften) werden die Informationen zusammengefasst, die der XSLT-Prozessor über sich und seine Eigenschaften zur Verfügung stellt. Ein XSLT-Stylesheet kann diese mittels der XSLT-eigenen Funktion system-properties('property-name') auslesen: Der Name der abzufragenden Systemeigenschaft wird der Funktion hierbei als String übergeben. Obligatorisch auslesbar sind die unterstützte XSLT-Version ('xsl:version'), der Name des Herstellers des Prozessors ('xsl:vendor') und dessen URL ('xsl:vendor-url'). Über diese stets implementierten Abfragemöglichkeiten hinaus kann ein XSLT-Prozessor beliebige weitere Informationen zur Verfügung stellen.

nach oben

T

Tag

Als Tag (Marke) wird im Rahmen einer Markup-Sprache eine Bereichsmarkierung bezeichnet, die Beginn (Starttag bzw. Startmarke) und Ende (Endtag bzw. Endmarke) eines Dokumentabschnitts kennzeichnet und diesem eine Bedeutung zuweist. In XML haben Tags die Funktion einer rein logischen Auszeichnung im Sinne von Metainformationen (→ Metadaten) über ihren jeweiligen Inhalt.

Template

→ Template-Regel

Template, benanntes

Ein benanntes Template (named template) wird, im Gegensatz zu einem normalen Template (→ Template-Regel) über einen Bezeichner angesprochen, der mit dem name-Attribut vergeben wird. Der Aufruf erfolgt aus einem anderen Template mittels xsl:call-template. Zu beachten ist, dass der ursprüngliche → Current Node des aufrufenden Templates im benannten Template weiterhin gültig bleibt.

Template-Body

Unter Template-Body ist primär der Inhalt eines xsl:template-Elements zu verstehen, im weiteren Sinne (in XSLT 1.0) aber auch der Inhalt jeder anderen XSLT-Instruktion, insofern dieser zur Erzeugung von Teilen von Inhalten des/eines Ergebnisdokuments dient. Ein solcher Template-Body besteht aus → Literal Result Elements und weiteren XSLT-Instruktionen, die ihrerseits letztlich eine Ausgabe in das → Ergebnisdokument zur Folge haben.

In XSLT 2.0 wird der Template-Body sinnvollerweise formal als Sequenzkonstruktor bezeichnet (da dieser nicht mehr direkt in ein Ergebnisdokument, sondern eine zu serialisierende Resultatsequenz ausgibt), während der früher verwendete Begriff »Template« den Bedeutungsumfang eher unzureichend beschreibt.

Template-Mode

Einer → Template-Regel, d.h. einem Template mit match-Attribut, kann zusätzlich mit Hilfe des mode-Attributs ein sogenannter Modus (mode) beigegeben werden, der bei Zusammenstellung einer für dieses Template passenden Nodesequenz aufgerufen werden muss. Dann und nur dann wird diejenige Template-Regel, die den aufgerufenen Modus besitzt, aktiviert.

Template-Regel

Unter einer Template-Regel (Template Rule), kurz auch einfach als Template bezeichnet, versteht man ein xsl:template-Element mit match-Attribut. Das XPath-Pattern des match-Attributs stellt ein Vergleichsmuster dar, auf das hin die Nodes der aktuellen Nodesequenz geprüft werden. Für jeden aktuell anstehenden Knoten dieser Sequenz wird jeweils die Template-Regel instanziiert, die das am besten passende Vergleichsmuster (die höchste → Priorität) besitzt. Der verarbeitete Knoten wird für die Laufzeit dieses Templates zum → Current Node.

Besitzt ein Template kein match-, sondern ein name-Attribut, so bezeichnet man es als benanntes Template (→ Template, benanntes).

Template-Regeln, eingebaute

Ein XSLT-Prozessor kennt mehrere sogenannte eingebaute Template-Regeln, die ausgeführt werden, als ob sie explizit im XSLT-Stylesheet stehen würden. Sie umfassen allgemeine Regeln für → Elementknoten (und den Document Node) und ermöglichen so die Verarbeitung von → Kindknoten solcher Elemente, für die keine eigenen Regeln definiert sind. Für → Textknoten gilt die allgemeine Regel, ihren Inhalt in das → Ergebnisdokument zu kopieren. Das gleiche gilt für → Attributknoten. → Kommentarknoten und → Processing-Instructions werden auf Grund einer eingebauten Regel ignoriert. Die eingebauten Template-Regeln können jederzeit durch selbst definierte Regeln mit höherer → Priorität überschrieben werden.

Template Rule

→ Template-Regel

Temporary Tree

→ Result Tree Fragment

Textdeklaration

Für externe geparste Entities, die keine selbstständigen, wohlgeformten XML-Dokumente darstellen, gibt es dennoch die Möglichkeit, eine Zeichen-Encodierung (→ Encodierung) zu deklarieren. Dies geschieht mit einer sogenannten Textdeklaration, die der → XML-Deklaration von der Form her entspricht. Im Gegensatz zur XML-Deklaration darf jedoch das version-Attribut entfallen. Eine Textdeklaration kann daher folgende Form besitzen: <?xml encoding="ISO-8885-1"?>.

Textknoten

Unter einem Textknoten ist ein zusammenhängender Bereich von → CDATA (Character Data)-Zeichen zu verstehen, der nicht durch Elemente unterbrochen wird. Textknoten gelten als → Kindknoten des Elements, in dem sie stehen; sie sind also über die → Child-Achse erreichbar und werden unverändert in das → Ergebnisdokument kopiert. Textknoten aus reinen → Whitespace-Zeichen (Whitespace-Nodes) können durch → Whitespace-Stripping entfernt werden. Die Stringwerte von Attribut- Kommentar- und Processing-Instruction-Knoten zählen nicht zu den Textknoten.

Text Node

→ Textknoten

Token

Unter Token versteht man die unteilbaren Symbole einer formalen Sprache. Darunter fallen sowohl Symbole, beispielsweise für Operatoren, als auch Schlüsselworte (key words) wie vordefinierte Befehle oder nach den Sprachregeln vereinbarte Bezeichner. Token können daher auch Zeichenketten sein, für die aber bestimmte Produktionsregeln (wie beispielsweise die für XML-Namen) gelten. Ein Token darf keine Leerzeichen enthalten.

Tokenliste

Unter einer Tokenliste versteht man eine Folge von → Token, die in der Regel durch Leerzeichen (bzw. nach neuer Lesart durch beliebige → Whitespace-Zeichen) voneinander getrennt sind (weshalb ein einzelnes Token auch keine Leerzeichen enthalten darf). Beispiel für Tokenlisten sind Attributwerte für IDREFS- oder NMTOKEN-Attribute.

Toplevel-Element

Mit dem Begriff Toplevel-Elemente wird in XSLT die Gruppe der XSLT-Deklarationen bezeichnet, die als unmittelbare Kindelemente des → Wurzelelements xsl:stylesheet stehen dürfen. Das wichtigste von ihnen ist das Element zur Formulierung von → Template-Regeln, xsl:template. In XSLT 1.0 gibt es dreizehn, in XSLT 2.0 fünfzehn Toplevel-Elemente. Die restlichen XSLT-Elemente werden als → Instruktionen bezeichnet.

Tree

→ Dokumentbaum

Tunnelparameter

→ Parameter

Typfehler

Ein Typfehler wird in XPath 2.0 durch einen einer Funktion übergebenen Wert erzeugt, dessen Typ nicht dem von der Funktion erwarteten → Datentyp entspricht. Typfehler zählen zu den non-recoverable errors, das heißt, die Verarbeitung muss(!) bei Auftreten eines Typfehlers abgebrochen werden. Diese Regelung wurde im Hinblick auf die Typintegrität des Ergebnisses einer XSLT-Transformation getroffen. Typfehlern kann durch explizite → Typumwandlung mittels entsprechender Umwandlungsfunktionen oder durch sogenanntes Casting vorgebeugt werden. Im günstigsten Fall kann ein Typfehler während der Transformation auf diesem Wege vermieden oder (bei fehlgeschlagenem Casting) zumindest im Vorfeld als statischer Fehler gemeldet werden.

XPath 1.0 kennt, da es im Gegensatz zu XPath 2.0 nur lose typisiert ist, keine Typfehler.

Typgültigkeit

Unter Typgültigkeit ist die Gültigkeit eines XML-Dokuments gegenüber einer → DTD oder einem → Schema zu verstehen. Im Rahmen von XML wird zwischen typgültigen und wohlgeformten Dokumenten unterschieden. Ein Dokument, das nicht typgültig ist, weil es entweder nicht mit einer DTD verbunden ist oder die Regeln der DTD nicht erfüllt, kann dennoch den Status der Wohlgeformtheit erreichen. Voraussetzung ist, dass das Dokument die → Wohlgeformtheitsregln einhält.

Typumwandlung

Typumwandlung ist die Umwandlung eines Werts, der in einem bestimmten → Datentyp vorliegt, in einen entsprechenden Wert eines anderen Datentyps. Eine Typumwandlung ist im Laufe der Verarbeitung eines XSLT-Stylesheets öfter notwendig. In XSLT 1.0/XPath 1.0 wird sie meist implizit vorgenommen, um einen Eingangsdatentyp an den in einem Ausdruck (z.B. in einem Funktionsaufruf) erforderlichen Typ anzupassen. In XPath 2.0 geschieht keine automatische Typumwandlung, vielmehr wird ein → Typfehler gemeldet und die Verarbeitung abgebrochen. Es gibt die Möglichkeit, Typumwandlungen mittels der XPath-Funktionen fn:boolean(), fn:number(), fn:string() oder der entsprechenden Castingfunktionen explizit vorzunehmen.

nach oben

U

UNICODE

Für die ursprüngliche ASCII-Zeichenmenge, die 128 verschiedene Zeichen umfasst, wurde ein 7-Bit-Schema verwendet, das später auf ein 8-Bit-Schema erweitert wurde. Letzteres lässt die Unterscheidung zwischen immerhin 256 Zeichen zu, was aber nur im Angloamerikanischen Sprachraum ausreicht. XML unterstützt mit seinem universalen Ansatz den Unicode-Standard, der ein 16-Bit-Muster verwendet und die Möglichkeit bietet, pro Zeichensatz (→ Encodierung) jeweils 65.000 Zeichen darzustellen. In XML sind daher alle in Unicode 2.1 (entspricht ISO/IEC 10646) definierten Zeichen verwendbar.

Unparsed Entity

Beim Parsen des XML-Dokuments wird eine Entity-Referenz im Allgemeinen expandiert, d.h. der Ersetzungstext in das Dokument eingefügt. Mit Referenzen auf Entities, die aus binären Daten bestehen, kann allerdings nicht auf diese Weise verfahren werden, weil sie nicht in XML- bzw. Textform vorliegen. Da sie somit (höchstwahrscheinlich) die Wohlgeformtheitsregeln verletzen, dürfen sie nicht geparst werden. Als weitere Besonderheit können Referenzen auf ungeparste Entities nur als Attributwerte entsprechend deklarierter Attribute vom Typ ENTITY oder ENTITIES auftreten. Als Referenz dient dann der Name des Entitys; das ansonsten übliche einleitende & und folgende Semikolon entfallen. Ein unparsed Entity wird folgendermaßen deklariert: <!ENTITY bild SYSTEM "/img/bild.gif" NDATA GIF>. Das Schlüsselwort NDATA gibt dem Parser den Hinweis, dass es sich um ein externes Entity handelt, das nicht geparst werden darf.

URI

Ein URI ist ein Universal Resource Identifier, der als Oberbegriff entweder einen → URL oder einen → URN bezeichnet. Ein URI wird eingesetzt, um eine beliebige Ressource im Internet zu bezeichnen, wobei entweder eine Adresse (URI) oder ein festgelegter Name (URN) verwendet wird.

URL

Ein URL ist ein Universal Resource Locator, eine eindeutige Adressangabe einer Ressource im Internet. Das allgemeine Format eines URL lautet: protokoll://servername/pfad/resourcenbezeichner. Als Protokolle finden gewöhnlich HTTP oder FTP Verwendung.

URN

Ein URN ist ein Uniform Resource Name, der eine Internetressource über ihren Namen beschreibt statt über eine Adresse. Dies geschieht analog zum PUBLIC-Identifier einer XML-Ressource. Es wird davon ausgegangen, dass eine Person oder ein Programm in der Lage ist, diese Ressource über ihren Bezeichner aufzufinden (beispielsweise eine Kopie davon einem lokalen Repository zu entnehmen), und dass die Angabe einer absoluten Adresse demzufolge nicht erforderlich ist.

UTF-8, UTF-16

Das UTF-8 Format ist ein Unicode-Format, das je dargestelltem Zeichen eine variable Anzahl von Bits verwendet. Es ist die Standard-Encodierung (→ Encodierung) von XML-Dokumenten, lässt aber im Gegensatz zur → ISO-8859-Familie nicht die unmittelbare Verwendung von Umlauten im Dokument zu. Diese müssen, solange kein anderes Encoding vereinbart wird, in Form von → Character Entities eingesetzt werden. UTF-16 ist eine Abwandlung von UTF-8, bei der stets 16 Bit (2 Byte) pro Zeichen verwendet werden. Der XML-Parser ist anhand der ersten Zeichen der → XML-Deklaration auch bei Abwesenheit eines encoding-Attributs in der Lage, zwischen diesen beiden Formaten zu unterscheiden.

nach oben

V

Valid

→ Typgültigkeit

Validierender Parser

→ Parser, validierender

Validierung

Unter Validierung eines XML-Dokuments versteht man den Vorgang der Prüfung auf Einhaltung einer mit dem Dokument verbundenen → DTD oder eines Schemas durch einen validierenden → XML-Parser. Ein Dokument, das die Validierung besteht, wird als gültig bzw. typgültig (valid) bezeichnet (→ Typgültigkeit).

Variable

Eine Variable wird in XSLT mit xsl:variable deklariert und kann als lokale Variable innerhalb eines Templates, oder – im Fall der Deklaration als Toplevel-Element – als globale Variable auftreten. Ihr → Gültigkeitsbereich erstreckt sich für eine globale Variable auf das gesamte Stylesheet, im Falle einer lokalen Variablen nur auf die Template-Regel, in der die Deklaration erfolgt. Der Wert einer Variable wird entweder aus dem XPath-Ausdruck ihres select-Attributs oder aus einem optionalen Templateblock im Inneren der Variablendeklaration bestimmt. Der Name der Variable wird durch ihr name-Attribut festgelegt, die Referenzierung erfolgt in XPath-Ausdrücken im Bereich der Gültigkeit durch den Namen mit vorangestelltem $-Zeichen: $meine_variable.

Variable Binding

→ Variable

Vereinfachtes Stylesheet

In manchen Fällen kann die Komplexität eines Stylesheets durch Weglassen des → Wurzelelements xsl:stylesheet stark reduziert werden. Soll das → Ergebnisdokument beispielsweise eine HTML-Datei in weitgehend festgelegter Form sein, so kann <html> direkt als Wurzelelement für das Stylesheet verwendet werden, in dem dann aber die XSLT-Version und der XSLT-Namensraum mit Präfix xsl: vereinbart werden müssen: <html xsl:version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">. Ein Stylesheet dieser Art besteht daher aus einer HTML-Seite in der XSLT-Instruktionen verwendet werden dürfen, nicht jedoch → Toplevel-Elemente. Aus diesem Grund können keine → Template-Regeln (xsl:template) vorkommen, sondern lediglich in den Fluss des Dokuments eingefügte Anweisungen, die Informationen aus dem verarbeiteten XML-Dokument extrahieren und in die HTML-Seite einfügen.

Vergleichsmuster

→ Pattern

Vorgabewert

→ Defaultwert

nach oben

W

Wahrheitswert

→ Boolescher Wert

Well-balanced

Ein XML-Fragment, das als externes geparstes → Entity in ein Hauptdokument eingebunden wird, muss nicht notwendig → well-formed sein. Es unterliegt aber ebenfalls, wenn auch in geringerem Maße, den → Wohlgeformtheitsregeln. Nicht erforderlich ist ein einzelnes → Wurzelelement, weshalb ein XML-Fragment auch nicht als → Dokumentbaum dargestellt werden kann (es könnte in mehrere Bäume zerfallen). Wichtig ist hingegen, dass Elemente korrekt geschlossen und verschachtelt sind. Durch das Einfügen (Expandieren) eines solchen Fragments darf die Wohlgeformtheit des Hauptdokuments nicht gefährdet werden. Ein Fragment, das in diesem Sinne verwendbar ist, wird als well-balanced bezeichnet. Es darf eine eigene Deklaration besitzen, um eine → Encodierung festzulegen. Diese wird, da es sich nicht um ein echtes XML-Dokument handelt, jedoch → Textdeklaration genannt.

Well-formed

Ein XML-Dokument ist well-formed (wohlgeformt), wenn es den → Wohlgeformtheitsregeln gerecht wird. Die Wohlgeformtheit ist Voraussetzung der Typgültigkeit, die zusätzlich die Gültigkeit auf eine vorhandene → DTD umfasst. Ein nicht wohlgeformtes Dokument wird nicht als korrektes XML-Dokument betrachtet und von XML-Parsern in jedem Fall zurückgewiesen.

Weißraum

→ Whitespace

Whitespace

Unter Whitespace werden in XML 1.0 pauschal die vier Weißraumzeichen Leerzeichen (SPC, #20), Zeilenumbruch (LF, #0A), Tabulator (TAB, #09) und Wagenrücklauf (CR, #0D) verstanden. In XML gilt Weißraum im Quelldokument grundsätzlich als signifikant, wird also vom → XML-Parser stets an die Folgeanwendung (z.B. den XSLT-Prozessor) weitergereicht, die damit dann nach Belieben verfahren kann. Eine Ausnahme hierbei können die Zeichen für das → Zeilenende im Quelltext sein.

XML 1.1 erweitert den Vorrat an Whitespace-Zeichen um das NEL-Zeichen (Newline, U+0085 bzw. #x85) aus dem IBM-Mainframe-Bereich, sowie um das Unicode-Zeilentrennzeichen #x2028. Bisher durften diese in XML-Dokumenten nicht enthalten sein, weshalb XML 1.1-Dokumente streng genommen keine wohlgeformten XML 1.0-Dokumente darstellen.

Whitespace-Textnodes

Unter Whitespace-Textnodes werden solche → Textknoten verstanden, die sich nur aus → Whitespace-Zeichen zusammensetzen. Sie entstehen zwischen Elementen bereits durch Zeilenumbrüche (C→ oder LF) im Quelltext oder durch Einrückungen im Quelltext mittels Leerzeichen (SPC) oder Tabulator (TAB). Das Entfernen von Whitespace-Nodes wird als → Whitespace-Stripping bezeichnet und ist nicht mit → Normalisierung zu verwechseln.

Whitespace-Stripping

Unter Whitespace-Stripping versteht man das Entfernen solcher → Textknoten zwischen Elementen, die ausschließlich aus Whitespace-Zeichen wie Leerzeichen (SPC), Zeilenumbruch (LF), Tabulator (TAB) und Wagenrücklauf (CR) bestehen. Im Inneren von Elementen, die auch Textknoten enthalten (→ Mixed Content) spricht man bei der Entfernung von führendem oder folgendem Leerraum hingegen von → Normalisierung.

Wildcard

Als Wildcard wird im Allgemeinen ein Platzhalter bezeichnet, der für einen unbekannten oder nicht näher bestimmbaren Bezeichner einer benannten Größe steht. In XPath werden Wildcards im Rahmen von → Nodetests, genauer gesagt bei → NameTests eingesetzt. Ein Wildcard wird durch das Symbol * dargestellt und an jener Position im → Location Step eingesetzt, wo normalerweise ein Element- oder Attributbezeichner steht. So steht der Ausdruck attribute::* für ein beliebig benanntes Attribut des → Kontextknotens, child::* für ein beliebig benanntes Element, das → Kindknoten des Kontextknotens ist. Mit den → abgekürzten Achsenbezeichnern lauten äquivalente Ausdrücke @* bzw. *. Ein Wildcard kann für einen → QName stehen, aber auch für den lokalen Teil bzw. den Präfixteil eines QNames eingesetzt werden. So bedeutet mein_prefix:* ein Element mit dem Präfix mein_prefix und beliebigem → Local Name, der Ausdruck *:mein_name Elemente mit lokalem Bezeichner mein_name und beliebigem Präfix.

Wohlgeformtheit

→ Well-formed

Wohlgeformtheitsregeln

Ein XML-Dokument muss bestimmte Wohlgeformtheitsregeln einhalten, andernfalls handelt es sich nicht um ein XML-Dokument. Es sind vor allem vier Grundregeln zu beachten:

  1. Es gibt genau ein → Wurzelelement des Dokuments, das den gesamten Inhalt enthält (der → Prolog des Dokuments gehört in diesem Sinne nicht zum Inhalt).
  2. Alle Elemente müssen korrekt verschachtelt sein. Überlappende Bereiche sind verboten, da sie die Eindeutigkeit der Zuordnung der Inhalte unmöglich machen würden.
  3. Alle Elemente müssen geschlossen sein, also einen Start- und einen Endtag besitzen. Für leere Elemente führt dies zur XML-typischen Schriebweise <leeres_element/>.
  4. Alle Attributwerte müssen in Anführungszeichen stehen.

Erfüllt ein XML-Dokument diese Kriterien und darüber hinaus die Regeln einer DTD, so wird es als typgültig bezeichnet. Wohlgeformtheit ist daher Voraussetzung für → Typgültigkeit.

Externe geparste Entities unterliegen ebenfalls den Wohlgeformtheitsregeln, allerdings in einem geringeren Maße – es entfällt die erste Forderung nach einem Wurzelelement. Es handelt sich daher auch nicht um selbstständige XML-Dokumente, sondern um XML-Fragmente. Ihr Status wird nicht als → well-formed, sondern als → well-balanced beschrieben.

Wurzelelement

In jedem XML-Dokument gibt es genau ein Element, das den Container für alle weiteren Inhalte bildet: das Wurzelelement. Existiert eine → DTD, so erscheint der Bezeichner des Wurzelelements normalerweise auch als Name der DTD in der → Document Type Declaration.

nach oben

X

XML-Datenbank

Unter einer XML-Datenbank versteht man ein für die Lagerung von XML-Daten optimiertes Datenbanksystem. Da Daten in XML-Form bereits eine Strukturbeschreibung in sich tragen, eignet sich dieses Format besonders für solche Informationen, deren Struktur nicht vollständig vorherbestimmbar ist. Die Informationsstruktur von XML-Daten kann einerseits hierarchisch sein, andererseits auch relational – was eine Speicherung in relationalen Datenbanken (RDBS) möglich macht. Da die Strukturen aber prinzipiell variabel sind, ist die Verwendung relationaler Datenbanken älteren Designs oft schwierig. Von vielen Herstellern erfolgt derzeit eine Anpassung in Bezug auf XML-Fähigkeit. Dass XML-Datenbanken deshalb als eigenständige Gattung betrachtet werden müssen, ist zumindest strittig. Ein bekanntes XML-Datenbanksystem ist beispielsweise Tamino.

XML-Deklaration

Die XML-Deklaration ist als optionale Einleitung eines XML-Dokuments Teil des → Prologs des XML-Dokuments. Obwohl sie prinzipiell optional ist, sollte sie dennoch verwendet werden, da sie die einzige Möglichkeit darstellt, dem Dokument einen anderen als den Default-Zeichensatz → UTF-8 zuzuweisen. Wird die XML-Deklaration verwendet, so muss sie strikt am Beginn des Dokuments stehen, d.h. es dürfen keine Leerzeichen, Leerzeilen oder Kommentare zuvor stehen. Vorgeschriebenes Attribut ist version, das als Wert den verwendeten XML-Versionsstand erhalten muss. Des Weiteren sind als optionale Attribute (aber strikt in dieser Reihenfolge) zu verwenden: encoding zur Festlegung des Zeichensatzes (→ Encodierung) sowie standalone (→ Standalone), um die Abhängigkeit von einer → DTD zu deklarieren. Typischerweise sieht die Deklaration folgendermaßen aus: <?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>. Trotz der äußerlichen Ähnlichkeit zählt man die XML-Deklaration nicht zu den Processing-Instructions. Die Deklaration kann auch einem externen geparsten Entity vorangesetzt werden. Dann bezeichnet man sie allerdings nicht mehr als XML-Deklaration, sondern als → Textdeklaration.

XML-Parser

Bei der Verarbeitung von XML-Dokumenten werden durch die XML-Spezifikation zwei Instanzen unterschieden: der XML-Parser und die Anwendung, wobei der Parser der Anweisung vorangeschaltet ist und das geparste Dokument an diese weiterreicht. Das Verhalten der Anwendung ist in der W3C-Spezifikation nicht näher bestimmt. Die Aufgabe des Parsers beim Einlesen eines Dokuments besteht primär in der Prüfung auf Einhaltung der → Wohlgeformtheitsregeln. Tritt an dieser Stelle ein Verstoß auf, so wird das Dokument zurückgewiesen, die weitere Verarbeitung abgebrochen und ein kritischer Fehler (critical error) gemeldet. Eine weitere (nicht festgeschriebene) Aufgabe des Parsers besteht in einer Vereinheitlichung der im eingelesenen Dokument verwendeten Zeichen für ein → Zeilenende.

Besteht das Dokument den Test, so führt der Parser die Expansion von → Entiy-Referenzen durch. Externe und interne Ersetzungstexte werden ihrerseits geparst und in das Dokument eingefügt, Character Entities durch die vertretenen Zeichen ersetzt. Als letzter Schritt wird der → Dokumentbaum aufgebaut. Man unterscheidet zwischen validierenden und nicht validierenden Parsern. Nicht validierende Parser prüfen lediglich auf Wohlgeformtheit (auch wenn eine → DTD vorliegt), die validierenden Parser darüber hinaus auf → Typgültigkeit, also die Einhaltung einer vorliegenden DTD.

XML Schema

XML Schema dient – alternativ zu → DTDs – zur Beschreibung der Struktur von XML-Dokumenten, zur Beschreibung von Inhaltsmodellen sowie dem Zuordnen von Datentypen zu XML-Elementtypen und -attributen. Die Spezifikation zerfällt in zwei Teile, in Struktur- und Datentypbeschreibung. XML Schema ist den bisher verwendeten DTDs in vieler Hinsicht überlegen, allerdings um den Preis einer wesentlich höheren Komplexität. Die übliche Dateiendung von XML Schema-Definitionen ist .xsd.

XPath

Die XPath Language ist eine Pfadbeschreibungssprache, die zum Adressieren von Teilen eines XML-Dokuments verwendet wird. XPath wird sowohl von XSLT als auch von XPointer verwendet. Die Sprache verwendet sogenannte → Pattern als Adressierungspfade. Darüber hinaus können beliebige → Ausdrücke gebildet werden, die Strings, Zahlen, boolesche Werte oder Knotenmengen ergeben. In Verbindung mit → XSLT 1.0 wird XPath 1.0 verwendet, mit XSLT 2.0 das wesentlich erweiterte XPath 2.0. XPath 3.0.

XPath-Ausdruck

→ Expression

XPath-Pattern

→ Pattern

XPointer

Die XPointer-Spezifikation ist Teil des XLL-Standards, der den Aufbau von Adressen in XLink-Ausdrücken festlegt. XPointer beschreibt das Format eines → Fragment Identifiers. Dieser folgt innerhalb eines URL auf den Delimiter # und verweist auf eine Untergruppe (Fragment) eines XML-Dokuments.

XQuery

Die Sprache XQuery stellt eine Erweiterung von XPath dar, die Eigenschaften und Methoden ähnlich denen von SQL einbezieht, um eine Abfragesprache für XML zu definieren. Nach ursprünglich separaten Entwicklungen von XPath und XQuery sind beide Spezifikationen in XQuery 1.0/XPath 2.0 zusammengeführt worden, sodass XPath 2.0 im Grunde als Untergruppe von XQuery 1.0 betrachtet werden kann. Beide Sprachen teilen sich Operatoren, Funktionen und Datenmodelle. Die Nähe der Syntax von XQuery zu der von SQL ist beabsichtigt, um die Migration von SQL zu XQuery zu erleichtern.

XSL-FO

→ Formatting Objects

XSLT-Namensraum

Der XSLT-Namensraum ist ein vom W3C festgelegter → URI, der die XSLT-Elemente als Instruktionen kennzeichnet. Die Bindung des korrekten URI an die Elemente ist Vorausetzung für einen XSLT-Prozessor, seine Befehlssätze erkennen zu können. Da prinzipiell auch ein anderes Präfix als xsl: eingesetzt werden dürfte, wäre das Präfix allein nicht ausschlaggebend. Daher muss im → Wurzelelement des → Stylesheets xsl:stylesheet oder xsl:transform der entsprechende Namensraum vereinbart werden, und zwar mit exakt dem folgenden URI: xmlns:xsl="http://www.w3.org/1999/XSL/Transform". Ein anderes Präfix zu vereinbaren, wäre zwar legal, ist aber weder üblich noch sinnvoll, da es die Lesbarkeit des Stylesheets unnötig erschwert.

Microsoft verwendete in einer Übergangszeit (mit gleichem Präfix xsl) den Namensraum-URI "http://www.w3.org/TR/WD-xsl", was die Ausführung entsprechender Stylesheets mit anderen XSLT-Prozessoren unmöglich macht (daneben gibt es weitere Unterschiede, die eine Umarbeitung erforderlich machen würden). Inzwischen unterstützt Microsoft den allgemeinen Standard.

XSLT-Prozessor

Ein XSLT-Prozessor dient der Verarbeitung von XML-Dokumenten im Rahmen einer XSLT-Transformation. Es werden seit der XSLT 2.0-Spezifikation zwei Klassen von Prozessoren unterschieden: der Schema-Aware XSLT Processor und der Basic XSLT Processor.

Unter einem Basic XSLT Processor ist eine Anwendung zu verstehen, die die Spezifikation von XSLT 2.0 und XPath 2.0 in allen Punkten unterstützt, sofern diese vorgeschrieben (mandatory) sind, mit Ausnahme verschiedener, mit → XML Schema zusammengehörender Konzepte. Ein Basic XSLT Processor soll die Verarbeitung eines → Stylesheets verweigern, wenn dieses sich auf die Einbindung eines XML Schemas stützt. Namentlich gehört dazu: die Verwendung der Instruktion xsl:import-schema, ein type-, validation- oder default-validation-Attribut, das nicht den Wert "strip" trägt, oder die Referenz auf benutzerdefinierte Datentypen. Die vordefinierten Datentypen (built-in types) werden jedoch unterstützt.

Ein Schema-Aware XSLT Processor (wie beispielsweise Saxon-SA) unterstützt, ebenso wie der Basic XSLT Processor, die Spezifikationen von XSLT 2.0 und XPath 2.0 in allen vorgeschriebenen Punkten, darüber hinaus jedoch auch alle schemaspezifischen Konzepte, die beim Basic XSLT Processor einen Verarbeitungsabbruch bewirken. Ein Schema-Aware XSLT Processor muss demnach Schemas importieren können, gemäß eines Schemas validieren und benutzerdefinierte Datentypen unterstützen.

Über die als vorgeschriebenen (mandatory) geltenden Punkte der Spezifikationen hinaus steht es Anwendungen frei, weitere, dort als unverbindlich (optional) klassifizierte Vorschriften zu implementieren (Stylesheets, die sich auf solche Features stützen, sind daher nicht unbedingt beliebig portierbar).

nach oben

Z

Zeichenkette

→ String

Zeichenkodierung

→ Encodierung

Zeilenende (im Quelltext)

Beim Parsing von XML-Dokumenten wandeln → XML-Parser die Zeilenendmarkierungen intern generell in ein einfaches Linefeed (LF, #0A) um, wie es unter UNIX gebräuchlich ist. XSLT-Prozessoren können dies für die Ergebnisdateien beibehalten (wie z.B. Saxon). Mac OS verwendet den Wagenrücklauf (CR, #0D), Windows (und DOS) die NLF-Kombination aus Wagenrücklauf und Zeilenvorschub #0D #0A. Unter Windows kann dies zu Problemen mit der einfachen Lesbarkeit von Quelltexten (beispielsweise in Notepad) führen, was aber durch die geeignete Wahl des Editors gelöst werden kann.

Die im Mainframe-Bereich üblichen Zeilenendkodierungen #x85 (NEL, next line) und #x2028 (LS, line separator; Unicode General Punctuation Block) zählen in XML 1.0 zu den verbotenen Zeichen. Dem ist in XML 1.1 Genüge getan, das diese Zeichen erlaubt und den Whitespace-Zeichen (→ Whitespace) zuschlägt. Auch NEL und LS werden beim Parsing entfernt und durch LF ersetzt, sodass eine Folgeanwendung (z.B. ein → XSLT-Prozessor) nicht mit ihnen konfrontiert wird.

nach oben

   

<< zurück vor >>