Die Auszeichnungssprache XML

Download Report

Transcript Die Auszeichnungssprache XML

Seminar:
XML und Datenbanken
Die Auszeichnungssprache XML
Jena, 27.Mai 2004
Lutz Garstecki
Geschichtliche Entwicklung
• 1964 GML als erste moderne Auszeichnungssprache entwickelt
• 1986 SGML (Standard Generalized Markup Language) von ISO als Standard
für Speicherung und Austausch v. Daten festgelegt (ISO 8879)
• 1996 begann W3C (WWW-Consortium) mit Entwicklung von XML
(Extensible Markup Language)
– sollte Mächtigkeit von SGML mit Akzeptanz von HTML verbinden
• Februar 1998 erklärt W3C XML 1.0 zu einer Empfehlung
– formale Spezifikation und Grammatik in EBNF unter
http://www.w3c.org/TR/REC-xml
Jena, 27.Mai 2004
Lutz Garstecki
Was ist Markup und warum XML?
• Markup
– Methode zur Übermittlung von Metadaten
– MLs benutzen Literale und Tags um Metadaten zu beschreiben und von
eigentlichen Inhalt zu trennen
• Bei Entwicklung starker Bezug auf Spezifikation von
SGML aber einfacher
– zB. XML-Parser leichter zu erstellen, benutzt bereits existierende InternetProtokolle und –Anwendungen, bleibt aufwärtskompatibel
• Datenaustausch übers Internet mit XML
– Offenes System
– Weitgehend selbstdokumentierend
– auch ohne vorhergehende Koordination
• basiert auf UCS (Universal Character Set)
– definiert im Standard ISO/IEC 10646 (Unicode)
Jena, 27.Mai 2004
Lutz Garstecki
Was ist Markup und warum XML? (2)
• Standard-API (Application Programming Interface) von W3C für
XML entwickelt
• Unterstützung von Internationalisierung
• alle bekannten und beliebten Features von HTML
– trotzdem kein Ersatz
• Obwohl hauptsächlich Daten selbst im Vordergrund,
trotzdem Möglichkeiten der Darstellung
– Stylesheets
„XML ist eine mächtige und elegante Art und Weise, wie man mit
Daten umgeht, diese mit anderen austauschen kann und das alles
über die Grenzen von unterschiedlichen Betriebssystemen hinweg.“
Jena, 27.Mai 2004
Lutz Garstecki
Syntax: Entity, Tag, Zeichen
• Markup = Auszeichnung zur Beschreibung und Strukturierung
des Inhalts von XML-Dokumenten (XML-Entity)
• Auszeichnung mittels Tags
– Abgrenzung einzelne Abschnitte des Inhalts, dienen als Referenzen auf
Teile von Inhalt, können spezielle Anweisungen enthalten oder dienen als
Kommentar für Autoren
• ! >>Groß- und Kleinschreibung (case sensitivity) da viel Wert
auf Internationalisierung
• Zeichen: 16 bit und Unicode 2.1 Zeichensatz
– entspricht ISO/IEC 10646
Jena, 27.Mai 2004
Lutz Garstecki
Syntax: Namen und Bezeichner
• Fast alle Strukturen in XML tragen Namen
• Alle XML-Namen oder Bezeichner müssen
mit Buchstaben, Unterstrich (_) oder
Doppelpunkt (:) beginnen und
• Danach nur gültige Zeichen für Namen (name
characters), d.h. Ziffern, Bindestrich und
Punkt
• Doppelpunkt (:) sollte nicht benutzt werden,
nur als Trennsymbol bei Namensräumen
• Zeichen nicht mehr auf ASCII-Zeichensatz
beschränkt
• Erlaubt:
Auto, AUTO
• Nich gültig:
-Auto, 320BMW,
xmlData
• wieder gültig:
_320BMW,
_xmlData
– z.B. Umlaute usw. für Markup verwendbar
• Zeichenketten, die mit xml, XML, ...
beginnen nicht erlaubt
– solche Namen nur für W3C reserviert
Jena, 27.Mai 2004
Lutz Garstecki
Anatomie eines Dokuments
• Prolog (optional)
• Rumpf
– mehrere Elemente, die
miteinander baumartig
verschachtelt sind, können
beliebige character data
enthalten
• Epilog (optional)
– Kommentare,
Verarbeitungsanweisungen,
und/oder Leerstellen
Jena, 27.Mai 2004
Lutz Garstecki
Anatomie: Elemente
• Grundbausteine eines Dokuments
(andere Elemente, Zeichen,
Zeichenreferenzen, Entity-Referenzen, Verarbeitungsanweisungen, Kommentare
und/oder CDATA-Abschnitte) = element content
• Konzept: Element als „Container“
– Ausnahme: Kommentare, PIs, Leerstellen
• werden durch Tags begrenzt (aus Name des Elementtyps)
• Beginn mit Start-Tag und Ende mit End-Tag (zwingend)
• Bsp.: <Tagname> hier steht der Inhalt </Tagname>
Vorsicht! Namen müssen korrespondieren, Groß-/Kleinschreibung
• Leeres-Element-Tag: haben keinerlei Inhalt
– beispielsweise zum Hervorheben gewisser Stellen im Dokument
– z.Bsp. Datei-Ende-Kennung <EOF char=“1A“/> )
<Punkt_1></Punkt_1>
– oder abkürzende Mischform: <Punkt_1/>
Jena, 27.Mai 2004
Lutz Garstecki
Anatomie: Elementtypen
• Jedes XML-Dokument muss baumartige Struktur haben
• Jedes XML-Dokument darf nur einen Baum haben
– Ursprungsknoten = document entity oder document root
– darf PIs und/oder Kommentare enthalten
• document root muss TB enthalten, dessen Wurzel das
Dokument-Element ist
– Elternelement; darf in keinem anderen Element auftreten
– Wurzel des Element-Baums aber nicht document root
• Kind-Element: alle anderen Elemente im Dokument sind
Nachfahren (Kinder) vom Dokument-Element
– Eltern/Kind-Beziehung wichtiges Merkmal
• Jeder Elementtyp kann einen von 4 Inhaltstypen haben
– element content
– mixed content
Jena, 27.Mai 2004
– empty content
– character content
Lutz Garstecki
Anatomie: korrekte und falsche Schachtelung
• XML fordert strikt, dass Elemente korrekt geschachtelt sein
müssen
• Korrekte Schachtelung
– Beispiel: Buchtransport
zum Bücherladen
• ein echter Karton kann ein Buch
nicht nur zum Teil enthalten
• Buch kann nur in einem Karton
sein usw.
• Falsche Schachtelung
– Beispiel: überlappende HTML-Elemente
 in XML verboten
