useGroupEinführung in XML/XSLTAnhang C: Druckversion

copyright (c)2003-2005   useGroup

Anhang B: Kurzreferenz

Anhang C: Druckversion

66151@usegroup.de Einführung in XML/XSLT Anhang C: Druckversion Druckversion

Druckversion

useGroupEinführung in XML/XSLT

copyright (c)2003-2005   useGroup

Version dieses Dokumentes

V1.00 vom 10.7.2001

Was Sie lesen sollten

Wenn Sie zuerst einmal wissen wollen, ob XSLT das Richtige für Sie ist, oder schnellstmöglichst zuerst einmal eine XML-Datei "hochstellen" möchten, lesen Sie bitte den Quickstart. Wenn Sie

• DTDs programmieren möchten, brauchen Sie nur die Datei DTDs zu lesen,
• Schemata programmieren möchten, lesen Sie bitte die Datei Schema und die ersten 5 Abschnitte der Grundkenntnisse,
• wenn Sie XSLT lernen möchten sollten Sie mit dem Einstieg anfangen und mit den beiden folgenden Dateien weitermachen, aber unbedingt wissen, dass die Navigation in einem XML-Dokument genau behandelt wird, und die Grundkenntnisse möglichst auch gelesen haben

Lizenz

      Copyright (c) 2001 usegroup.
      Permission is granted to copy, distribute and/or modify this document
      under the terms of the GNU Free Documentation License, Version 1.1
      or any later version published by the Free Software Foundation;
      with the Invariant Sections being Vorwort, with no
      Front-Cover Texts, and with no Back-Cover Texts.
      A copy of the license is included in the section entitled 
      "GNU Free Documentation License".

Änderungen an diesem Dokument

Wenn Sie Änderungen an diesem Dokument vornehmen möchten, lesen Sie bitte model.html.

Links

Im Internet gibt es verschiedene gute XSLT-Seiten wie

• http://www.heise.de/ix/raven/Web/xml/ Die XML-Seite der iX
• http://www.heise.de/ix/raven/Web/xml/xslt.htm Die XSLT-Link-Seite der iX
• http://users.iclway.co.uk/mhkay/saxon/ Saxon, eine der XSLT-Implementationen
• http://zvon.org/xxl/XSLTutorial/Books/Book1/index.html XSLT-Tutorial von Zvon (NoFrames-Version:bookInOne.html)
• http://zvon.org/xxl/XSLTreference/Output/index.html XSLT-Referenz von Zvon
• http://www.nwalsh.com/docs/tutorials/xsl/xsl/ Sun-XSLT-Tutorial
• http://www.heise.de/ix/artikel/2001/01/167/ Das iX-XSLT-Tutorial
• http://www.zvon.org/xxl/DTDTutorial/General/book.html Das Zvon DTD-Tutorial
• http://zvon.org/xxl/xmlSchemaReference/Output/Schema/index.html Zvon Schema-Referenz
• http://www.w3schools.com/schema/schema_intro.asp Schema-Tutorial
• http://www.xfront.com/xml-schema.html Schema-Tutorial (zusammen 272(!) Powerpoint Slides)
• http://www.site-builder.co.uk/xhtml.htm Unterschiede zwichen HTML und XHTML
• http://www.selfxml.de/ SelfXML, XSLT-Programmierung für Internet Explorer
• http://www.usegroup.de/software/phptutorial/ Das "Schwester-Tutorial" dieses Dokuments mit dem Thema PHP.

Was ist XML?

XML (eXtensible Markup Language) ist eine Datenbeschreibungssprache. Das heißt, dass jede Art von Daten (z.B. ein Textverarbeitungs- oder Tabellenkalkulationsdokument, eine Homepage oder eingeschränkt Grafikdaten (bislang nur Vektordaten) in einem XML-Format beschreiben lassen). Sie denselben Vorgänger wie HTML, nämlich SGML (und sie ähnelt HTML: Tags sollten Ihnen bekannt vorkommen). Auch definiert XML einen Nachfolger für HTML, XHTML, der gewisse Vor-und Nachteile hat, doch dazu später.
Hier eine kurze Beschreibung von XML:

• XML ist an sich keine Dokumentenbeschreibungssprache, sondern eher eine Dateiformatbeschreibungssprache. Letztendlich könnte ich in einem XML-Dateiformat alle Aufgaben erfüllen, die ein beliebiges anderes Dateiformat schon heute erfüllt. Aus einer XMLisierung erfolgen gewisse Vor-und Nachteilen. XHTML ist die offizielle XML-Abbildung es HTML-Dateiformates, doch gibt es weitaus mehr XML-Markup Languages (d.i. Dateiformate) wie z.B. SVG, MathML (Mathematical Markup Language) und ChemML, (chemical Markup Language) und XSLT.
• XML definiert die Art und Weise, wie Tags geöffnet und geschlossen werden können, XML selbst definiert jedoch keine Tags. Bei der Arbeit mit XSLT werden wir selbsterfundene Tags benutzen (man könnte zwar direkt XHTMl-Tags benutzen um die eigene Homepage zu schreiben, jedoch bringen "selbsterfundene" Tags, die mit XSLT in XHTML umgewandelt werden, einen Vorteil: wenn ich einen Tag habe, der mir sagt, was ein Zitat oder eine Überschrift ist, kann ich für alle Zitate und Überschriften die Schriftart, Größe, Ausrichtung u.s.w. zentral festlegen).
• XML hat die Möglichkeit, die Korrektheit von Dokumenten mit sogenannten DTDs und Schemata testen zu können, jede SVG-Datei kann mit einem XML-Parser überprüft werden, ob sie syntaktisch und in begrenztem Maße auch semantisch korrekt ist.
• XML enthält viele Spezifikationen und Erweiterungen wie XPath und XPointer die aber für den Durchschnittsprogrammierer nur vom Konzept her interessant sind: Genaugenommen benutzt zwar jeder XSLT-Programmierer zwangsläufig XPath, weiß es aber nicht. Um ganz genau zu sein ist die gesamte Navigation in XML-Dateien die in den Grundkenntnissen beschrieben sind, XPath.
• XML-Datenformate sollen auch für Menschen verständlich sein: Auch Vektordaten aus SVG können dadurch z.B. durch einen Texteditor von Fehlern befreit werden.

Was ist XSLT?

