1. Namensräume
   1. Motivation
      1. Ziele
         1. Kombination von XML-Dokument-Fragmenten, die verschiedenen DTDs unterliegen
         2. Verwendung von Standard-Modellen statt Eigenentwicklung
      2. Zu lösende Probleme
         1. Namenskonflikte vermeiden
         2. Welche DTD gehört zu welchem XML-Dokument-Fragment?
         3. Wie die Gültigkeit des kombinierten Dokuments überprüfen?
      3. Grundidee
         1. Einführung eines Namensraums für die Bezeichner jeder konkreten DTD
   2. Wie wird der Name vergeben?
      1. 1. Möglichkeit: Vergabe durch den Entwickler einer DTD
         1. Lediglich Verschiebung eines möglichen Namenskonflikts
      2. 2. Möglichkeit: Globale Vergabe der Namen durch eine zentrale Instanz
         1. Immenser Verwaltungsaufwand
      3. 3. Möglichkeit: Nutzung eines existierenden Konzepts: URI (Uniform Resource Identifier)
         1. Globale und lokale Bestandteile des Namens
   3. Definition
      1. Definition der offiziellen deutschen Übersetzung der W3C-Spezifikation: "Ein XML-Namensraum ist eine Zusammenstellung von Namen, identifiziert durch einen URIVerweis, die in XML-Dokumenten als Elementtypen und Attributnamen verwendet werden."
         1. Und weiter: "XML-Namensräume unterscheiden sich von den 'Namensräumen', die normalerweise im Computerbereich verwendet werden, in dem Maße, dass die XML-Version eine interne Struktur hat und im mathematischen Sinne keine Zusammensetzung ist." (Bezug auf Kontext eines Elements)
   4. URL's
      1. URL (Uniform Resource Locator)
         1. Bekannte Teilmenge der URI zur Lokalisation von Dateien
         2. Sind entwickelt worden, um Internet-Dokumente zu identifizieren
         3. Beschreiben den Ort der Ablage (es geht also nicht primär um einen eindeutigen Namen)
         4. Sind aber so allgemein, dass sie nicht nur Daten im Internet, sondern auch im Intranet oder auf einer lokalen Maschine identifizieren
         5. Werden in XML für Hyperlinks und zur Referenzierung von Entities benutzt.
         6. URL: Typischer Aufbau für HTTP URL
         7. Referenzierung von Fragmenten
      2. Relative URLs
         1. Wenn sich das referenzierte Objekt im selben Dateisystem befindet, reicht es, einen relativen Pfad anzugeben
         2. Pfad anzugeben. <!ENTITY introduction SYSTEM "chapters/intro.xml"> <!ENTITY introduction SYSTEM "../chapters/intro.xml">
   5. Beispiele für URIs (aus IETF RFC 2396)
      1. ftp://ftp.is.co.za/rfc/rfc1808.txt -- ftp scheme for File Transfer Protocol services gopher://spinaltap.micro.umn.edu/00/Weather/California/Los%20Angeles -- gopher scheme for Gopher and Gopher+ Protocol services http://www.math.uio.no/faq/compression-faq/part1.html -- http scheme for Hypertext Transfer Protocol services mailto:mduerst@ifi.unizh.ch -- mailto scheme for electronic mail addresses news:comp.infosystems.www.servers.unix -- news scheme for USENET news groups and articles telnet://melvyl.ucop.edu/ -- telnet scheme for interactive services via the TELNET Protocol
   6. Wie wird mit URIs für Namensräume umgegangen?
      1. Beispiel für Namensraum-URI: "http://www.w3.org/1999/xhtml"
      2. Obwohl es sich um Internet-Adressen handelt, muss die verarbeitende Applikation keinen Internet-Zugang haben und darauf zugreifen.
      3. Es geht nur um eine eindeutige Identifizierung.
   7. Verwendung von Namensraum-Bezeichnern im XMLDokument
      1. Aber: URIs sind nicht geeignet als Präfix
         1. zu lang
         2. nicht erlaubte Sonderzeichen
      2. Deshalb Kurzbezeichner als Präfix
   8. Namensraum-Deklaration
      1. Bindung einer URI an ein Präfix
         1. Wird realisiert durch das reservierte Attribut "xmlns"
         2. Das Attribut "xmlns" ist für alle Elemente erlaubt
            1. Beispiel: <x xmlns:edi='http://ecommerce.org/schema'> <!-- the "edi" prefix is bound to http://ecommerce. org/schema for the "x" element and contents --> </x>
         3. Das Präfix kann durch die Deklaration für das betreffende Element und Unterelemente verwendet werden
      2. Namensraum-Deklaration bezieht sich auf das betreffende Element und alle Unter-Element
         1. <?xml version="1.0"?> <!-- all elements here are explicitly in the HTML namespace --> <html:html xmlns:html='http://www.w3.org/TR/REC-html40'> <html:head> <html:title>Frobnostication</html:title> </html:head> <html:body> <html:p>Moved to <html:a href='http://frob.com'>here.</html:a></html:p> </html:body> </html:html>
         2. Namensraum-Deklarationen sind für alle Elemente erlaubt. Üblich ist es jedoch, sie am Wurzelelement aufzuführen
      3. Mehrere Namensraum-Deklarationen im selben Element erlaubt
         1. <?xml version="1.0"?> <!-- both namespace prefixes are available throughout --> <bk:book xmlns:bk='urn:loc.gov:books' xmlns:isbn='urn:ISBN:0-395-36341-6'> <bk:title>Cheaper by the Dozen</bk:title> <isbn:number>1568491379</isbn:number> </bk:book>
         2. Es handelt sich hier um zwei Attribute, die sich im Suffix unterscheiden
      4. Default-Namensraum: Suffix und Doppelpunkt entfallen
         1. <?xml version="1.0"?> <!-- elements are in the HTML namespace, in this case by default --> <html xmlns='http://www.w3.org/TR/REC-html40'> <head><title>Frobnostication</title></head> <body><p>Moved to <a href='http://frob.com'> here</a>.</p> </body> </html> ... <?xml version="1.0"?> <!-- unprefixed element types are from "books" --> <book xmlns='urn:loc.gov:books' xmlns:isbn='urn:ISBN:0-395-36341-6'> <title>Cheaper by the Dozen</title> <isbn:number>1568491379</isbn:number> </book>
      5. Default-Namensraum: Vererbungsregeln für Elemente
         1. Default-Namensraum bezieht sich auf das Element, wo die Deklaration stattfindet und auf Kind- Elemente.
         2. Wenn ein Element kein Namensraum-Präfix aufweist und es keinen Default-Namensraum gibt, wird für das Element gar kein Namensraum angenommen.
      6. Namensraum-Regeln für Attribute
         1. Default-Namensraum gilt nicht automatisch für Attribute
         2. Ein Attribut mit Namensraum-Präfix gehört zum entsprechenden Namensraum
         3. Ein Attribut ohne Namensraum-Präfix erbt den Namensraum des umgebenden Elements
            1. Wenn das umgebende Element ein Namensraum-Präfix aufweist, gilt dieser Namensraum für das Attribut.
            2. <FLIGHTS:SEAT CLASS="Y" HTML:CLASS="reallyImportant"> 33B</FLIGHTS:SEAT>
            3. Wenn das umgebende Element keinen Namensraum-Präfix aufweist, aber den Default- Namensraum erbt, so gilt der Default-Namensraum auch für das Attribut
            4. Wenn das umgebende Element keinem Namensraum angehört, ist das Attribut auch an keinen Namensraum gebunden.
      7. Default-Namensraum: Leerer String als URI hebt Default-Wirkung auf
         1. Übung: Welchen Namensraum weisen die Elemente auf? <?xml version='1.0'?> <Beers> <table xmlns='http://www.w3.org/TR/REC-html40'> <th><td>Name</td> <td>Origin</td> <td>Description</td></th> <tr> <td><brandName xmlns="">Huntsman</brandName></td> <td><origin xmlns="">Bath, UK</origin></td> <td> <details xmlns=""> <class>Bitter</class> <hop>Fuggles</hop> <pro>Wonderful hop, good summer beer</pro> <con>Fragile</con> </details></td> </tr></table></Beers>
            1. Lösung: <?xml version='1.0'?> <Beers> <!-- the default namespace is now that of HTML --> <table xmlns='http://www.w3.org/TR/REC-html40'> <th><td>Name</td> <td>Origin</td> <td>Description</td></th> <tr><!-- no default namespace inside table cells --> <td><brandName xmlns="">Huntsman</brandName></td> <td><origin xmlns="">Bath, UK</origin></td> <td> <details xmlns=""> <class>Bitter</class> <hop>Fuggles</hop> <pro>Wonderful hop, good summer beer</pro> <con>Fragile</con> </details></td> </tr></table></Beers>
      8. Namensräume und DTDs
         1. Eine DTD muss in den Inhaltsmodellen alle erlaubten Elemente aus den verschiedenen Namensräumen aufführen
            1. Dabei Nennung des Präfix als Bestandteil des Element-Namens
            2. <!ELEMENT bk:book (bk:title, isbn:number) >
         2. Auch die Namensraum-Deklaration ist Bestandteil der DTD
            1. <!ATTLIST bk:book xmlns:bk CDATA #FIXED "urn:loc.gov:books" xmlns:isbn CDATA #FIXED "urn:ISBN:0-395-36341-6">