Jena, 27.Mai 2004
Lutz Garstecki
Text-Literale und Character Data
• Text-Literale dienen als Werte für Attribute, interne Entities
und externe Bezeichner
– müssen von Begrenzern ( ‘ oder “ ) umschlossen sein
• aber innerhalb der Literale darf jeweilige Begrenzer nicht auftauchen
• sollte man beide brauchen, muss das Zeichen mit entity reference
(&apos; bzw. &quot;) geschützt werden
•
Character Data: jeder Text, der nicht zum Markup gehört
– dass heißt: Inhalt von Elementen oder die Werte von Attributen
• aber: & und < dienen als Begrenzungssymbole für Markup
 dürfen nicht ungeschützt in Texten auftauchen
(Ausnahme: CDATA-Blöcke)
 Schutz durch Benutzen der Entities (&amp; bzw. &lt;)
Jena, 27.Mai 2004
Lutz Garstecki
Attribute in XML
• Oft will man Aussagen über den Inhalt von Elementen
machen (diese Infos sind aber nicht Teil des Inhalts selbst)
• Solche Informationen werden durch Attribute angegeben
Name = ‘Wert‘ bzw. Name = “Wert“
• Werte von Attributen sind immer Textliterale
– Achtung: in HTML auch numerische Werte zB. <IMG WIDTH=400 ...> oder
unklar begrenzte Werte zB. <P ALIGN=LEFT> erlaubt.
 in XML verboten !