XSLT (eXtensible Stylesheet Language Transformations) ist ein Werkzeug, von einem XML-Format ins andere zu konvertieren. XSLT kann z.B. benutzt werden um von einem Eigenformat in eine XHTML-Datei zu konvertieren. XSLT hat gegenüber CSS den Vorteil, dass es Transformieren kann, d.h. Elemente mehrmals und an verschiedenen Positionen verwenden kann (die Tags z.B. von hinten nach vorne zeigen kann). Richtig vorteilig wirds dann bei Verzeichnissen für Inhalt, Stichwörter und Bilder: XSLT kann sich die entsprechenden Informationen aus den Dateien nehmen und automatisch ein Inhaltsverzeichnis aufstellen (so geschehen in index.html).
Die Trennung von Struktur und Inhalt
HTML war von Anfang an dazu gedacht, zu definieren, welche Stellen im Dokument z.B. Überschriften sind und welche betont werden sollen. Der Browser entschied, wie die Dokumente darzustellen waren - und hat aber wirklich Jeden, der entfernt was von Design verstand ziemlich die Wände hochgehen lassen (die Seiten sahen selten auf zwei Browsern gleich aus). Sehr spät hat das W3C seinen Fehler eingesehen hat und den Benutzern mit CSS ein Werkzeug an die Hand gegeben hat um das Aussehen ihrer Seiten genauer und Browserunabhängig festlegen zu können.
Nichtsdestotrotz haben sich die Entwickler von großen Seiten ein Beispiel an dem tollen WYSIWYG (What You See Is What You Get, also dem gleich-aussehen des Ergebnisses mit der Anzeige in der Arbeitsumgebung) genommen, dass viele Seiten mehr oder weniger eingefroren sind. Ich habe zum Beispiel an einem Projekt konventionell mitarbeiten müssen, das aus je 200 Dateien in 7 Sprachen bestand. An sich ist das noch kein Problem, nur wenn Optik oder Inhalt geändert werden sollen (und sie sollten), sind oft redundante Arbeiten auszuführen (an denselben Tags in verschiedenen Dateien etwas ändern) oder die Änderungsstellen werden schwer gefunden.
Dagegen hilft eine weitere Schicht, die Strukturschicht. Ich definiere also selbst Tags die beschreiben, welche Information mit der Absatz liefert und später sage ich wie diese Information(en) dargestellt werden sollen.
Inhalt (z.B. Dies ist ein Artikel über XML).
Struktur (<Artikelanfang>Dies ist ein <Stichwort>Artikel über XML</Stichwort> <Artikelende>)
Darstellung: Stichwörter unterstreichen.
Ergebnis: Dies ist ein

Was ist XHTML?

HTML ist einne Untermenge des SGML-Dateiformat (Standard Generalized Markup Language). XML ist eine kleinere Untermenge der SGML-Möglichkeiten und XHTML ist ein XML-Dateiformat.

Vorteile:

• Die X(HT)ML-Eingabe kann durch DTDs und Schemata geprüft werden
• Der Standart ist klar definiert und kann durch Namespaces ausgeweitet werden: Eine Kontrolle des Standarts ist gegenüber HTML möglich und auch gegeben (keine nur-auf-Netscape-laufenden Erweiterungen mehr)
• Es ist in XSLT leichter und sinnvoller, eine XHTML-Datei als eine HTML-Datei zu definieren
• Die X(HT)ML-Eingabe kann durch XSLT in andere Formate portiert werden
• Es ist wesentlich einfacher, einen XHTML-Browser als einen HTML-Browser zu schreiben

• HTML-Editoren und Programmierer müssen umlernen
• Da HTML de facto weiter besteht werden die Browser aufgebläht
• Es ist bisher kaum verbreitet
• Es ist länger als HTML

Was sind DTDs?