2. DTD
   1. Schwächen von DTDs
      1. Keine XML Syntax
         1. Keine XML-Software anwendbar: Parser, Verarbeitung, Überprüfung der Wohlgeformtheit und Gültigkeit
         2. Nicht in XML-Editoren zu erstellen
         3. Keine leichte Erweiterbarkeit und Einbettung (z.B. Verarbeitung durch XSLT)
      2. Datentypen
         1. Wenige Datentypen verfügbar
         2. Keine Konzepte zur Definition neuer Datentypen
            1. Schlechte Erweiterbarkeit
         3. Praktisch keine Datentypen für den Inhalt von Elementen
         4. Sehr Zeichenketten-orientierte Datentypen für Attribute
      3. Einschränkungen bei Inhaltsmodellen
         1. Steuerung der Anzahl von Elementen
         2. Mixed Content
      4. Starke Einschränkungen bzgl. Namensräumen
      5. Einschränkungen bezüglich Wiederverwendbarkeit
         1. Konzept der globalen Definition von Elementen und Parameter Entities versus expliziter Referenzierung von Attributen, Elementen und Datentypen
         2. Einschränkungen bei der Wiederverwendbarkeit von DTD-Elementen: Attribute sind an Elemente gebunden
      6. Einschränkung bezüglich lokaler Gültigkeitsbereiche
         1. Attribute immer lokal, Elemente immer global
         2. Keine anonymen Typen
      7. Sehr eingeschränkter Referenzierungs-Mechanismus
   2. XML Dokument Struktur
      1. Element-Deklaration
         1. Element-Name
            1. Muss mit einem Buchstaben, “_”, oder “:” beginnen.
            2. Darf neben Buchstaben, “_” und “:” auch Zahlen, “.” und “-” enthalten
            3. Beliebige Länge
         2. Konnektoren
            1. Sequenz-Konnektor: “,”
            2. Oder-Konnektor: “| “
         3. Occurence Indicators
            1. Mindestens einmal: “+” (1-n)
            2. Optional: “?” (0-1)
            3. Beliebig oft (auch 0 mal): “*” (0-n)
            4. Häufigkeits-Kennzeichen haben Vorrang vor Konnektoren
         4. Inhaltsmodell
            1. #PCDATA
            2. Text-Inhalte
            3. “Mixed Content”
            4. Erlaubt: <!ELEMENT okay-xml (#PCDATA | emph)* > <!ELEMENT okay-xml1 (#PCDATA | emph | refint)* > <!ELEMENT okay-xml2 (#PCDATA) > Auch erlaubt: <!ELEMENT okay-xml4 (#PCDATA)* >
            5. Regeln
            6. #PCDATA muss immer an erster Stelle der Inhaltsbeschreibung stehen (andernfalls gibt es einen Parserfehler).
            7. #PCDATA und Elemente müssen in der Inhaltsbeschreibung mit »|« verknüpft werden.
            8. gesamte Mixed Content-Gruppe muss optional sein und beliebig oft vorkommen dürfen (es ist also nur der »*«-Operator zulässig).
            9. Weder die Anzahl noch die Reihenfolge der Child-Elemente eines Mixed-Content-Elements können daher genauer festgelegt werden.
         5. Empty Element
            1. Typische Anwendung: Meta-Information
            2. Elemente, die einen leeren Inhalt haben können
         6. Beliebiger Inhalt
            1. Element darf beliebige andere Elemente der DTD enthalten
      2. Attribut-Deklaration
         1. Regeln
            1. Attribut-Namen werden wie Element-Namen gebildet
            2. Für ein Element darf es mehrere Attribut-Deklarationen geben
            3. Die verschiedenen Deklarationen werden wie eine gemeinsame behandelt
            4. Wenn ein Attribut-Name mehrfach auftritt, gilt die erste Deklaration
         2. Default-Wert-Schlüsselwörter
            1. #REQUIRED
            2. Es muss ein Wert in der Dokument-Instanz angegeben werden.
            3. #IMPLIED
            4. Es muss kein Wert in der Dokument-Instanz angegeben werden
            5. #FIXED
            6. Der Wert ist fest vorgegeben
         3. Aufzählungstypen
         4. Datentypen für Attribut-Werte
            1. Beliebige Zeichenketten
            2. CDATA (Character Data), String
            3. Besondere Zeichenketten
            4. NMTOKEN (Name Token),
            5. wie Element/Attribut-Namen, aber ohne Sonderbedingungen für das erste Zeichen
            6. NMTOKENS
            7. mehrere NMTOKEN, durch Blank getrennt
            8. Für Referenzierungen
            9. ID
            10. IDREF
            11. IDREFS
            12. externe Daten
            13. ENTITY
            14. ENTITIES
            15. nicht-XML Daten
            16. NOTATION
      3. Entities
         1. Anderer Entity-Typ, um Namenskonflikte zu vermeiden
         2. Deklaration in der DTD (typischerweise der internen Teilmenge)
         3. Nutzung in der Dokument-Instanz
         4. Entity-Typen
            1. Parameter Entität (%)
            2. <!ENTITY % blocks "para | table | numlist | unumlist" >
            3. <!ELEMENT section (title, %blocks;) >
            4. mehrfach benötigt werden
            5. Parameter-Entitities in externen Dateien auszulagern, damit sie von verschiedenen DTDs genutzt werden können.
            6. Parameter Entities für komplexere Inhaltsmodelle
            7. OHNE <!ELEMENT chapter (title, note?, para+) > <!ELEMENT section (title, note?, para+) >
            8. <!ENTITY % chap-sec-content "(title, note?, para+)" <!ELEMENT chapter %chap-sec-content; > <!ELEMENT section %chap-sec-content; >
            9. Interne allgemeine (&)
            10. <!ENTITY amm "Aircraft Maintenance Manual">
            11. <para>The &amm; has 24,000 pages.</para>
            12. <amm long-name="&amm;">
            13. Text Entities
            14. Definition in der DTD, typischerweise in der internen Teilmenge
            15. Texte und Markup als Ersetzungstext erlaubt
            16. Anführungszeichen im Ersetzungstext erlaubt (einfache Anführungszeichen, wenn der Ersetzungstext in doppelten steht, und umgekehrt)
            17. Referenzierung der Entität darf im Inhalt und im Attributwert auftauchen
            18. Referenzierung darf nicht als Attributwert auftauchen
            19. Referenzierung darf im Entity-Wert einer Entity-Deklaration auftauchen
            20. Externe allgemeine (&)
            21. Referenzierung der Entität ist in Attribut-Werten verboten
            22. Referenzierung darf im Entity-Wert einer Entity-Deklaration auftauchen
            23. <!ENTITY introduction SYSTEM "chapters/intro.xml"> <!ENTITY introduction PUBLIC "//LUFTHANSASYSTEMS//CONTENTS//EN" "chapters/intro.xml " >
            24. <manual>&introduction;<chapter>...
            25. Externe, nicht-XML (z.B. graphic)
            26. Als externe Entität, Referenzierung im Attribut
            27. In der DTD: Empty Element mit Attribut vom Typ ENTITY oder ENTITIES
            28. <!ELEMENT graphic EMPTY> <!ATTLIST graphic gnbr ENTITY #REQUIRED>
            29. In der internen DTD-Teilmenge: Deklaration als allgemeine externe Entität, ungeparst
            30. <!ENTITY g123 SYSTEM "graphics/g123.cgm" NDATA CGM>
            31. Im Dokument: Referenzierung über Attribut im Empty Element
            32. <graphic gnbr="g123"/>
            33. Als Inhalt eines Elements
            34. Daten als Inhalt eines Elements, Angabe der Notation im Attribut vom Typ NOTATION
            35. <!ATTLIST word-document title CDATA #IMPLIED format NOTATION (RTF | MIF) "MIF"> <word-document title="An unstructured Text" format="RTF"> {\rtf\ansi\ansicpg1252\... </word-document>
            36. Format in einer Notation-Deklaration
            37. <!NOTATION CGM SYSTEM "graphics/mycgmviewer.exe" > oder <!NOTATION CGM PUBLIC "-//USA-DOD//NOTATION Computer Graphics Metafile//EN">
            38. Regeln für Notation-Deklarationen
            39. Wie in SGML ist es hier erlaubt, nur einen PUBLIC Identifier anzugeben
            40. Wenn keine Applikation zur Verarbeitung der nicht-XML-Daten verfügbar ist oder wenn das Format unbekannt ist, ist eine Einbindung dennoch möglich, wenn ein leeres System Literal angegeben wird: <!NOTATION UNKNOWN SYSTEM "" >
            41. Zeichen-Entität (z.B. Sonderzeichen &lt;)
            42. Die Referenzierung von Zeichen-Entities entspricht der von allgemeinen Entities.
            43. Zeichen-Entities nehmen Bezug auf den Zeichensatz ISO10646.
            44. Zur Bezeichnung eines Zeichens können dezimale Zahlen oder Hexadezimal-Zahlen benutzt werden.
            45. Eine Entity-Deklaration ist nicht notwendig, da die Abbildung von Namen auf Zeichen durch die Zeichensätze gegeben ist.
            46. Vordefinierte Entities
            47. Zeichen mit besonderer Bedeutung
            48. <!ENTITY lt "&#38;#60;">
            49. <!ENTITY gt "&#62;">
            50. <!ENTITY amp "&#38;#38;">
            51. <!ENTITY apos "&#39;">
            52. <!ENTITY quot "&#34;">
            53. Einsatz der Zeichen dort, wo die direkte Verwendung verboten ist.
         5. Referenzierung von Entities im Entity-Wert
            1. Auflösung von allgemeinen Entities erst im Dokument
            2. Beispiel aus XML-Spezifikation: <!ENTITY % pub "&#xc9;ditions Gallimard" > <!ENTITY rights "All rights reserved" > <!ENTITY book "La Peste: Albert Camus, &#xA9; 1947 %pub;. &rights;" >
            3. Der Ersetzungstext des Entity-Werts von "book" lautet: La Peste: Albert Camus, © 1947 Éditions Gallimard. &rights;
            4. Erst wenn "&book;" im Dokument-Inhalt oder einem Attribut-Wert auftauchen sollte, würde "&rights;" aufgelöst werden.
      4. ID/IDREF-Konzept
         1. Beispiel: <!ELEMENT chapter (...)> <!ATTLIST chapter key ID #REQUIRED> <!ELEMENT refint (#PCDATA)> <!ATTLIST refint refid IDREF #REQUIRED>
            1. Im Dokument: <para>Please refer to <refint refid="c12">chapter 12</refint> .</para>
         2. Regelln
            1. Identifier muss mit einem Buchstaben beginnen, darf "." und "-" enthalten
            2. Eindeutigkeit der Identifier wird durch den XML Parser überprüft
            3. ID/IDREF Konzept stammt von SGML
   3. Physikalische Organisation
      1. System Identifier
      2. Public Identifier
         1. Indirekter Zugriff über einen logischen Namen
         2. Auflösung mittels einer Katalog-Datei
         3. Zusätzlicher System Identifier erforderlich, falls Suche im Katalog nicht erfolgreich
      3. Conditional Sections
         1. Teilbereiche der DTD aus- und eingeblendet werden
         2. Konzept: Included / Ignored Sections
         3. Üblicherweise wird das INCLUDE bzw. IGNORE Schlüsselwort über eine Parameter-Entität eingebunden, um in den spezifischen Bestandteilen der DTD entsprechend gesetzt werden zu können.
         4. <![ %boeing-variant; [ <!ELEMENT example (action | command)+> ]]> <![ %airbus-variant; [ <!ELEMENT example (action | command | andasap)+> ]]>
            1. Bestandteile der Boeing DTD: <!ENTITY % boeing-variant " INCLUDE "> <!ENTITY % airbus-variant " IGNORE ">
            2. Bestandteile der Airbus DTD: <!ENTITY % boeing-variant "IGNORE"> <!ENTITY % airbus-variant "INCLUDE">
3. Info Sets
   1. Was ist ein XML Information Set?
      1. Abstraktes Datenmodell, dass ein wohlgeformtes XML-Dokument repräsentiert
      2. Ein XML-Dokument stellt eine mögliche, konkrete Implementierung eines Infosets dar, Infoset beschreibt Struktur unabhängig von konkreter Syntax
      3. Kann beim Parsen eines XML-Dokuments erzeugt werden, muss aber nicht
      4. Ein XML-Dokument muss nicht gültig bzgl. einer DTD sein, um ein Infoset zu haben
   2. Aufbau eines Infosets
      1. Setzt sich aus Informationseinheiten zusammen
      2. Es gibt verschiedene Typen von Informationseinheiten
      3. Informationseinheiten werden durch Eigenschaften beschrieben
   3. Typen von Informations-Einheiten
      1. Dokument-IE
         1. Eigenschaften der Dokument-IE
            1. [children] - Geordnete Liste mit den Kind-IEs (IE für Wurzel-Element, ggf. für PIs, ggf. für Kommtare, Dokumenttyp-Deklaration) (PI = Processing Instruction)
            2. [document element] - IE für das Wurzel-Element
            3. [notations] - die in der DTD deklarierten Notationen
            4. [unparsed entities] - Menge der ungeparsten Entities, die in der DTD deklariert sind
            5. [base URI] - Adresse des XML-Dokuments
            6. [character encoding scheme] - Zeichensatz
            7. [standalone] - Entspricht standalone-Attribute aus XML-Deklaration
            8. [version] - XML-Version
            9. [all declarations processed] - Boolsches Attribut, das anzeigt, ob der Prozessor die gesamte DTD lesen konnte
      2. Element-IE
         1. Eigenschaften der Element-IE I [namespace name] - Namensraum-Bezeichner I [local name] - Name des Elements I [prefix] - Namensraum-Kurzname I [children] - Geordnete Liste mit den Kind-IEs (für Elemente, Zeichen, ggf. PIs, ggf. Kommtare, ggf. nicht-erweiterte Entity-Verweise) I [attributes] - Ungeordnete Zusammenstellung von Attribut-IEs (eine IE für jedes Attribut des Elements) I [namespace attributes] - Ungeordnete Zusammenstellung von Attribut-IEs (eine IE für jedes Namensraum-Attribut) I [in-scope namespaces] - Ungeordnete Zusammenstellung von Namensraum-IEs I [base URI]: Basis-URI des Elements I [parent]: Die Eltern-IE
      3. Attribut-IE
         1. Eigenschaften der Attribut-IE I [namespace name] I [local name] I [prefix] I [normalized value] - Der Attributwert I [attribute type] - Der in der DTD angegebene Typ, sonst kein Wert (soll wie CDATA behandelt werden) I [references] - Nur für die Typen IDREF, IDREFS, ENTITY, ENTITIES, NOTATION: Liste der IE der referenzierten Objekte I [owner element] - Element-IE zu der das Attribut gehört
      4. Zeichen-IE
         1. Eigenschaften der Zeichen-IE I [character code] - Der ISO-10646-Zeichencode (bis #x10FFFF) I [element content whitespace] - Boolescher Wert für Whitespace I [parent] - Die Eltern-IE
      5. Kommentar-IE
      6. PI-IE
      7. IE für nicht-erweiterte Entity-Referenzen (Entities werden im Allgemeinen aufgelöst)
      8. Notations-IE
      9. IE für ungeparste Entities
      10. IE für Dokumenttyp-Deklarationen
      11. Namensraum-IE
   4. Generierung von IEs durch XML-Prozessor
      1. Ein XML-Prozessor muss immer alle Zeichen, die nicht zum Markup zählen, an die Anwendung liefern.
      2. Ein validierender XML-Prozessor muss für ein Attribut mit Default-Wert, das nicht im XMLDokument auftaucht, ein Attribut-IE erzeugen
   5. Übung
      1. Übung: Welche IEs werden von einem XML-Prozessor für das folgende Dokument erzeugt? <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <adresse> <name>HAW</name> <strasse nr="7">Berliner Tor</strasse> <ort plz="20099">Hamburg</ort> </adresse>
         1. Lösung:
4. XML Schema
   1. Vorteile vs DTD
      1. XML Applikation (validierbar, Verarbeitung durch XML Tools möglich)
      2. Mächtiger bzgl. Datentypen
      3. Datentypen selbst definierbar
      4. Modularisierbar (Wiederverwendung)
      5. Unterstützung von Namensräumen
      6. Auftrittshäufigkeit leichter zu steuern
      7. Lokal unterschiedliche Deklarationen
      8. Besserer Referenzierungsmechanismus
      9. Restriktivere Mixed Content Modelle
   2. Schwächen von XML Schema
      1. Umfangreich, aufwendig
         1. Für einfache Anwendungen umständlich
         2. Für Dokumenten-zentrierte Anwendungen manchmal unnötig
         3. (Höhere Entwicklungskosten)
      2. Keine Parameter-Entities
         1. Sehr flexibles und einfaches Konstrukt
      3. Häufig ist die einfachere Lösung die bessere!
   3. Grundkonzepte
      1. Datentyp-Definitionen
         1. Einfache Datentypen (Simple Type)
            1. Alle Attribute
            2. Elemente ohne Kinder und Attribute
            3. Es existiert eine Reihe vordefinierter einfacher Datentypen
            4. Auf der Basis der vordefinierten Datentypen kann man eigene definieren
            5. Ableitung neuer einfacher Datentypen
            6. Benutzer-definierte Datentypen können aus bereits existierenden abgeleitet werden
            7. Einschränkung auf eine Teilmenge ("Restriction")
            8. Durch das Restriction-Element
            9. Bezug zu einem Basis-Typ über Attribut "base" oder über Simple-Type-Deklaration als Kind- Element
            10. Definition der Einschränkung über "Facets"
            11. Spezifikation
            12. <restriction base = QName id = ID {any attributes with non-schema namespace . . .}> Content: (annotation?, (simpleType?, (minExclusive | minInclusive | maxExclusive | maxInclusive | totalDigits | fractionDigits | length | minLength | maxLength | enumeration | whiteSpace | pattern)*)) </restriction>
            13. Ableitung eines neuen einfachen Datentyps durch Einschränkung: Beispiele <xsd:element name="quantity"> <xsd:simpleType> <xsd:restriction base="xsd:positiveInteger"> <xsd:maxExclusive value="100"/> </xsd:restriction> </xsd:simpleType> </xsd:element> <xsd:simpleType name="SKU"> <xsd:restriction base="xsd:string"> <xsd:pattern value="\d{3}-[A-Z]{2}"/> </xsd:restriction> </xsd:simpleType>
            14. Liste von Elementen eines Basis-Datentyps ("List")
            15. Vordefinierte Listen-Typen: NMTOKENS, IDREFS, ENTITIES
            16. Definition eigener Listen-Typen durch Element "list"
            17. Bezug zum Basis-Typ über Attribut "itemType" oder Simple-Type-Deklaration (nur Simple Types erlaubt)
            18. Spezifikation
            19. <list id = ID itemType = QName {any attributes with non-schema namespace . . .}> Content: (annotation?, (simpleType?)) </list>
            20. Beispiele <xsd:simpleType name='messwerte'> <xsd:list itemType='xsd:float'/> </xsd:simpleType> <xsd:simpleType name='jahreszahlen'> <xsd:list itemType='xsd:positiveInteger'/> </xsd:simpleType>
            21. Vereinigung mehrerer Basis-Datentypen ("Union")
            22. Definition eines Vereinigungs-Typs über Element "union"
            23. Bezug zu den Basis-Typen über Attribut "memberTypes" oder durch Simple Type Deklarationen
            24. <union id = ID memberTypes = List of QName {any attributes with non-schema namespace . . .}> Content: (annotation?, (simpleType*)) </union>
            25. Beispiel <xsd:attribute name="size"> <xsd:simpleType> <xsd:union> <xsd:simpleType> <xsd:restriction base="xsd:positiveInteger"> <xsd:minInclusive value="8"/> <xsd:maxInclusive value="72"/> </xsd:restriction> </xsd:simpleType> <xsd:simpleType> <xsd:restriction base="xsd:NMTOKEN"> <xsd:enumeration value="small"/> <xsd:enumeration value="medium"/> <xsd:enumeration value="large"/> </xsd:restriction> </xsd:simpleType> </xsd:union> </xsd:simpleType> </xsd:attribute> <p> <font size='large'>A header</font> </p> <p> <font size='12'>this is a test</font> </p>
            26. Variante über Attribut "memberTypes": <xsd:simpleType name="point"> <xsd:restriction base="xsd:positiveInteger"> <xsd:minInclusive value="8"/> <xsd:maxInclusive value="72"/> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="type"> <xsd:restriction base="xsd:NMTOKEN"> <xsd:enumeration value="small"/> <xsd:enumeration value="medium"/> <xsd:enumeration value="large"/> </xsd:restriction> </xsd:simpleType> <xsd:attribute name="size"> <xsd:simpleType> <xsd:union memberTypes="point type"/> </xsd:simpleType> </xsd:attribute>
            27. Die vordefinierten abgeleiteten Datentypen sind als Einschränkung oder als Liste definiert
            28. Beispiel
            29. Simple Type Definition <simpleType final = (#all | (list | union | restriction)) id = ID name = NCName {any attributes with non-schema namespace . . .}> Content: (annotation?, (restriction | list | union)) </simpleType>
         2. Komplexe Datentypen (Complex Type)
            1. Für Elemente
            2. Elemente mit Kindern oder Attributen
            3. Komplexe Typen können auf zwei Arten definiert werden
            4. globale Definition
            5. lokale Definition
            6. Komplexe Datentypen betreffen die Inhaltsmodelle von Elementen
            7. Nur einfacher Inhalt: keine Attribute, keine Unterelemente: -> "Simple Type"
            8. Kein Inhalt (leeres Inhaltsmodell), aber Attribute
            9. Wenn ein Element Attribute aufweist, ist es von einem komplexen Datentyp
            10. Es reicht, die Attribut-Deklarationen innerhalb einer Complex Type Definition aufzuführen
            11. <xsd:element name="effect" <xsd:complexType> <xsd:attribute name="effrg" type="xsd:string"/> <xsd:attribute name="efftxt" type="EfftxtType"/> </xsd:complexType> </xsd:element>
            12. Kein Inhalt, keine Attribute
            13. Wie kein Inhalt mit Attributen, jedoch keine Nennung von Attributen
            14. <xsd:element name="revst"> <xsd:complexType/> </xsd:element>
            15. Einfacher Inhalt, aber Attribute
            16. Inhalt wird durch einfachen Datentyp beschrieben, auf den selbstverständlich Bezug genommen werden soll.
            17. Das Element ist aber von einem komplexen Datentyp, weil es Attribute aufweist.
            18. Die Beschreibung des komplexen Datentyps muss also einen einfachen Datentyp referenzieren
            19. Dies geschieht über ein "Simple Content" Element (der Basis-Datentyp wird um Attribute erweitert)
            20. erweitert): <xsd:element name="PreisInternational" <xsd:complexType> <xsd:simpleContent> <xsd:extension base="xsd:decimal"> <xsd:attribute name="Währung" type="xsd:string"/> <xsd:/extension> </xsd:simpleContent> </xsd:complexType> </xsd:element>
            21. Mixed Content
            22. Beispiel
            23. <BriefText> <Anrede>Sehr geehrter Herr <Name>Schmid</Name>,</Anrede> Ihre Bestellung von <Anzahl>1</Anzahl> <Buchtitel>Herr der Ringe</Buchtitel> wurde am <Lieferdatum>1999-05-21</Lieferdatum> ausgeliefert. ... </BriefText>
            24. <xsd:element name="BriefText"> <xsd:complexType mixed="true"> <xsd:sequence> <xsd:element name="Anrede"> <xsd:complexType mixed="true"> <xsd:sequence> <xsd:element name="Name" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="Anzahl" type="xsd:positiveInteger"/> <xsd:element name="Buchtitel" type="xsd:string"/> <xsd:element name="Lieferdatum" type="xsd:date"/> <!-- usw. --> </xsd:sequence> </xsd:complexType> </xsd:element>
            25. Modell kann mit XML Schema genauer spezifiziert werden als in der XMLSpezifikation vorgesehen
            26. Reihenfolge und Anzahl der Kindelemente können festgelegt werden
            27. Konzepte für komplexe Inhaltsmodelle
            28. Sequenz-Gruppe ("Sequence Group")
            29. Auswahl-Gruppe ("Choice Group")
            30. "All"-Gruppe: Mehrere Elemente in beliebiger Reihenfolge (wenig restriktiv)
            31. Beispiel: All-Gruppe <xsd:complexType name="Contact"> <xsd:all> <xsd:element name="email" type="EmailType" minOccurs="0"/> <xsd:element name="address" type="AddressType" minOccurs="0"/> <xsd:element name="tel" type="TelType" minOccurs="0"/> </xsd:all> </xsd:complexType>
            32. Steuerung der Wiederholung durch Attribute "minOccurs", "maxOccurs"
            33. Erlaubt für Sequenz-Gruppe und Auswahl-Gruppe
            34. Für All-Gruppe gilt: minOccurs=0|1, maxOccurs=1
            35. Default-Werte: 1
            36. Model Groups
            37. Globale Definition einer Model Group durch das Element "group"
            38. Erlaubte Bestandteile einer Model Group: (sequence | choice | all)
            39. Referenzierung in komplexen Typdefinitionen
            40. <xsd:group name="wcnGroup"> <xsd:choice> <xsd:element name="warning" type="paraType"/> <xsd:element name="caution" type="paraType"/> <xsd:element name="note" type="paraType"/> </xsd:choice> </xsd:group> ... <xsd:complexType> <xsd:sequence> <xsd:group ref="wcnGroup" maxOccurs="unbounded"/> <xsd:element name="procitems" type="procitemsType"/> </xsd:sequence> </xsd:complexType>
            41. Kind-Elemente und ggf. Attribute
            42. Beispiel
            43. Beispiel: Komplexe Datentypen <xsd:complexType name="Items"> <xsd:sequence> <xsd:element name="item" minOccurs="0" maxOccurs="unbounded"> <xsd:complexType> <xsd:sequence> <xsd:element name="productName" type="xsd:string"/> <xsd:element name="quantity"> <xsd:simpleType> <xsd:restriction base="xsd:positiveInteger"> <xsd:maxExclusive value="100"/> </xsd:restriction> </xsd:simpleType> </xsd:element> <xsd:element name="USPrice" type="xsd:decimal"/> <xsd:element ref="comment" minOccurs="0"/> <xsd:element name="shipDate" type="xsd:date" minOccurs="0"/> </xsd:sequence> <xsd:attribute name="partNum" type="SKU" use="required"/> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType>
            44. Einschränkung und Erweiterung von Datentypen
            45. Sinn und Zweck?
            46. Es kann auf bestehende Definitionen zurückgegriffen werden
            47. Anwendungen, die den allgemeinen Fall beherrschen, können auch mit dem eingeschränkten Fall umgehen
            48. Einschränkung und Erweiterung von einfachen Datentypen
            49. Einschränkung (restriction) eines einfachen Datentyps ergibt einen einfachen Datentyp
            50. Erweiterung eines einfachen Datentyps, um Attribute einzubinden. Resultat: komplexer Datentyp
            51. Einschränkung von komplexen Datentypen
            52. complexContent
            53. restriction
            54. Beispiel:
            55. I Beispiel: <xsd:complexType name="ArbeitstagTyp"> <xsd:complexContent> <xsd:restriction base="WochentagTyp"> <xsd:sequence> <xsd:element name="Montag" type="xsd:string"/> <xsd:element name="Dienstag" type="xsd:string"/> <xsd:element name="Mittwoch" type="xsd:string"/> <xsd:element name="Donnerstag" type="xsd:string"/> <xsd:element name="Freitag" type="xsd:string"/> </xsd:sequence> </xsd:restriction> </complexContent> </xsd:complexType>
            56. Erweiterung von komplexen Datentypen
            57. complexContent
            58. extension
            59. Beispiel
            60. Beispiel: <xsd:complexType name="KonferenzteilnehmerTyp"> <xsd:complexContent> <xsd:extension base="PersonenTyp"> <xsd:sequence> <xsd:element name="firma" type="xsd:string"/> </xsd:sequence> </xsd:extension> </complexContent> </xsd:complexType>
            61. Zusatzinformation
            62. Ableitung von Datentypen: Verhinderung der Definition abgeleiteter Datentypen
            63. final
            64. restriction
            65. extension
            66. #all
            67. Beispiel: Erweiterung erlaubt, Einschränkung verboten
            68. Beispiel: Erweiterung erlaubt, Einschränkung verboten <xsd:complexType name="PersonenTyp" final="restriction"> <xsd:sequence> <xsd:element name="anrede" type="xsd:string"/> <xsd:element name="vorname" type="xsd:string"/> <xsd:element name="nachname" type="xsd:string"/> </xsd:sequence> </xsd:complexType>
            69. Attribut "finalDefault" im Element "schema" verhindert die Ableitung für alle Typen
            70. Abgeleitete Typen in Dokumenten-Instanzen
            71. Beispiel
            72. Im Schema: <xsd:element name="person" type="PersonenTyp"/> In der Instanz: <person xsi:type="KonferenzteilnehmerTyp"> <anrede>Herr</anrede> <vorname>Rudolf</vorname> <nachname>Meyer</nachname> <firma>Lufthansa</firma> </person>
            73. Zusatzinformation
            74. Abgeleitete Typen in Dokumenten-Instanzen: Verhinderung dieses Mechanismus im Schema
            75. block
            76. <xsd:complexType name="PersonenTyp" block="extension"> <xsd:sequence> <xsd:element name="anrede" type="xsd:string"/> <xsd:element name="vorname" type="xsd:string"/> <xsd:element name="nachname" type="xsd:string"/> </xsd:sequence> </xsd:complexType>
            77. Attribut "blockDefault" im Element "schema" verhindert die Verwendung von abgeleiteten Typen in der Instanz für alle Typen.
         3. Grundeigenschaften von Datentypen
            1. Ein Datentyp ist ein 3-Tupel
            2. Wertebereich ("value space")
            3. Die grundsätzlich erlaubten Werte
            4. Lexikalische Repräsentation ("lexical space")
            5. die Menge der gültigen Literale
            6. Darstellungen der erlaubten Werte (z.B. 135000 oder 135.000,00 oder 13,5E4 für dasselbe Element der Wertebereichs
            7. Für jedes Element des Wertebereichs existiert mindestens 1 Element des lexikalischen Bereichs. (U.a. für den Datentyp "String" sind Wertebereich und lexikalischer Bereich gleich.)
            8. "Facets"
            9. "Fundamental Facets"
            10. Test auf Gleichheit
            11. Für zwei Werte a und b eines Wertebereichs gilt immer entweder a=b oder a<>b
            12. Existenz einer Ordnungsrelation
            13. false, partial, total
            14. Bounded
            15. Existenz von Schranken
            16. Kardinalität
            17. "endlich" oder "abzählbar unendlich"
            18. Numerisch
            19. "wahr" oder "falsch"
            20. "Constraining Facets"
            21. length, minLength, maxLength
            22. Länge von String-ähnlichen Daten
            23. pattern
            24. Muster, definiert durch reguläre Ausdrücke
            25. <xsd:simpleType name="USState"> <xsd:restriction base="xsd:string"> <xsd:pattern value="AK|AL|AR"/> <!-- and so on ... --> </xsd:restriction> </xsd:simpleType>
            26. Einschränkung des duration-Datentyps: <xsd:simpleType name="myduration"> <xsd:restriction base="xsd:duration"> <xsd:pattern value="P\d+D\d+H\d+M\d+S"/> </xsd:restriction> </xsd:simpleType> Beispiel-Wert: P10D2H30M45S (P:period, D:days, H:hours, M:minutes, S:seconds)
            27. enumeration
            28. Aufzählungen
            29. <xsd:simpleType name="USState"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="AK"/> <xsd:enumeration value="AL"/> <xsd:enumeration value="AR"/> <!-- and so on ... --> </xsd:restriction> </xsd:simpleType>
            30. whiteSpace
            31. Umgang mit Leerzeichen, Zeilenumbrüchen, etc. (erlaubte Werte: "preserve", "replace", "collapse")
            32. minInclusive, minExclusive, maxInclusive, minInclusive
            33. Obere und untere Schranken
            34. totalDigits, fractionDigits
            35. Anzahl Stellen bzw. der Nachkomma-Stellen von Zahlen
            36. <xsd:simpleType name='amount'> <xsd:restriction base='xsd:decimal'> <xsd:totalDigits value='8'/> <xsd:fractionDigits value='2' fixed='true'/> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name='celsiusBodyTemp'> <xsd:restriction base='xsd:decimal'> <xsda:totalDigits value='4'/> <xsd:fractionDigits value='1'/> <xsd:minInclusive value='36.4'/> <xsd:maxInclusive value='40.5'/> </xsd:restriction> </xsd:simpleType>
      2. Definitionen
         1. Global
            1. Referenzierung über einen Namen
         2. Lokal
            1. Z.B. innerhalb von Deklarationen ("Anonymous Type Definitions")
      3. Deklarationen
         1. Global
            1. Auch für Attribute
         2. Lokal
            1. Auch für Elemente
            2. Innerhalb von Deklarationen und innerhalb von Typ-Definitionen
   4. Spezielle Konzepte
      1. Attributgruppen
         1. <xsd:element name="chapter"> <xsd:complexType> <xsd:sequence> <xsd:element ref="title"/> <xsd:element ref="section" minOccurs="1" maxOccurs="unbounded"> </xsd:sequence> <xsd:attributeGroup ref="RevisionAtts"> </xsd:complexType> </xsd:element> <xsd:attributeGroup name="RevisionAtts"> <xsd:attribute name="chg" type="chgType"/> <xsd:attribute name="revdate" type="dateType"/> <xsd:attribute name="key" type="xsd:string"/> </xsd:attributeGroup>
      2. Identity Constraints
         1. Element "unique"
            1. Inhaltsmodell: (selector, field+)
            2. <xsd:unique name="eindeutigePerson"> <xsd:selector xpath="veranstaltung/teilnehmer"/> <xsd:field xpath="vorname"/> <xsd:field xpath="nachname"/> <xsd:field xpath="firma"/> </xsd:unique>
            3. Unterschiede zu DTDs
            4. Eindeutigkeit gilt nur für den spezifizierten Bereich
            5. Eindeutigkeit kann für beliebige Element-Inhalte und Attribut-Werte verlangt werden
            6. Eindeutigkeit kann sich auf Kombinationen von Inhalten beziehen
         2. Elemente "key", "keyref"
            1. Dient dazu, die Gleichheit von Kombinationen von Inhalten zu gewährleisten: (key tritt innerhalb von Elementdeklarationen auf)
            2. <xsd:key name="PersonenSchlüssel"> <xsd:selector xpath="veranstaltung/teilnehmer"/> <xsd:field xpath="vorname"/> <xsd:field xpath="nachname"/> <xsd:field xpath="firma"/> </xsd:key> <xsd:element name="Werbung" type="WerbungTyp"/> <xsd:keyref name="teilnehmerRef" refer="PersonenSchlüssel"> <xsd:selector xpath="InfoEmpfänger"/> <xsd:field xpath="vorname"/> <xsd:field xpath="nachname"/> <xsd:field xpath="firma"/> </xsd:keyref> </xsd:element>
         3. Datentypen "ID", "IDREF"
      3. Kommentare
         1. Kommentare sind praktisch überall als erstes Kindelement erlaubt
         2. Automatisch generierte Dokumentation eines Schemas möglich
         3. annotation
            1. documentation
            2. app-info
            3. Beliebiges Inhaltsmodell für "documentation" und "app-info"
            4. Beispiel
            5. <annotation> <documentation xml:lang="DE"> <myns:benutzer>Das Element &lt;efflist&gt; enthält die Effectivity-Konfigurierungsdaten.</myns:benutzer> <myns:entwickler>Die Efflist muss beim Aufruf des Editors übergeben werden.</myns:entwickler></documentation> <app-info>/customer/variant/ac/msn</app-info> </annotation>
   5. Gültigkeit
      1. Ein Schema stellt ebenfalls ein XML-Dokument dar. Seine Gültigkeit kann daher auch bezüglich einer DTD oder eines Schemas überprüft werden
      2. Gültigkeit eines XML-Dokuments gilt bezüglich einer bestimmten DTD oder bezüglich eines bestimmten Schemas
      3. Unterschied relevant: Schema bietet grundsätzlich stärkere Steuerungs-Möglichkeiten
      4. Bezüglich Schema kann man unterscheiden zwischen
         1. Content Model Validity (korrekte Strukturen)
         2. Datatype Validity
   6. XML Schema und Namensräume
      1. Namensraum für Elemente und Attribute zur Beschreibung eines XML Schemas
         1. I Präfix: xsd I URI: http://www.w3.org/2001/XMLSchema
      2. Namensraum für solche Elemente und Attribute aus der Schema-Definition, die in Dokument- Instanzen verwendet werden dürfen
         1. I Präfix: xsi I URI: http://www.w3.org/2001/XMLSchema-instance
      3. Ziel-Namensraum ("target namespace") für Dokument-Instanzen
         1. I Präfix: wird in der Instanz vergeben I URI: wird im Schema festgelegt
   7. Haupt-Bestandteile eines Schemas
      1. Bild
   8. Design-Strategien
      1. Salami Slice
         1. Fokus: Globale Element-Deklarationen
         2. Beispiel
            1. <xsd:schema ... <xsd:element name="manual"> <xsd:complexType> <xsd:sequence <xsd:element ref="title"/> <xsd:element ref="chapter maxOccurs="unbounded"> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="chapter"> <xsd:complexType> <xsd:sequence> <xsd:element ref="title"/> <xsd:element ref="section" maxOccurs="unbounded"> </xsd:sequence> </xsd:complexType> </xsd:element> ...
         3. Eigenschaften
            1. Wie DTD
            2. Alle Elemente wiederverwendbar
            3. Keine lokal unterschiedlichen Definitionen von Element-Inhalten
            4. Wert von elementFormDefault ist ohne Bedeutung
            5. Element-Substitution möglich
5. Entwurfsziele XML
   1. im Internet auf einfache Weise nutzen lassen
   2. ein breites Spektrum von Anwendungen unterstützen
   3. zu SGML kompatibel
   4. einfach sein, Programme zu schreiben, die XML-Dokumente verarbeiten
   5. Zahl optionaler Merkmale in XML soll minimal sein
   6. XML-Dokumente sollten für Menschen lesbar
   7. Entwurf von XML soll formal und präzise sein
   8. XML-Dokumente sollen leicht zu erstellen sein
   9. Knappheit von XML-Markup ist von minimaler Bedeutung
   10. Motivation
       1. HTML
       2. SGML
6. Wohlgeformtheit
   1. Bedingung 1:
      1. Ein XML-Dokument enthält ein oder mehrere Elemente
      2. Es gibt exakt ein Wurzel-Element.
      3. Alle anderen Elemente haben Start-Tag und Ende-Tag im Inhalt desselben (Eltern-) Elements, sind also korrekt verschachtelt
   2. Bedingung 2
      1. Für Ende-Tag gibt es passendes Start-Tag
      2. Attribut-Namen dürfen nur einmal pro Start-Tag oder Empty-Element auftauchen
      3. Zeichen gehören zum erlaubten Zeichensatz
7. Publikation von XML Dokumenten
   1. CSS
   2. XPath
      1. Adressierung von Teilen eines XML-Baumes
   3. XQuery
   4. XSLT
8. Verarbeitung von XML Dokumenten
   1. XSLT
      1. XSL
         1. die FO Repräsentation
         2. die Vereinigung aus XSL (FO) und XSLT
         3. manchmal auch XSLT
      2. Transformationssprache zur Überführung von einer XMLDokumentart
   2. XSLT-FO
      1. Layout-Beschreibungssprache
      2. FO (Formatting Objects)
   3. SAX
      1. Eigenschaften
         1. Ereignis-basiert, sequentielle Abarbeitung
         2. geringer Speicherbedarf, geeignet für große Dokumente
         3. kein Zugriff auf den gesamten Baum
         4. keine Schreibmöglichkeit
         5. schnell
         6. Push-Ansatz (Kontrolle bei Parser)
      2. Methoden
         1. endDocument()
         2. endElement()
         3. startDocument()
         4. startElement()
         5. ignorableWhitespace()
         6. characters()
         7. skippedEntity()
   4. DOM
      1. Eigenschaften
         1. hoher Speicherbedarf, ungeeignet für große Dokumente
         2. Baumbasiert
         3. voller Zugriff aufs Dokument
         4. Schreibmöglichkeit
         5. keine inkrementelle Abarbeitung möglich
      2. Methoden
         1. getElementsByTagName()
         2. createElement()
         3. getChildNodes()
         4. getFirstChild()
         5. getParentNode()
         6. hasChildNodes()
         7. hasAttributes()
         8. insertBefore()
   5. StAX
      1. Eigenschaften
         1. Ereignis-basiert
         2. Pull-Ansatz (Kontrolle bei aufr. Anw.)
         3. Streaming und Cursor API vs Iterator API
         4. geringer Speicherbedarf
         5. kein Zugriff auf den ganzen Baum
         6. frühzeitiger Abbruch des Parsens möglich
         7. mehrere Threads
   6. JDOM
      1. Eigenschaften
         1. keine Factories, Java-orientiert
         2. Baumbasiert
         3. Erzeugung von SAX Events möglich
         4. relativ effizient
9. Bestandteile
   1. XML-Deklaration
      1. Zeichenfolge zur Kennzeichnung der XML-Deklaration "<?xml"
      2. Versions Information
      3. Encoding Deklaration
      4. Standalone Dokument Deklaration
         1. standalone="yes"
            1. Es wird nur die interne DTD-Teilmenge abgearbeitet. Die externe DTD-Teilmenge wird ignoriert, unabhängig davon, ob eine externe DTD-Teilmenge referenziert wird oder nicht.
         2. standalone="no"
            1. Die Voreinstellung: Die externe DTD-Teilmenge wird abgearbeitet, ebenso wie die interne.
   2. Dokument-Typ Deklaration
      1. Interne und externe DTD-Teilmenge
         1. Mit der internen Teilmenge kann man externe Definitionen überschreiben
         2. Interne DTD-Teilmenge wird typischerweise für Dokument-spezifische Deklarationen verwendet
         3. Insbesondere spezifische Entity-Deklarationen
   3. Kommentare (optional)
      1. Schlüsselwort auch am Ende (Konsistenz mit SGML)
      2. Zeilenumbrüche innerhalb der Kommentar-Deklaration erlaubt
      3. Keine Doppel-Bindestriche innerhalb des Kommentar-Textes erlaubt
      4. Keine Einbettung in andere Deklarationen, z.B. Element-Deklarationen, erlaubt
      5. Ansonsten an beliebigen Positionen außerhalb anderen Markups
   4. Processing Instructions (optional)
      1. Eine Verarbeitungs-Anweisung ist eine Information, die für eine bestimmte XML-Applikation gilt und von dieser ausgeführt wird.
      2. Verarbeitungs-Anweisungen dürfen an fast beliebiger Stelle im Inhalt von Elementen und im Prolog auftreten.
   5. CDATA Sections (optional)
      1. Bereiche können als "CDATA Section" deklariert werden. Darin enthaltene Sonderzeichen werden dann nicht als Markup interpretiert.
   6. keine DTD vorhanden
      1. I Alle Attribute vom Typ CDATA (Annahme des Prozessors)
      2. I Alle Attribute optional (IMPLIED) (Annahme des Prozessors)
      3. I Keine Default-Werte
      4. Keine Entitities (außer den vordefinierten Zeichen-Entitities “&lt;”, “&gt;”, “&amp;”, “&apos;” und “&quot;”)
10. Gültigkeit
    1. wohlgeformt
    2. Verweis auf eine Grammatik
    3. durch die Grammatik beschriebene Format einhält