• Inhalt eines Start-Tags oder eines Leere-Element-Tags
jeweils nur eine Instanz eines Attribut-Namens erlaubt!
– <img src=“bild01.jpg“ src=“alternativBild.jpg“ nicht erlaubt
• Deswegen vereinfachte Handhabung von Attributen durch
XML-Parser
Jena, 27.Mai 2004
Lutz Garstecki
Spezielle Attribute in XML
Zusätzlich:
•
Attribute mit festgelegter Bedeutung
- Weiterleiten von Mitteilungen an Applikation
•
Nutzung der Syntax von XML-Namensräumen (xml : eigentlicher Name)
xml:space (Darstellung)




Jena, 27.Mai 2004
Zur Beibehaltung von Text-Formatierungen
einschließlich aller Sonder- und Trennzeichen
Was Anwendung dann tatsächlich tut, ist abhängig
vom Programmierer
Attribut-Wert auf Element selbst und alle seine
Kinder angewendet
Bei validierendem Parser nur Werte >>preserve<<
und >>default<< (DTD)
Lutz Garstecki
Spezielle Attribute in XML (2)
xml:lang (bei internationalen XML-Dok.)





Jena, 27.Mai 2004
zur Internationalisierung
bei bidirektionalen semitischen Texten, Hinweise zur
Komposition asiatischer Schriftzeichen, lexikale
Sortierreihenfolge von Zeichen, Rechtschreibprüfung,...
Bei validierendem Parser muss Attribut in DTD deklariert
werden (wie alle anderen auch)
beschränkt auf: ISO 639 (zB. fr, ja),RFC 1766
benutzerdefinierte (ISO 3166)
Anwendung wie bei xml-space; auch hier Anwendung
nicht verpflichtet zur Auswertung oder Reaktion
Lutz Garstecki
Leerstellen und Trennzeichen (white spaces)
• Wichtiges linguistisches Konzept für
natürliche und normale Sprachen
• In XML werden nur 4 Zeichen als
Leerstellen bzw. Trennzeichen verwendet
• Regeln zur Handhabung sind sehr simpel:
– alle Leerräume innerhalb des Dokumentes vom
Parser beachtet und an Anwendung unverändert
weitergegeben
– Leeräume innerhalb von Tags und Werten von
Attributen entfernt
• Bearbeitung der Anwendung überlassen
Zeichencode(hex)/Beschreibung
09
10
0D
20
-
HT (horr.Tabulator)
LF (Zeilenvorschub)
CR (Wagenrücklauf)
Leerzeichen (ASCII)