DTD (Document Type Definitions) sind Dateien die beschreiben, welche Tags mit welchen Attributen an welchen Stellen eines bestimmten XML-Formats erlaubt sind. Da die Korrektheit der Tags ganz erheblichen Einfluss darauf hat, ob die Dateien überhaupt angezeigt werden können, gibt es für fast jedes XML-Format ein DTD oder Schema (mehr dazu gleich).
Auch sind sie eine wertvolle Hilfe beim Debugging und beim Schreiben (Emacs mit DTD-Unterstützung zeigt zum Beispiel alle Tags die im aktuellen Kontext verwendet werden dürften).
DTDs werden vom XML-Parser verarbeitet und können den Anwender z.B. mit Fehlermeldungen wie "Tag unknown in line 44" weiterhelfen.
DTDs haben einen Haken: Sie können keine Datentypen überprüfen. Das Tag Kundennummer kann letztendlich nur als Zeichenfolge (PCDATA) deklariert werden, sollten Kundennummern etwa mit Buchstaben oder Sonderzeichen vorkommen, muss jeder (bzw. jedes Programm das es anzeigen soll) selbst sehen, wie er zurecht kommt ;( Dieses Manko beheben XML Schemata die seit dem 24.10.2000 W3C-Empfehlung sind.

Was sind Schemata?

Schemata sind Dateien, die ähnlich wie DTDs die Gültigkeit eines Dokuments beschreiben. Anders als diese arbeiten Schemata jedoch nicht Dokumenten- sondern Datenorientiert, kennen also verschiedene Datentypen. Mit Schemata können Sie z.B. vorgeben, dass ein Attribut nur eine Postleitzahl und ein Element nur eine Artikelnummer beinhalten darf. Sie können dann die Datentypen Postleitzahl z.b. als fünfstellige Nummer definieren und Artikelnummer aus einer Folge dreier Buchstaben, einem Bindestrich und 4 bis 5 Zahlen.
Der Vorteil: Werden die XML-Daten maschinell ausgewertet können Fehler der Eingabe schon früh vermieden werden. Teilweise kann sogar ganz auf eigene Überprüfungsroutinen, z.B. ob das Element eine Zahl ist, verzichtet werden.

XSLT-Quickstart

Hier die Schritte wie Sie ein XSLT-Projekt ins Netz bekommen:

• Schreiben Sie Ihre XML-Datei in einem beliebigen Editor, Beispiel
• Schreiben Sie Ihre XSL-Datei in einem beliebigen Editor, Beispiel
• Konvertieren Sie die XML-Datei mit der XSL-Datei und einem XSLT-Prozessor wie Saxon in XHTML (bei Instant Saxon lautet der Aufruf z.B. saxon -a -o htmldatei.html xmldatei.xml)
• Stellen Sie die XHTML-Datei ins Netz, Ergebnis des Beispiels
• DTDs und Schemata zu verwenden machen dann Sinn, wenn z.B. eine Personengruppe an den XML-Dateien arbeitet: ein DTD oder ein Schema würde dann z.B. verhindern, dass die XML-Datei nicht mehr nach den Regeln der XSL-Datei interpretiert werden kann. Falls Sie ein DTD oder ein Schema haben wird Schritt 1 davon unterstützt, wenn Sie einen XML-Editor benutzen.

Was Sie erwartet

In dieser Datei werden XML-Begriffe geklärt und die Navigation in einem XML-Dokument aufgezeigt. Diese Navigation sollte Ihnen bei den XSLT-Kapiteln besonders hilfreich sein.

well-formed

Ein Document ist dann "well-formed", also als XML zu erkennen wenn es den XML-Gesetzen in der Weise gehorcht, dass

• Es keine ungültigen Zeichen beinhaltet
• Es keine Zeichen ausserhalb von Tags oder Attributen beeinhaltet
• Jedes Tag geschlossen oder in Kurzform geschlossen ist (kurzform: <tag/>)
• Es genau ein Top-Level-Tag besitzt
• Di Schachtelungen der Tags "sauber" ist, also jedes Tag geschlossen ist bevor sein Vatertag geschlossen wird (falsch: z.B. <topl>Dies ist ein <b>fetter <i>kursiver</b> Text</i></topl>)
• Alle Attribute in Hochkommas eingeschlossen sind
• Keine Attribute unmaskierte spitze Klammern besitzen (<>)
• Jeder Attributname in einem Tag nicht öfter als einmal vorkommt
• Es einen Header besitzt (z.B. <?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?> )

valid

Ein Dokument ist dann valid, also gültig, wenn es wellformed ist und dem DTD und/oder dem Schema gehorcht, der/das/die im Dateikopf angegeben wurde/n. (Ein Dokument kann sowohl einem DTD als auch einem Schema gehorchen müssen)

Import-Präzedenz

Sollte zwei gleichermaßen zutreffende Tags gefunden werden,

    <!-- für Tag b ist definiert -->
    <xsl:template match="b">
    Wird angewendet
    </xsl:template>
    <!-- und -->
    <xsl:template match="u|i|b">
    Wird in dem Fall für b nicht angewendet
    </xsl:template>
    
  

  <xsl:template match="bsp">
  <b>
    <xsl:apply-templates/>
  </b>
  </xsl:template>
  

Namespaces

Namensräume (Namespaces) sind die XML-Empfehlun wie man verschiedene XML-Formate in einem Dokument verwenden kann (man schreibt einfach den Namespace prefix, z.b. xsl mit einem Doppelpunkt vor das verwendete Kommando).
Der Eintrag in einer XSL-Datei

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

Navigation im XML-Dokument

Eine XML-Datei wird oft mit einem Baum verglichen, wobei jedes Tag einen weiteren Ast vom aktuellen Ast abspaltet abspaltet - der wiederung weitere Äste haben kann. Die Wurzel, also das höchste Tag und gleichzeitig der erste Ast ist /.
Die Elemente werden ähnlich wie Verzeichnisse auf einem Linux-Computer angesprochen (Unterschiede zu Windows-Verzeichnissen: es wird auf Groß/Kleinschreibung geachtet und man trennt nicht durch \ sondern durch /). Man kann alle Elemente absolut und lokal ansprechen. /datei/abschnitt/satz spricht z.B. nur die Berliner an:

<datei>
<satz inhalt="kein berliner">
Ich bin kein Berliner
</satz>

<abschnitt>
<satz inhalt="berliner">
Ich bin ein Berliner
</satz>
<satz>
Ich bin auch ein Berliner
</satz>
</abschnitt>
</datei>

//

//satz spricht jeden Satz, egal in welchem Tag an, also alle drei Sätze.

|

Der vertikale Strich bedeutet soviel wie ein "oder". Um im Beispiel zu bleiben bedeutet ein satz|abschnitt, dass sowohl Sätze, als auch Abschnitte mit diesem Template behandelt werden (passt zu Satz oder Abschnitt).

.

Der Punkt spricht das lokale Element an. Bsp:

<xsl:value-of select="."/>

@

Der Klammeraffe spricht die Attribute an, /datei/satz/@inhalt z.B. "kein Berliner". Beim lokalen Element reicht "@attributname", ein Punkt ist hier nicht nötig.

@*

Bedeutet: Selektiere sowohl alle Attribute als auch den Taginhalt. Praktisch ist das z.B. beim Kopieren von Elementen.

self::tagname

Entspricht dem Tagnamen des aktuell selektierten Elements.

<xsl:apply-templates select="*[not(self::s)]"/>

preceding-sibling::

Wählt das vorhergegangene gleichrangige (sibling=Geschwister)-Tag aus.

<xsl:apply-templates select="*[not(preceding-sibling::s)]"/>

following-sibling::

Wählt das nachkommende gleichrangige (sibling=Geschwister)-Tag aus.

<xsl:apply-templates select="*[not(following-sibling::s)]"/>

parent::

Wählt das Tag eine Ebene höher aus.

<xsl:apply-templates select="*[not(parent::s)]"/>

ancestor::

Wählt das Tag mindestens eine Ebene höher aus.

<xsl:apply-templates select="*[not(ancestor::s)]"/>

child::

Wählt das Tag eine Ebene tiefer aus.

<xsl:apply-templates select="*[not(child::s)]"/>

descendant::

Wählt das Tag mindestens eine Ebene tiefer aus.

<xsl:apply-templates select="*[not(descendant::s)]"/>

XHTML

Um von HTML auf XHTML umzusteigen, müssen Sie folgende Dinge beachten:

• Tags und Attributnamen müssen in Kleinbuchstaben geschrieben werden
• Die Datei muss sollte mit <?xml version="1.0" encoding="ISO-8859-1"?> beginnen und muss <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd"> beinhalten
• alle Tags müssen geschlossen sein, z.B. <br></br> (entspricht der Kurzform <br/>)
• alle Attributwerte müssen in Hochkomma eingeschlossen sein
• keine Attributminimierung mehr! Es gibt jetzt für jede Minimierung eine Alternative, aus <hr noshade> wird z.B. <hr noshade="noshade"/>
• auch in Javascript müssen nun die Elemente & und < maskiert werden als &amp; bzw. &lt;
• Keine Elementschachtelungen über das Vaterelement heraus! <b>fetter <i>fett-kursiver</b> kursiver</i> Text ist jetzt streng verboten, weil man sowas nie in einem Baum darstellen oder verarbeiten könnte. Benutzen Sie <b>fetter <i>fett-kursiver</i></b><i> kursiver</i>
• Folgende Tags können nun, dürfen aber nicht in folgenden anderen enthalten sein:

  a	darf kein weiteres a enthalten
  pre	darf kein img,object,big,small,sup,sub enthalten
  button	darf kein input, select, textarea, label, button, form, fieldset, iframe, isindex
  label	darf kein weiteres label enthalten
  form	darf kein weiteres form enthalten

• <p name=""> heißt jetzt <p id>

XHTML-Tags

Die folgenden Tags sind in XHTML 1.1 definiert:

Was ist DocBook?

Docbook ist ein SGML-Format, das für Veröffentlichungen bestimmt wurde. Es gibt jedoch ein XML-Format, DocBook/XML. Wie Sie aus dem Vorwort wissen sollten, ist XML eine Teilmenge von SGML, Docbook/XSL ist jedoch nicht notwendigerweise eine Teilmenge von Docbook (Sie können alles machen, was Sie mit Docbook/SGML auch können, nur machen Sie einige Dinge anders). Zur Verdeutlichung der Beziehung von SGML und XML hier ein Diagramm .

Warum der Name?

Der Name Docbook ist aus folgenden Gründen sinnvoll:

• Es handelt sich um ein Format, das auch gut dafür verwendet werden kann, technische Dokumentationen zu erstellen
• Durch die Untersttzung von DTP-Programme wie Framemaker kann man Docbooks tatsächlich relativ einfach als Buch veröffentlichen lassen

• Man kann Docbook nicht nur verwenden, um ganze Bcher zu definieren, sondern auch für kleine Artikel (Die Linux-howtos werden z.B. aus Docbook generiert).
• Auch sind die entstandenen Dateien vielseitig verwendbar nicht nur, um Bücher zu drucken, sondern auch, um zum Beispiel XHTMLs oder PDFs zu erstellen.

Was ist XML:FO

XML:Formatting Objects ist ein vom W3C abgesegnetes XML-Dateiformat, das für Print-Medien optimiert wurde. Anders als in den meisten anderen XML-Formaten, deren Tags sagen, was ein Element ist, und nicht wie es dargestellt werden soll, befassen sich die Tags von XML:FO ausschlie�ich damit, wie die Elemente auf Print-Medien darzustellen sind. XML:FO-Prozessoren wie der Apache FOP generieren daraus dann Druckvorstufen, der Apache FOP beherrscht z.B. auch PDF. Wir werden die XSLT-Transformationen von Docbook auf XML:FO benutzen, um ein PDF zu erstellen, und die von Docbook auf XHTML um eine XHTML-Seite zu erstellen.

Ein Testsystem

Um anständig mit Docbook/XML arbeiten zu können empfehle ich Ihnen folgende Dateien:

• Die Docbook-XSL-Stylesheets (unter der Überschrift Docbook-XSL) um die geschriebenen Dateien in XHTML oder PDFs umwandeln zu können
• Einen anständigen XML-Editor wie XML-Spy weil Docbook etwas komplex ist und man jede Hilfe beim Erstellen gebrauchen kann
• Die Docbook DTDs als Zip-Archiv, hier beispielsweise die der Version 4.2 Release Candidate 1.
• Einen XSLT-Prozessor, hier beispielweise Instant Saxon von Michael Kay
• Einen FOP-Prozessor, hier beispielweise den Apache FOP

Ein Beispiel-Buch

Wählen Sie in Ihrem XML-Editor "neues Dokument" basierend auf der Docbook DTD (je nachdem wohin Sie sie entpackt haben). In XML-Spy bevorzuge ich die Textansicht .

<?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE set SYSTEM ".\dtds\docbookx.dtd">
  <set>
    <book>
    <chapter>
      <title>Mein erstes Kapitel</title>
      <para>Hier ist ein Absatz</para>
      <sect1>
        <title>Ein Abschnitt im Kapitel</title>
        <para>Mindestens ein Absatz im Aschnitt macht ihn DTD-Gerecht.</para>
      </sect1>
      </chapter>
    </book>
  </set>

Bilder in Docbook

Eine Möglichkeit, Bilder einzubetten, besteht in der Kombination aus inlinemediaobject, imageobject und imagedata. Wie der Name schon sagt, wird das Bild dann inline, also ohne Umlauf oder Ausrichtung eingebaut.

  <inlinemediaobject>
    <imageobject>
      <imagedata fileref="dateiname.jpg" format="JPG"/>
    </imageobject>
  </inlinemediaobject>

Zeilenumbruch (Breaks) erzwingen

Normalerweise wird man Zeilenumbrüche in Docbook durch Absätze (<para>...</para>) herbeiführen. Diese werden in HTML jedoch sinnhafterweise mit <p>...</p> übersetzt, einen einfachen Zeilenumbruch, sprich etwas, was die Ausgabe eines <br/> in der HTML-Ausgabe erzeugt, ist nur durch die Verwendung von Literallayout möglich. Um Literallayout anwenden zu können, müssen zunächst alle Absätze beendet werden. Das Literallayout ist dabei in etwa vergleichbar mit dem HTML-Preformatted-Tag <pre>...</pre>: Ein Zeilenumbruch in der Quelldatei führt zur Erzeugung eines Zeilenumbruchs in der Ausgabe.

  <para>
    Ein Absatz ohne Zeilenumbruch
  </para>
  <literallayout>
    Ein Absatz mit Zeilen-
    umbruch
  </literallayout>
  <para>
    Ein weiterer Absatz ohne Zeilenumbruch
  </para>

Links

Links werden in DocBook mit ulink realisiert.

  <ulink url=”http://www.google.de”> Linktext </ulink>

Kursiver Text

Text können Sie kursiv darstellen, wenn Sie das emphasis-Tag mit der kursiven "role" verwenden.

  <emphasis role="italic">italic emphasized</emphasis>

Fußnoten

Verwenden Sie footnote im Text um an der entsprechenden Stelle eine Fußnote einzufügen. Darin sollten Sie Text als Absatz (para) formatieren.

<footnote id="fnid1"><para>A footnote</para></footnote>

Metadaten über Artikel

Als per <set>-<book> als ganzes Buch auszuzeichnen können Sie auch den leichtgewichtigeren article verwenden: Artikel können (oder sollten) mit Metadaten ausgezeichnet werden, vom Titel über Datum und Autor bis hin zu Stichwörtern, die in einer subjectset-subject-subjectterm-Konstellation angegeben werden können.

	
<article>
<articleinfo>
  <title>XYY</title>
  <corpauthor>usegroup</corpauthor>
  <date>2005-04-04</date>
  <subjectset>
    <subject>
      <subjectterm>
        Others
      </subjectterm>
    </subject>
  </subjectset>
</articleinfo>

<para>
Ein Abschnitt
</para>
</article>

Export als XHTML

Wenn Sie diese Datei möhten z.B. als XHTML ins Netz stellen möchten, müssen Sie zuerst einmal einfgen, dass das entsprechende XSL-Stylesheet verwendet werden soll.
Mit dem Befehl

saxon -o index.html docbook.xml html/docbook.xsl

Export als PDF

PDFs bekommen Sie aus einem Docbook, indem Sie zuerst eine Ausgabe in XML:FO erstellen:

saxon -o index.fo docbook.xml fo\docbook.xsl

fop index.fo index.pdf

[Error]: The id "toc...d47e3" already exists in this document

Kommentare

Kommentare werden in XSLT geschrieben als

<!-- Kommentar -->

<xsl:comment>< Kommentar, der übernommen wird ></xsl:comment>

xsl:text

Der gesamte Text in der XSL-Datei, der ausgegeben werden soll, müsste streng genommen in xsl:text - Tags stehen. Genaugenommen wird er aber auch ausgegeben, wenn er nicht in diesen Tags steht.

xsl:template

*name

Ein Template (zu deutsch: Vorlage) ist das zentrale Element in XSLT: dort werden alle Tagumwandlungen und Positionierungen vorgenommen. Beispiel: samples/xslt1.xml und samples/xslt1.xsl.

--- datei xslt1.xml
<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?> 
<?xml-stylesheet href="xslt1.xsl" type="text/xsl"?> 
<hello-world>
Hallo Welt!
</hello-world>
--- datei xslt1.xsl
<?xml version="1.0" encoding="ISO-8859-1"?>

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

<xsl:output method="html"/>

<xsl:template match="/">
<html>
  <body>
   <xsl:apply-templates/>
  </body>
</html>

</xsl:template>


</xsl:stylesheet>

Apply-Templates ohne passende Templates

So wird auch bei folgendem Beispiel (sample/xslt2.xml) das "undefinierte" Tag b nicht übergeben, der Text nicht fett dargestellt, weil XSLT nicht wissen kann, dass b als Tag so erhalten bleiben soll.

Hallo <b>Welt</b>!

Ein anderes Tag matchen

Mit einem zweiten xsl:template-Tag können wir auch beliebige andere Tags bearbeiten - z.B. können wir ein b-Tag kapseln (samples/xslt3.xml und samples/xslt3.xsl)

<xsl:template match="/">
<html>
  <body>
   <xsl:apply-templates/>
  </body>
</html>
</xsl:template>

<xsl:template match="b">
  Fett:<b>
   <xsl:apply-templates/>
  </b> und wieder normal:
</xsl:template>

xsl:value-of

select

Neben der schon erwähnten Methode

xsl:apply-updates

xsl:value-of select="..."

<xsl:value-of select="."/>

<body> Hallo <b> Welt </b>  </body>

xsl:value-of

select

Attribute werden in XSLT grundsätzlich mit tagname/@attributname angesprochen, z.B. img/@src für das src-Attribut eines img-Tags. Mit

<xsl:template match="img">
Bild: <xsl:value-of select="@src"/>
</xsl:template>

Kurzform einer Ausgabe

Erfolgt die Ausgabe innerhalb von Attributen kann man anstelle eines value-ofs eine geschweifte Klammer verwenden. Siehe xslt4.xsl und xslt4.xml.

<xsl:template match="img">
  <img src="{@src}" alt="{@alt}"/>
</xsl:template>

Bedingungen

Mit xsl:if können Sie überprfen, ob Variablen, Funktionen, Tags oder Attribute einen bestimmten Wert haben.
Siehe auch when
Ein definiertes Tag oder Attribut hat z.B. immer den Wert true, so gibt

<xsl:if test="@name">
Name des Bildes: <xsl:value-of select="@name"/>
</xsl:if>

<xsl:if test="position()!=last()">
<a href="#top"><img src="nachunten.gif"/></a>
</xsl:if>

das fehlende xsl:else

Es gibt in XSLT ein else, nur heißt es xsl:otherwise und funktioniert nur in xsl:choose-tags.

case

xsl:choose ist in etwa mit einem case einer normalen Programmiersprache vergleichbar. Alle when-und otherwise Tags müssen in einem xsl:choose Tag gekapselt sein.

<xsl:choose>
<xsl:when test="state='AZ'">Arizona</xsl:when>
<xsl:when test="state='CA'">Kalifornien</xsl:when>
<xsl:when test="state='DC'">Washington DC</xsl:when>

<xsl:otherwise><xsl:value-of select="state"/></xsl:otherwise>
</xsl:when>

</xsl:choose>

xsl:when

Änlich if, darf aber nur in einem choose-Tag vorkommen und ein otherwise (entspricht else) ist möglich. Beispiel siehe xsl:choose

xsl:otherwise

Entspricht in etwa else einer Programmiersprache oder einer Default-Einstellung.

xsl:for-each

select

xsl:for-each ist ein sehr praktisches Tag, weil es erlaubt, alle Tags eines bestimmten Types im aktiven Template auszugeben und zu bearbeiten. Daher ist es z.B. fr Inhaltsverzeichnisse und Stichwortlisten pr�estiniert.

	<xsl:for-each select="//cue">
		<a href="{.}"/><xsl:value-of select="@name"/></a>
 	</xsl:for-each>

	<xsl:for-each select="//cue">
		<a href="{//cue}"/><xsl:value-of select="//cue/@name"/></a>
 	</xsl:for-each>

Sortieren

select, *order, *case-order, *lang, *data-type

xsl:sort ist als Kindelement zu for-each und apply-templates zugelassen. Es sortiert die Ausgabe nach dem in select angegebenem Attribut

	<xsl:for-each select="document(@fname)//cue">
  		<xsl:sort select="@name"/>
  		<xsl:value-of select="@name"/>-<xsl:apply-templates/><br/>
  	</xsl:for-each>

  <xsl:for-each select="//person">
    <xsl:sort select="@alter"/>
    <xsl:sort select="@name"/>
    <xsl:value-of select="@alter"/>, <xsl:value-of select="@name"/><br/>
  </xsl:for-each>

das fehlende xsl:while

Da es in XSLT nicht m�lich ist, Variablen zu modifizieren, gibt es auch kein while, weil sich keine Bedingung jemals ändern könnte. Es ist allerdings möglich, templates rekursiv so aufzurufen, dass sich de facto ein while realisieren lässt.

xsl:variable

name *select

Die Auswertung von select oder der Inhalt wird in der Variable gespeichert. Variablen werden mit $ angesprochen.

<xsl:variable name="lastnode" select="last()"/>
<xsl:if test="position()=$lastnode">
Last node for the turn...
</xsl:if>

<xsl:variable name="decision">
<xsl:if test="position()=1">
First node for the turn...
</xsl:if>
<xsl:if test="position()=last()">
Last node for the turn...
</xsl:if>
</xsl:variable>

Geltungsbereich:

<xsl:if test="position()=1">
<xsl:variable name="decision" select="First node for the turn..."/>
</xsl:if>
<xsl:if test="position()=last()">
<xsl:variable name="decision" select="Last node for the turn..."/>
</xsl:if>

position()

position() gibt die Nummer des aktuell in Bearbeitung befindlichen Templates zurück. Achtung: Diese Nummerierung unterscheidet nicht die Art des Tags, nach einem apply-templates select="*" auf

<hallo>
welt und 
<eintag/>
<eintag/>
</hallo>

   <xsl:template match="//hallo"> 
	<xsl:apply-templates select="*[not(self::eintag)]"/> <!-- not(self::eintag) bedeutet: zuerst einmal alle Tags bearbeiten, die NICHT eintag-tags sind. -->
	<xsl:apply-templates select="eintag"/>  
   </xsl:template> 

   <xsl:template match="eintag"> 
        Position: <xsl:value-of select="position()"/><br/>
	<xsl:value-of select="."/>
   </xsl:template> 

last()

last() gibt die Anzahl der Templates zurück, die anzuwenden sind. Es eignet sich somit hervorragend um in einem xsl:if zusammen mit einem position() zu überprüfen, ob gerade das letzte (vorletzte etc.) Tag einer bestimmten Gattung bearbeitet wird.

<xsl:if test="position()=last()">
Letztes Tag dieser Template-Reihe
</xsl:if>

xsl:number

*count *level *format

<xsl:number count="item"> nummeriert die entsprechenden Tags (bei diesem Aufruf: Nummerierung startet bei 1 und zählt jeweils nur die Tags der entsprechenen Verschachtelung - Ergebnisse wie 1,2,1,2,3,4,3,5 sind vorprogrammiert). Das Attribut level="any" anstelle match="item" nummeriert durchgehend durch alle Ebenen - aber auch das ist nicht das was ich unter einer Gliederung verstehe. Diese leistet erst level="multiple" count="item".
Das (optionale) Format-Parameter kann noch viel mehr: format="1.1.1.1" nummeriert nach arabischen Zahlen (Standart)
format="i.1.I.1" nummeriert nach kleinen römischen, dann arabischen, dann großen römischen und dann wieder arabischen Zahlen (bspw:ii.2.IX.9)
Sollten Sie nicht genug Format-Anweisungen gegeben haben (z.B.: i bei einer Schachtelungstiefe von 2) werden die nichtangegebenen Ziffern arabisch (z.B. iii.3.1).
Weitere Beispiele:

document

string

Mit document('dateiname.xml') kann man in XPath Tags aus anderen Dateien matchen (für Inhaltsverzeichnisse und Stichwortlisten meist unerlässlich). Das geht überraschend einfach z.B. mit

   <xsl:for-each select="document('xslt6.xml')//hello-world">
   	<xsl:value-of select="."/>
   </xsl:for-each>

  <xsl:for-each select="document('xslt6.xml')//file">
        <xsl:variable name="filename" select="concat(substring-before(@name, '.xml'), '.html')"/> 
        
	<xsl:for-each select="document(@name)">
	
		<a href="{$filename}"/>
  		<xsl:value-of select="//article/@name"/>
  		<br/>  		

  		
  		<xsl:value-of select="//article/@name"/>
  		<br/>  		</xsl:element>

  	</xsl:for-each>
   </xsl:for-each>

xsl:copy

Der Container für xsl:copy-of.

<xsl:template match="a|abbr|acronym|address|b|big|blockquote|br|cite|dfn|div|em|h1|h2|h3|h4|h5|h6|hr|i|kbd|p|pre|q|quote|samp|span|small|strong|sub|sup|tt|var|button|fieldset|form|input|label|legend|option|optgroup|select|caption|col|colgroup|table|tbody|td|tfoot|th|thead|tr|dl|dd|dt|ol|ul|li|img" xmlns:html="http://www.w3.org/1999/XSL/some">
<xsl:copy>
	<xsl:copy-of select="@*"/><!-- alle Attribute und Tags kopieren -->
	<xsl:apply-templates/>
</xsl:copy>
</xsl:template>

xsl:copy-of

select

Kopiert Tags. Im Beispiel werden z.B. einige HTML-Tags bei Vorkommen ungeändert und mit allen Attributen in die Ausgabe kopiert.

xsl:import

xsl:import importiert ein Style-Sheet. Wichtig ist nur zu beachten, dass es ein top-level-Element ist, also als Kind zu xsl:stylesheet "sehr weit oben" in der Datei stehen muss. xsl:import importiert mit einer niedrigeren Import-Präzedenz als xsl:include, d.h. dass in der lokalen Datei matchende templates den importierten auf jeden Fall vorgezogen werden (anders bei xsl:include).

<xsl:import href="common.xsl"/>

xsl:include

xsl:import importiert ein Style-Sheet als wäre es an dieser Stelle im Quelltext definiert. Es ist wie xsl:import ein top-level-Element.

<xsl:include href="common.xsl"/>

substring-before()

value, substring

Liefert den Stringteil von value zurück, der VOR Substring steht.

substring-after()

value, substring

Liefert den Stringteil von value zurück, der NACH Substring steht.

concat()

str1, str2

Liefert einen aus str1 und str2 zusammengesetzten String zurück.

xsl:call-template

name

Ruft das Template name auf (man beachte die Ähnlichkeit zu einem Funktionsaufruf).

<xsl:template name="mytemplate">
<xsl:apply-templates/>
</xsl:template>

<xsl:template match="/">
<xsl:call-template name="mytemplate"/>
</xsl:template>

Eine dateiübergreifende Referenz sortieren

Eine Referenz zu erstellen, ist in XSLT einfach mit einem for-each-Tag möglich; aus verschiedenen Dateien liest man mit document. Normalerweise erstellt man eine XML-Datei in der man alle XML-Dateien erwähnt, die am aktuellen Projekt beteiligt sind:

<project>
<file id="datei1" name="datei1.xml"/>
<file id="datei2" name="datei2.xml"/>
</project>

  <xsl:variable name="nodetree">
  <xsl:for-each select="document('project.xml')//file"> 

	<file xmlns="" name="{@name}"> 
	<-- hier wird in der neuen Baumvariable ein Element angelegt das den Dateinamen enthält, in welchem die refs gerade stehen-->
			<xsl:copy-of select="document(@name)//ref"/> 
			<-- hier werden die Ref-tags als Unterelement zum Dateinamen in den Baum kopiert -->
	</file>
   </xsl:for-each>
  </xsl:variable>

  <h2>Nach Stichwort</h2>  	<-- Nach Stichwort sortieren -->

   
  <xsl:for-each select="$nodetree//ref"> <-- alle Refs wieder aus dem Baum raus-->
    <xsl:sort select="@name"/> <-- nach Attribut name sortieren-->
    <a href="{../@name}"><xsl:value-of select="@name"/></a><br/> 
    <-- Und zusammen mit Link auf das Name-Attribut des übergeordneten Elements (File) ausgeben-->
  </xsl:for-each>


  <h2>Nach Datei</h2>  <-- Nach Datei sortieren -->
  <xsl:for-each select="$nodetree//file"> 
  <xsl:sort select="@name"/>
	<xsl:for-each select="//ref"> 
	  <xsl:sort select="@name"/> <-- Jeden Dateiinhalt nach Stichwort sortieren -->
	    <a href="{../@name}#{../@a}"><xsl:value-of select="@name"/></a><br/><-- ... und ausgeben -->
    	</xsl:for-each>
  </xsl:for-each>

What's missing

Es trifft nicht ganz zu, diesen Artikel "für Profis" genannt zu haben; Das XSLT ein bisschen mehr ist, als hier erwähnt wurde, "wäre ungefähr wie zu sagen, die Haut eines Ertrinkenden sei feucht. Es ist richtig aber es trifft nicht den Kern der Sache" (Scott Adams). XSLT ist ein weitaus mächtigeres Werkzeug als ich bei meinen ersten Style-Sheets gedacht habe - hoffentlich können Sie mit diesen Dateien schonmal anfangen, Ihre ersten Style-Sheets zu schreiben und vielleicht springt der Funke über...

Grundlegender Aufbau

DTDs sind in SGML definiert, aber nicht in XML. Überwiegend werden <!-Tags verwendet, Elemente mit !ELEMENT, Attribute mit !ATTLIST elementname (in einer XML- Umgebung wäre es logischer, die Attribute als Tags in den Element-Tag zu schreiben) und Entities mit !ENTITY definiert.

Einbindung

DTDs werden in die XML-Datei eingebuden mit

<!DOCTYPE ROOTELEMENT SYSTEM "DTDDATEINAME.dtd">

PCDATA

Tags können als Inhalt entweder weitere Tags und/oder Buchstaben haben (z.B. <p> hallo Welt </p>). Diese Buchstaben werden in DTDs entweder als CDATA (character data, für Attribute) oder als
PCDATA (parsed character data) definiert.

Elemente

Tags (entsprechen Elementen) werden mit dem Schlüsselwort <!ELEMENT tagname> definiert.

---myfirst.dtd
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- Schaden tut der XML-Header nicht-->
<!ELEMENT hello-world (#PCDATA)>
---myfirst.xml
<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?> 
<?xml-stylesheet href="myfirst.xsl" type="text/xsl"?> 
<!DOCTYPE hello-world SYSTEM "myfirst.dtd">
<hello-world>
Hallo Welt!
</hello-world>

leere Tags und volle Tags

Das Schlüsselwort EMPTY definiert Tags, die keinen Inhalt haben dürfen (wie etwa das br/-Tag in HTML)

<?xml version="1.0" encoding="ISO-8859-1"?>
<!ELEMENT hello-world EMPTY>

Tags erlauben

Innerhalb der Klammern nach dem Tagnamen können Sie allerdings auch eine Liste mit Tags angeben, die vorkommen sollen oder müssen. Das Beispiel verlangt im Tag hello-world nach genau einem Vorkommen des Tags name, das Text enthalten kann.

<?xml version="1.0" encoding="ISO-8859-1"?>
<!ELEMENT hello-world (name)>
<!ELEMENT name (#PCDATA)>

<?xml version="1.0" encoding="ISO-8859-1"?>
<!ELEMENT hello-world (name, alter)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT alter (#PCDATA)>

<p>Dies ist <u>ein</u> 
<i>Text mit <u>Unterstrich</u></i></p> 

<!ELEMENT p (#PCDATA | i | u)*>
<!ELEMENT i (#PCDATA | u)*>
<!ELEMENT u (#PCDATA | i)*>

Attribute

Attribute werden mit !ATTLIST definiert - so

<!ATTLIST p
name	CDATA	#REQUIRED
beschreibung	CDATA	#IMPLIED
autor	CDATA	"ich"
groesse	(klein|mittel|gross)	#IMPLIED
intoc (ja|nein)	"ja"
>

Entities

Zwei Beispiele:

<!ENTITY myente "quaak">
<!ENTITY auml "ä">

<!ENTITY auml "&auml;">

Was weggelassen wurde

Nicht erwähnt habe ich Parameter Entity References (Entities die in der DTD genutzt werden können und damit eine gewisse Modularisierung erlauben - oft benutzte Zeichenketten kann man als Parameter Entity zentralisieren), bedingte Abschnitte in der DTD und Notationen. Mit Parameter Entity References kann man auch andere DTDs in den eigenen DTD importiert.

Warum Schemata

Anders als DTDs werden Schemata in einem XML-Format definiert. Das ist an und für sich schonmal ein Vorteil, dazu kommt aber dass das u.A. so ist weil Schemata erst 2001 vom W3C verabschiedet worden sind und es deshalb erheblich mehr Werkzeuge gibt die auf Konformität mit einem DTD prüfen und Schemata noch nicht interpretieren. Ich persönlich nutze Schemata nur dort, wo ich deren Vorteil brauche und der ist: Daten und nicht Dokumentorientiert zu arbeiten.
Es gibt in Schemata verschiedene Datentypen, in DTDs gibt es diese nicht. Ich kann also sagen ein Tag darf nur ein Datum enthalten, bei DTDs muss ich damit leben dass die XML-Autoren in ein Feld namens Datum 1999, 1.10.1999, erster Oktober 1999 oder Mickey Mouse hat einen Bruder reinschreibt. Werden die XMLs automatisch verarbeitet, z.B. in eine Datenbank eingetragen wird das entsprechende Programm spätestens beim Mickey-Mouse-Satz seine helle Freude haben.

Einbindung

Schemata werden in die XML-Datei eingebunden mit

<ROOTELEMENT xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance" xsi:noNamespaceSchemaLocation="SCHEMADATEINAME.xsd">

...

</ROOTELEMENT>

Tags

Tags werden mit dem xsd:element-Tag beschrieben. Ein sehr einfaches Schema wäre z.B.

<?xml version="1.0" encoding="ISO-8859-1"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema" elementFormDefault="qualified">
	<xsd:element name="p" type="xsd:string"/>
</xsd:schema>

Untertags

mit

	<xsd:complexType name="wasbeliebt">
		<xsd:sequence>
			<xsd:element name="b" type="xsd:string"/>
			<xsd:element name="i" type="xsd:string"/>
  			<xsd:element name="u" type="xsd:string"/>
  		</xsd:sequence>
	</xsd:complexType>

	<xsd:element name="p" type="wasbeliebt"/>

Inline Schemata

Man kann die complexTypes übrigens auch gleich ins Element einbetten:

	<xsd:element name="p">
	<xsd:complexType name="wasbeliebt">
			<xsd:element name="i" type="xsd:string"/>
	</xsd:complexType>
	</xsd:element>

Tags zur Auswahl stellen

Wenn Sie den DTD-Teil dieses Tutorials schon gelesen haben, wissen Sie aber, dass das nicht Sinn der Sache war. Es sollen beliebig viele und geschachtelte i us und bs möglich sein. Ein xsd:choice sieht zwar wie eine Lösung aus, ist aber keine

	<xsd:complexType name="wasbeliebt">
		<xsd:choice>
			<xsd:element name="b" type="xsd:string"/>
			<xsd:element name="i" type="xsd:string"/>
  			<xsd:element name="u" type="xsd:string"/>
  		</xsd:choice>
	</xsd:complexType>

minOccurs

minOccurs und maxOccurs liegen in engem Wettstreit mit type um meine persönlichen XML-Lieblingsattribute. Während Type eine beinahe schon an PHP erinnernde intuitive (weil logische) Programmierung erlaubt sind minOccurs und maxOccurs in vielen Tags erlaubt und -- bedeuten immer das Gleiche (keine Ausnahmen, kein fehlersuchen, kein Referenzenwühlen).
minOccurs="n" bedeutet: Das in dem Tag spezifizierte Element muss mindestens n-mal vorkommen.

maxOccurs

maxOccurs="n" verhält sich analog: Das in dem Tag spezifizierte Element darf höchstens n-mal vorkommen. Wobei jede Zahl für eine Zahl steht und "unbounded" für unendlich. Mit diesen beiden Elementen lässt sich dann auch unser ibu (italic/bold/underline)-Beispiel weiter bringen: durch ein ergänzen einer Zeile erhält man nämlich

		<xsd:choice minOccurs="0" maxOccurs="unbounded">

	<xsd:element name="b" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
	<xsd:element name="i" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
	<xsd:element name="u" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>

	<xsd:element name="p" type="wasbeliebt"/>
	<xsd:complexType name="wasbeliebt">
		<xsd:choice minOccurs="0" maxOccurs="unbounded">
			<xsd:element name="b" type="xsd:string"/>
			<xsd:element name="i" type="xsd:string"/>
			<xsd:element name="u" type="xsd:string"/>
		</xsd:choice>
	</xsd:complexType>

Tags in beliebiger Reihenfolge erlauben

Leichter als in DTDs kann man in Schemata Tags erlauben und von der Reihenfolge absehen: wie xsd:sequence und xsd:choice wird xsd:all definiert.

	<xsd:element name="p" type="wasbeliebt"/>
	<xsd:complexType name="wasbeliebt">
		<xsd:all>
			<xsd:element name="b" type="xsd:string"/>
			<xsd:element name="i" type="xsd:string"/>
			<xsd:element name="u" type="xsd:string"/>
		</xsd:all>
	</xsd:complexType>

Attribute

Attribute werden in einem complexType mit xsd:attribute definiert (und dürfen im complexType immer erst NACH choices oder sequences definiert werden).

	<xsd:element name="p" type="wasbeliebt"/>
	<xsd:complexType name="wasbeliebt">
		<xsd:attribute name="ibu" type="xsd:string"/>
	</xsd:complexType>

	<xsd:element name="p" type="wasbeliebt"/>
	<xsd:complexType name="wasbeliebt">
		<xsd:choice minOccurs="0" maxOccurs="unbounded">
			<xsd:element name="b" type="xsd:string"/>
			<xsd:element name="i" type="xsd:string"/>
			<xsd:element name="u" type="xsd:string"/>
		</xsd:choice>
		<xsd:attribute name="ibu" type="xsd:string"/>
	</xsd:complexType>

Attributaufzählungen

Sie können wie in DTDs die Auswahlmöglichkeiten bei einem Attribut gezwungenermaßen einschränken -- und zwar durch verwenden eines simpleTypes mit einer restriction:

		<xsd:attribute name="bio" use="required">
            	<xsd:simpleType>
                	<xsd:restriction base="xsd:string">
                    		<xsd:enumeration value="clear"/>
                    		<xsd:enumeration value="investigating"/>
                    		<xsd:enumeration value="suspicious"/>
                	</xsd:restriction>
            	</xsd:simpleType>
	        </xsd:attribute> 

Wertebereich einschränken

angenommen wir möchten zu p noch ein Attribut, Note. Diese Note soll eine ganze Zahl im Bereich von 1-6 sein (in der Schweiz von 6-1 ;)). Wir machen auch das mit einer restriction, geben aber ein minInclusive und ein maxInclusive vor.

<xsd:simpleType name="notentyp">
    <xsd:restriction base="xsd:integer">
        <xsd:minInclusive value="1"/>
        <xsd:maxInclusive value="6"/>
    </xsd:restriction>
</xsd:simpleType>

Datentypen

Von Hause aus bieten Schemas die folgenden Datentypen:

Eigene Datentypen definieren

Mit

	<xsd:element name="plz" type="plz"/>	
	...
	<xsd:simpleType name="plz">
    		<xsd:restriction base="xsd:integer">
        <xsd:length value="5"/>

    <xsd:restriction base="xsd:integer">
      <xsd:pattern value="\d{5}\/d{5}"/>
    </xsd:restriction>

Entities

"Since XML Schema begins work on the infoset of a well-formed (perhaps valid) XML document, parsed entity definition substitution has already taken place. We decided a two-pass architecture was too clunky, and arguably impossible, and concluded the best thing was to leave XML 1.0 entities to XML 1.0 mechanisms (i.e. you can define entities in the internal subset) ", Henry S. Thompson.
Auf Deutsch: Da Schemata nur auf XML-Dateien anzuwenden sind, die schon well-formed sind, muss jeder sehen wo er bleibt.
Zum Beispiel hier:

<!DOCTYPE ROOTELEMENT [
<!ENTITY eacute "é">
]>

We can achieve a similar but not identical outcome by declaring an element in a schema, and by setting the element's content appropriately: 

<xsd:element name="eacute" type="xsd:token" fixed="é"/>

And this element can be used in an instance document: 

Using an element instead of an entity in an instance document. 
<?xml version="1.0" ?>
<purchaseOrder xmlns="http://www.example.com/PO1"
               xmlns:c="http://www.example.com/characterElements"
               orderDate="1999-10-20>
 <!-- etc. --> 
  <city>Montr<c:eacute/>al</city>
 <!-- etc. -->
</purchaseOrder>

Unicode

Für eigene XML-Formate, die dann noch per XMLT umgewandelt werden, kann es wichtig sein, Umlaute einzubinden. In XHTML stehen zwar Entities wie &auml; zur Verfügung, Unicode funktioniert allerdings unabhängig davon immer auch in eigenen Formaten.

Hier einige wichtige deutsche Unicodes:

Lizenz

GNU Free Documentation License

Copyright (C) 2000  Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.

0. PREAMBLE

0. PREAMBLE

1. APPLICABILITY AND DEFINITIONS

1. APPLICABILITY AND DEFINITIONS

2. VERBATIM COPYING

2. VERBATIM COPYING

3. COPYING IN QUANTITY

3. COPYING IN QUANTITY

4. MODIFICATIONS

4. MODIFICATIONS

• A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.
• B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has less than five).
• C. State on the Title page the name of the publisher of the Modified Version, as the publisher.
• D. preserve all the copyright notices of the Document.
• E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.
• F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.
• G. preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice.
• H. Include an unaltered copy of this License.
• I. preserve the section entitled "History", and its title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.
• J. preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.
• K. In any section entitled "Acknowledgements" or "Dedications", preserve the section's title, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.
• L. preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.
• M. Delete any section entitled "Endorsements". Such a section may not be included in the Modified Version.
• N. Do not retitle any existing section as "Endorsements" or to conflict in title with any Invariant Section.

5. COMBINING DOCUMENTS

5. COMBINING DOCUMENTS

6. COLLECTIONS OF DOCUMENTS

6. COLLECTIONS OF DOCUMENTS

7. AGGREGATION WITH INDEPENDENT WORKS

7. AGGREGATION WITH INDEPENDENT WORKS

8. TRANSLATION

8. TRANSLATION

9. TERMINATION

9. TERMINATION

10. FUTURE REVISIONS OF THIS LICENSE

10. FUTURE REVISIONS OF THIS LICENSE

Kurzreferenz

Nach Stichwort

Nach Datei

useGroupEinführung in XML/XSLT

copyright (c)2003-2005   useGroup

Anhang B: Kurzreferenz

Anhang C: Druckversion

useGroupEinführung in XML/XSLTAnhang C: Druckversion

copyright (c)2003-2005   useGroup