Tabulatoren nicht zu
mehreren Leerzeichen
expandiert (also als ein
Zeichen behandelt)
– dass heißt, alle Behandlungen, die durch LF u./o.
CR impliziert wurden
Jena, 27.Mai 2004
Lutz Garstecki
Handhabung von Zeilenenden
• XML-Dokumente oft in Form einzelner Dateien abgespeichert
–
sie bestehen aus einzelnen „Zeilen“ Text
• Leerräume CR u. LF auch zur Markierung für Zeilenende
(wie im ASCII-Zeichensatz)
• 3 gängige Kombinationen dieser 2 Zeichen zur Markierierung
innerhalb von Dateien
–
–
–
CR und LF (DOS, Windows)
LF allein (UNIX)
CR allein (MacOS)
• Zur Erleichterung der Erstellung von XML-Applikationen
wandelt Parser jede Kombination in einfaches LF (line-feed)
um, dass heißt, XML erzwingt ein Zeilenende, wie es bei
UNIX üblich ist!
Jena, 27.Mai 2004
Lutz Garstecki
Zeichen- und Entity-Referenzen
Wie auch SGML und HTML bietet XML eine einfache Methode zur
Codierung von Zeichen, die nicht im ASCII-Zeichensatz enthalten sind.
• Zeichenreferenzen: als Ersatz für literale Form, wenn diese
die Spezifikation verletzen würde
– repräsentieren druckbare Zeichen u. bestehen aus dezimalen
oder hexadezimalen Zahlen, die &# oder &#x davor haben
– in XML hexadezimale Form bevorzugt, da Codierung in
Unicode auch hexadezimale Notation
• Beispiel:
&#169; oder &#xA9; im HTML-Browser
&#174; oder &#xAD; im HTML-Browser
Jena, 27.Mai 2004
©
®
Lutz Garstecki
Zeichen- und Entity-Referenzen (2)
• Entity-Referenzen erlauben es, beliebige Textliterale in
Elemente oder Attribut-Werte einzufügen oder bieten die
Möglichkeit, symbolische Namen (mnemonics) für
Zeichenreferenzen zu definieren
– &Name; wobei Name ein gültiger XML-Name sei muss
– 5 Entities als integraler Bestandteil von XML definiert
(zum Schutz der Symbole aus dem XML-Markup):
&amp;
&lt;
&gt;
&apos;
&quot;
• Beispiele:
- AT&amp;T = AT&T
- &quot;Jack&apos;s Auto&quot; = “Jack‘s Auto“
– Außer diesen müssen alle Entity-Referenzen in der DTD eines Dokuments
definiert werden, bevor man sie nutzen kann.
• Dabei kann DTD in separater Datei gespeichert =externe Teilmenge oder
im Dokument selbst stehen = als Teil der <!DOCTYPE...>-deklaration =
interne Teilmenge.
– Trifft Parser auf nichtdefinierte Referenz, wird Verarbeitung mit „fatal error“
abgebrochen!
Jena, 27.Mai 2004
Lutz Garstecki
Verarbeitungsanweisungen
• Verarbeitungsanweisungen (PIs) bieten Mechanismus, um mit
dem Dokument Hinweise an die Anwendung weiterzugeben
<? Ziel ... Anweisungen ... ?>
• Ziel der PI ist zwingend anzugeben, Name muss gültiger
XML-Name sein (zur Bezeichnung einer Anwendung an die sich die
Anweisungen richten)
• Anweisungen ist einfaches Text-Literal (außer: ?> alle Zeichen)
• Viele Diskussionen über:
– Nachteile
• Fehlende Unterstützung durch Browser
• Möglichkeit der Bildung inkompatibler Anweisungen durch Regelmangel für Definition
von Pis
– und Vorteile
• Schemataerweiterung
• Dukumenterweiterung ohne Änderung von Überprüfungsmechanismus durch DTD
• Einbettung von Anweisungen über Darstellung im Dokument selbst ohne Strukturänderung
Jena, 27.Mai 2004
Lutz Garstecki
Kommentare und CDATA-Blöcke
• Kommentare: zum Protokollieren der Entwicklung des
Dokuments oder jede andere Art von Metadaten, die für Autor
oder Leser wichtig sind, aber nicht zum Inhalt gehören.
– können überall stehen, außer innerhalb vom Markup
– im Kommentar, Entities nicht expandiert und Tags nicht interpretiert
<!-- ... Text des Kommentars...--> (belieb. Zeichen außer -- möglich)
• CDATA-Blöcke: Möglichkeit der Einbettung von Texten,
welche Zeichen enthalten, die sonst als Markup interpretiert
würden
– <![CDATA [ . . . ]]>
• „ . . . “ können beliebige Zeichenketten sein, außer Textliteral „ ]]>“
• aber: keine gute Möglichkeit zur Speicherung binärer Daten im Dokument
(Bytefolge „5D5D3E“ dürfte nicht enthalten sein)
Jena, 27.Mai 2004
Lutz Garstecki
Logische Struktur von Dokumenten
Prolog:
Jedes XML-Dokument beginnt mit Prolog - OPTIONAL
– Zeigt Beginn von XML-Daten an und beschreibt, welche Zeichenkodierung
verwendet wird oder beinhaltet andere Infos, die für Parser oder Anwendung
wichtig sind!
• XML-Deklaration
– Jedes Dokument darf und sollte mit einer einzelnen XML-Deklaration
beginnen!
– Wenn, dann als erstes im Dokument (keine Leerzeichen oder Kommentare
vorangestellt)!
– erlaubt Anwendung einiger Optimierungen bei der Verarbeitung:
<?xml version=“1.0“
XML-Version
obligatorisch
Jena, 27.Mai 2004
encoding=“UTF-8“
Codierung
optional
standalone=“yes“ ?>
yes or no
optional
Lutz Garstecki
Logische Struktur von Dokumenten
Prolog:
• Deklaration des Dokumenttyps (Nicht verwechseln mit DTD!)
– enthällt interne Teilmenge oder referenziert externe Teilmenge einer DTD
– jedes gültige XML-Dokument muss Deklaration des Dokumenttyps enthalten
• Einfache, nur wohlgeformte Dokumente brauchen keine, solange im
Dokument keine Entity-Referenzen außer 5 Standard-Entities auftauchen!
– Referenzen auf externe Teilmenge: Referenz mit Name als Einstiegspunkt
– Referenzen auf interne Teilmenge:
Entity-Referenzen müssen in interner
Teilmenge der DTD deklariert werden
– Deklaration erfolgt dann in Deklaration
des Dokumenttyps
(mit [...] drum)
!!! Definition interne Teilmenge hat Vorrang !!!
(Bei Überschneidung von interner und externer Teilmenge!)
Jena, 27.Mai 2004
Lutz Garstecki
Logische Struktur von Dokumenten
Epilog:
• kann Kommentare, PIs und/oder Leerzeichen enthalten
• Tim Bray: „Der Epilog in XML ist ein echter Designfehler“

nicht ohne driftigen Grund einen Epilog schreiben
denn: XML-Dokument besitzt keine speziellen Kennzeichen für
Dokumentende
• viele XML-Anwendungen nehmen den End-Tag des
Dokument-Elements als Ende
– Epilog könnte ignoriert werden (anwendungsspezifisch)
– Verarbeitungsanweisungen zwischen 2 Dokumenten
können allenfalls mehrdeutig sein
Jena, 27.Mai 2004
Lutz Garstecki
Ein wohlgeformtes XML-Dokument
• ... ist ein XML-Dokument, das der Spezifikation und der darin
festgelegten Syntax entspricht
• auch ohne DTD oder Schema, welches die Struktur beschreibt
 „standalone document“
– können sich dann aber nicht auf externe Deklaration stützen
– Attributwerte werden nicht besonders behandelt und bekommen keine
Default-Werte zugewiesen
• Eigenschaften:
- korrekte Schachtelung der Elemente
- alle Elemente zusammen bilden einfachen Elementbaum
- einzige direkte Relation zwischen 2 Elementen ist
Kind-/Eltern-Beziehung
• Wenn Parser Konstrukt entdeckt, dass Bedingung der
„Wohlgeformtheit“ widerspricht  „fatal error“ an die Anwendung
Jena, 27.Mai 2004
Lutz Garstecki
XML-Parser
• 2 Typen von XML-Prozessoren (Parser)
- nicht validierend
- validierend
(Prüfung nur auf Wohlgeformtheit)
(verwendet auch DTDs, um zu prüfen, ob
Dokument in Form und Inhalt „gültig“ ist)
• Um Handhabung der XML-Daten aus Anwendung heraus
zu erleichtern (z.Bsp. Symbole, die Zeilenende oder Dateiende
markeieren, sind abhängig vom Betriebssystem  Parser reduziert
alle Markierungen für Zeilenende auf LF; Weitergabe aller
Leerzeichen an Anwendung; Auflösung aller Zeichenreferenzen, sowie
sie in interner oder externer Deklaration definiert sind; Normalisierung
aller Attributwerte vor Weitergabe an Anwendung)
• 2 Ansätze, Parser zu definieren
– ereignisgesteuert, baumorientiert - wobei beide ihre Vorteile haben
Jena, 27.Mai 2004
Ende
Lutz Garstecki