So, schönen guten Tag.
Ich begrüße Sie zu einer weiteren Fortsetzung von Angewandter
Informatik 2.
Wir haben uns letztes Mal beschäftigt mit der Beschreibung von
Dokumenten.
Ich hatte Ihnen zunächst noch etwas über HTML erzählt, dann habe ich
angefangen, Ihnen etwas über XML zu erzählen.
Und dazu haben wir dann zunächst mal gesehen, dass es bei XML sehr
wichtig ist, dass man die Struktur von der Präsentation trennt.
Das heißt, wir haben einmal das XML-Dokument, in dem die Struktur
angegeben ist.
Und wir haben dann, das war hier dieser Bereich, der Inhalt.
Und je nachdem, wo ich es präsentieren möchte, auf welchem Medium,
kann ich dann über ein Style-Sheet, beziehungsweise eine .xsl-Datei,
unterschiedliche Präsentationsobjekte erzeugen.
Auf dem Drucker, auf dem Handy oder auf irgendeiner Webseite.
Das sind also die verschiedenen Möglichkeiten.
Ich hatte Ihnen kurze Beispiele genannt, um die Struktur nochmal
darzulegen.
Im Prinzip kennen Sie bereits diese Art der Notation, so eine Markup
-Language mit Tags.
Und das habe ich bei Ihnen bei SGML schon gezeigt.
Wir haben das bei HTML nochmal gesehen, in einer speziellen SGML
-Sprache.
Und jetzt kommt halt hier das XML.
Und da habe ich Ihnen so ein paar Beispiele schon genannt.
Ich habe Ihnen gesagt, dass man zunächst mal schauen muss, also warum
macht man überhaupt so etwas?
Ich will natürlich dann ein solches Dokument vernünftig bearbeiten
können.
Das heißt, ich will mit einem Programm feststellen können, ob ein
Dokument auch bestimmten Anforderungen entspricht.
Denn dann kann ich entsprechend den Vorgaben auch mit dem Dokument
weiterarbeiten.
Und deswegen muss man zunächst mal sehen, ist das Ganze wohlgeformt?
Ist es richtig aufgebaut?
Das entspricht dem, dass wir bei formalen Sprachen schauen, ob die
Regeln der Grammatik eingehalten sind, ob ein Wort zu einer Sprache
gehört.
Bei der Wohlgeformtheit guckt man erstmal bezüglich von Regeln einer
sehr einfachen Grammatik.
Und dann kann man halt auch noch speziellere Grammatiken sich
anschauen, indem man diese speziellen DTDs, Document Type Definitions,
sich hernimmt und dort nachschaut, welche zusätzlichen Regeln der
Nutzer definiert hat.
Und diese Regeln müssen dann halt auch in dem Dokument eingehalten
sein.
Dann habe ich hier die Möglichkeit, also zum Beispiel bei einer
solchen DTD, könnte man dann feststellen, ob ein Dokument tatsächlich
gültig ist.
Und dazu muss man halt bestimmte, oder muss man wissen, wie man
Elemente deklariert, also wie man so eine DTD aufbaut, ein Dokumenten
Typ Definition.
Und man kann dann halt, wie gesagt, feststellen, ist ein Dokument
gültig?
Das entspricht bei Programmiersprachen der syntaktischen, oder der
Überprüfung der syntaktischen Korrektheit eines Programms.
Ist ein Programm tatsächlich in Java geschrieben?
Dann kann ich das auch übersetzen in ein maschinenausführbares
Programm, also Maschinensprache oder Assembler-Sprache oder was immer
die nächste Stufe ist.
Oder bei Java wäre es ja der Bytecode.
Und wenn das Programm gar nicht diesen Regeln entspricht, kann ich
auch nichts übersetzen.
Insofern ist das genau das Gleiche, was man hier macht.
Wenn ich mit einem Dokument was anfangen will, muss es den Regeln der
Dokumenten Typ Definition entsprechen, die vorgegeben ist und dann
kann ich damit tatsächlich etwas anfangen.
Ich hatte Ihnen hier das Beispiel gezeigt mit einem einfachen Namen
Tag mit einer gewissen Struktur und hatte gezeigt, dass man das auch
anders machen kann, indem man Attribute verwendet.
Dann hätte man also einfach das Gleiche hier über Attribute gemacht,
also unterschiedliche Möglichkeiten, so ein Dokument zu strukturieren.
Hier war das einfache Beispiel einer Kundenliste, auch das hatte ich
Ihnen erläutert, was hier alles drin ist.
Hier oben war also das Beispiel des Dokuments und unten drunter die
Dokumenten Typ Definition, ein Beispiel für so eine DTD.
Und wir hatten uns das kurz angeschaut, ich hatte erläutert, was dort
die einzelnen Elemente bedeuten und Sie haben das hier nochmal
gesehen.
Man kann also das Beispiel, das ich gerade eben genannt hatte, in zwei
verschiedenen Arten verwenden.
Einmal getrennt, eine XML-Datei und eine DTD-Datei, in der also diese
Dokumenten Typ Definition getrennt vom Dokument gespeichert ist, was
immer dann Sinn macht, wenn man viele Dokumente mit einem bestimmten
Dokumententyp machen will.
Wenn man in einem Dokument nur bestimmte Regeln haben möchte, die
beachtet werden sollten, dann macht das durchaus auch Sinn, die
Dokumenten Typ Definition einzubetten in das XML-Dokument.
Der Parser, der das dann anschaut, der verarbeitet dann diese
Definition und wird die entsprechend verwenden bei der Überprüfung des
Dokuments auf Gültigkeit.
Das wäre so ähnlich, als wenn Sie bei einem Programm, das Sie
schreiben, zunächst mal vorne drin die Grammatik hinschreiben, nach
der Sie Ihre Anweisungen in dem Programm aufschreiben.
Sowas haben wir normalerweise im Programmieren nicht, könnte man sich
aber durchaus auch vorstellen, dass jeder im Prinzip eine beliebige
Programmiersprache haben kann, der muss nur vorne angeben, nach
welchen Regeln er die Anweisungen aufschreibt, dann kann ein Parser
damit tatsächlich auch umgehen.
Genauso haben wir das hier bei XML.
Jetzt haben wir hier eine kurze Gegenüberstellung von XML und HTML.
Da sieht man, dass allein bei der Strukturierung des Dokuments bereits
bestimmte Dinge deutlich werden, die bei HTML eigentlich nicht
vorhanden sind.
Hier bei HTML haben wir einfach nur Strukturierungen, die sich über
das P hier auf die einzelnen Paragraphen beziehen.
Das hat inhaltlich keine Aussage, was dort tatsächlich zwischen diesen
P -Tags steht.
Während wir bei XML überhaupt keine P-Tags hinschreiben, das hat mit
Präsentation zunächst mal gar nichts zu tun, sondern wir schreiben
hier nur hin Tags, die sich auf die Inhalte beziehen, die zwischen
diesen Tags stehen sollen.
Also zum Beispiel bei Ort soll halt ein Name stehen für einen Ort als
Attribut.
Oder bei Himmel soll dazwischenstehen irgendeine Eigenschaft des
Himmels, bewölkt, heiter oder was immer.
Oder bei das Tag Temp soll halt für Temperatur stehen oder müsste
dazwischen auch eine Temperatur stehen.
Das heißt, hier deutet man an eine gewisse Semantik, die man mit dem
Inhalt oder mit den Zeichenketten verbirgt, die dann daneben stehen.
Was wir bei der Definition natürlich gar nicht genau angeben können,
bei der Dokumententyp-Definition wird ja so ein Tag, wie meinetwegen
hier dieses Temp, einfach nur so angegeben, dass dazwischen
irgendwelche Character Data stehen.
Also eine Folge von Zeichen, von Characters, ohne dass wir dabei
angeben können, das muss jetzt eine Temperatur sein.
Das ist etwas, wenn man das haben will, muss man ein bisschen
komplexere Datentypen haben.
Dazu werden wir heute noch kommen.
Dass man also auch komplexere Datentypen angeben kann, als nur einfach
zu sagen Character Data oder Past Character Data.
Also, wir können durch die Tags durchaus mehr Struktur und auch ein
bisschen Bedeutungsinformation reinbringen in ein Dokument, sodass
jemand, der dieses XML-Dokument anschaut, bereits einen gewissen
Eindruck von der Struktur hat, ein menschlicher Leser.
Für die Präsentation des Dokuments sagt das erstmal noch gar nichts.
Das ist noch ein völlig anderes Thema, auf das wir heute gar nicht
mehr kommen werden.
Das hat dann was zu tun mit den Extended Style Sheets, die die
Präsentation tatsächlich festnehmen.
Ein weiteres Beispiel war hier, dass man Formeln darstellen kann.
Wenn Sie sich überlegen, wie Sie in HTML eine Formel darstellen, da
gab es ja nur so minimale Möglichkeiten, etwas Formel-ähnliches zu
machen, wie dass man zum Beispiel so ein Superscript für eine Zahl,
das konnte man durchaus machen, dass man eine Zahl nach oben schreibt
als Superscript oder nach unten als Subscript, als Index.
Das ging durchaus.
Aber eine Formel wie die, die hier angegeben ist, das geht in HTML so
direkt nicht, weil das halt deutlich über die
Formatierungsmöglichkeiten üblicherweise hinausgeht.
Wenn Sie solche Formeln dort einbetten wollen in HTML, da können Sie
zum Beispiel mit GIFs, also mit einfachen Bildern arbeiten.
Das heißt, Sie haben dann aber auch nur eine Bildinformation und keine
Inhaltsinformation.
In XML können Sie über die MathML tatsächlich solche Formeln
definieren und können die dann in einer Art, die noch festzulegen ist,
über ein Style Sheet, tatsächlich auch präsentieren.
Das heißt, hier haben wir mit XML die Möglichkeit über diese MathML.
MathML ist also eine Dokumententypdefinition, wobei in dem Fall MathML
über ein Schema definiert wird mit komplexeren Datentypen.
Da kann man halt Tags verwenden, die etwas zu tun haben mit dem Aufbau
von Formeln.
Und das jetzt aus dem, was hier links steht, die Formel rechts
entstanden ist, das sieht man natürlich nicht an den Tags, die hier
stehen.
Betone jetzt nochmal, die Präsentation ist etwas, was man erst über
das Style Sheet macht, über eine getrennte XSL-Datei, Transformation
aus der Struktur in irgendetwas, was präsentiert werden soll.
Ich hatte dann letztes Mal, ich glaube das war meine letzte Folie,
darauf hingewiesen, dass wir natürlich als Hintergrund haben unser
Anwendungsbereich E-Commerce, also elektronische Geschäftsbeziehungen.
Da hatten wir EDI kennengelernt.
EDI ist natürlich nach wie vor ein wichtiger Bereich.
Aber wir hatten die ganzen Defizite von EDI uns angeschaut, die
Schwächen identifiziert, festgestellt, heutigen Anforderungen wird das
eigentlich in Bezug auf die Strukturierungsmöglichkeiten der Dokumente
nicht so richtig gerecht.
Und deswegen brauchten wir etwas Flexibleres.
XML ist flexibler und kann deswegen für den elektronischen
Dokumentenaustausch eingesetzt werden und löst inzwischen eben auch
die alten EDI-Standards ab.
Hier steht IB-XML, es gibt also eine XML-Variante, ein Dokumententyp,
der speziell Tags enthält für den elektronischen Handel.
Und dann kann man also zum Beispiel eine EDIFAKT-Nachricht überführen
in eine XML-Nachricht, die mit anderen Tags arbeitet.
Etwas lesbarer für den Menschen, wobei ich das auch oft genug betont
habe, dass der Mensch so ein Dokument lesen kann, sowohl bei EDIFAKT
als auch bei XML ist zunächst mal nebensächlich, höchstens wenn es um
die Erstellung der Dokumente geht, also um diejenigen geht, die
Autoren sind solche Dokumente, die wollen natürlich auch das, was sie
schreiben, besser verstehen können.
Aber für die Präsentation hat weder EDIFAKT etwas zu tun, noch XML
direkt.
Trotzdem ist es wichtig, auch wenn Sie ein Programm schreiben, dass
man so ein Programm lesen kann.
Sie wissen alle, dass ein Programm wie C leider für einen Laien nicht
sofort lesbar ist.
Deswegen ist es eigentlich eine ganz schreckliche Sprache, weil das
eine kryptische Sprache ist, die nur jemand versteht, der sich lange
mit C beschäftigt hat.
Das ist bei Java ähnlich.
Es gibt andere Sprachen, die sind sofort lesbar für jeden, der
einigermaßen Sprachverständnis hat.
Bei anderen Sprachen wie COBOL oder ALGOL oder PASCAL werden
sprechende Begriffe verwendet und nicht irgendwelche kryptischen
Abkürzungen.
Und das ist genau das, was man hier bei XML eben auch macht, dass man
Tags verwendet, die sprechend sind, indem sie eine Bedeutung schon
suggerieren, sodass ich beim Erstellen des Dokuments bereits mich
anhand dieser Tags orientieren kann und sinnvolle Sachen reinschreibe,
was dann eben auch das Überarbeiten dieser ganzen Dokumente deutlich
erleichtert.
Und diesen Gesichtspunkt muss man natürlich als Informatiker immer
drin haben.
Es geht ja darum, dass ich nicht nur sehe, was wird erzeugt aus diesen
Dokumenten, sondern wie erstelle ich die Dokumente und dafür müssen
sie eben auch vernünftig lesbar sein für den Entwickler.
So, jetzt kommt die erste neue Folie.
Ein Thema, das ganz wichtig ist.
Wenn wir eine Vielzahl von Dokumenten haben, die wir aufschreiben,
dann können Namenskonflikte auftreten.
Was sind Namenskonflikte?
Ich habe hier ein kleines Beispiel angegeben für solche
Namenskonflikte.
Das ist wirklich sehr schnell beschrieben, worum es darum geht.
Ich will ein Dokument beschreiben, in dem als Inhalt ein Buch
vorkommt.
Wenn ich so ein Buch beschreibe, was kommen da alles für Tags vor?
Nun, es kommt hier vor ein Tag Titel.
Dann denken wir alle, okay, da steht hier jetzt Internetalgorithmen.
Und dann, es gibt ein Buch, es gibt einen Titel, es gibt einen Autor.
So einen Tag haben wir hier auch.
Und ein Autor, der hat, hier steht also ein Tag Name und Adresse.
Sicherlich auch sinnvoll.
Und als Name steht dann hier, da steht jetzt irgendwas, schmeckt
Hartmut Professor Doktor, da steht hier nochmal ein Titel.
Was ist denn eigentlich, hier haben wir zweimal ein Tag Titel.
Das ist selbstverständlich wohl geformt, überhaupt kein Problem.
Und könnte auch problemlos über eine DTD so definiert werden.
Würde keinen Fehler verursachen.
Aber von der Bedeutung her ist natürlich hier etwas völlig anderes.
Hier ist ein Titel gemeint als ein Bestandteil eines Namens, im
unteren Teil.
Und im oberen Bereich hier, da ist der Titel eines Buches.
Und das, was hier deutlich wird, ist, dass hier ein Tag verwendet
wird, eigentlich in unterschiedlichen Zusammenhängen.
Einmal haben wir den Zusammenhang innerhalb dieses Elements Name
Adresse oder Name Adresse oder das andere Mal haben wir den Titel
innerhalb unseres Tags Buch.
Und das wird sicherlich zu gewissen Konflikten führen, wenn man solche
Dinge einfach so sich anschaut.
Sie kennen auch das aus Programmiersprachen.
Wenn Sie Variablen deklarieren, dann können Sie das durchaus
geschachtelt machen.
Sie haben hier irgendein größeres Programm oder Dokument und Sie haben
hier irgendeinen Namen A.
Dann können Sie durchaus hier unten drin das A nochmal deklarieren,
innerhalb einer Prozedur oder Methode.
Und eine Referenz auf A hier unten drin, bezieht sich dann nur auf
dieses A und nicht auf das A dort oben.
Und ein A, was hier unten steht, wird sich immer auf das A beziehen
und nicht auf das A, was dort drin in diesem eingeschachtelten Bereich
steht.
Das kennen wir also alles aus anderen Bereichen, die Namensbereiche in
Programmiersprachen, die erlauben uns all das, dass wir lokal durchaus
die gleiche Variable nochmal verwenden, aber sie ist dann ja auch nur
lokal gültig und ein globaler Name, der identisch aussieht, wird nicht
dabei angesprochen, weil der in einem anderen Bereich liegt.
Und dieses Unterscheiden der Bedeutungsbereiche, der
Gültigkeitsbereiche für Namen, das macht man in XML mit etwas, was man
Namensräume nennt.
Jetzt muss ich das hier mal kurz wegwischen, damit wir das besser
lesen können.
Das war unser Beispiel gewesen.
Hier haben wir ein A, da haben wir ein A und wenn das hier auftaucht
oder da auftaucht, haben wir unterschiedliche Bezüge zu den
verschiedenen Definitionen.
Das gleiche wollen wir hier erreichen und das erreicht man in XML
durch sogenannte Namespaces.
Was ist ein Namespace?
Ein Namespace ist eine Bezeichnung eines Bereiches, in dem ein
bestimmter Name gültig ist.
Und das wird jetzt in XML in verschiedenster Weise gemacht.
Hier ist das gleiche Beispiel, was links steht, in etwas anderer Form
beschrieben.
Hier haben wir eingefügt die Definition von Namespaces.
XML Namespace, also XMLNS abgekürzt.
Da steht hier Book gleich und Address gleich.
Und rechts daneben stehen zwei URLs oder URIs, also eindeutige
Bezeichnungen, eindeutige Namen.
Und wenn ich jetzt irgendwo unten drunter ein Element verwende, dann
schreibe ich das hier mit dem Präfix Book.
Und dann bezieht sich diese Verwendung von Titel auf den Namespace
http://www.w3.org Books.
Und wenn wir hier unten Titel verwenden, da steht es nicht mehr
einfach Titel, sondern da steht Address.titel.
Dann ist das ein anderer Tag, der bezieht sich auf den Namespace hier
oben www.iso.org Address.
Und damit habe ich diese beiden Titel-Tags voneinander getrennt.
Und Sie sehen, dass diese Tags jetzt alle etwas länger geworden sind.
Die enthalten jetzt ein Präfix und ein Suffix, getrennt durch einen
Doppelpunkt.
Und im Prinzip sind in XML alle Elemente, die vorkommen, alle Tags
immer so aufgebaut.
Wenn dieser erste Teil nicht vorkommt, wie wir das hier auf dieser
Seite gemacht haben, dann wird implizit ein Präfix verwendet.
Dann wird angenommen, dass die alle zum gleichen Namensraum gehören,
diese Elemente.
Und wenn ich Konflikte habe bei der Bezeichnung von Elementen, dann
verwende ich solche Namespaces, weil ich die dann nämlich eindeutig
machen kann.
Und dann kann ich also dafür sorgen, dass der Parser genau feststellen
kann, aha, hier unten drunter, wenn hier ein Name steht, dann ist das
ein Nameelement innerhalb des Namensraums, in dem Adressen definiert
werden.
Und auf diese Art und Weise kann man also Namen für Elemente oder
Attribute in XML-Dokumenten verwalten und dafür sorgen, dass ich dort
keine Überschneidungen kriege.
Es ist ganz wichtig, wenn Sie zum Beispiel in verteilter Art und Weise
Dokumente erstellen, was der Standard ist in irgendwelchen größeren
Anwendungen, Sie haben riesige Webauftritte oder Sie haben große
Bereiche, große Dokumentenmengen, die in unterschiedlichsten
Arbeitsgruppen erstellt werden, wenn Sie erstmal abstimmen müssten
unter all diesen verschiedenen Mitwirkenden bei der Erstellung einer
großen Dokumentensammlung, dass die verwendeten Elemente alle
unterschiedlich sind.
Damit es keine Konflikte gibt, wäre das viel zu umständlich.
Es ist viel einfacher für jeden, der ein Dokument erstellt, einfach
einen Namensraum anzugeben und innerhalb dieses Namensraums ist dann
alles eindeutig.
Und damit muss ich nur wissen, wenn ein anderer so einen Tag
verwendet, wie die Namensräume alle heißen.
Sofern ich ein Element eines anderen Namensraums verwenden will.
Das heißt, ich kann auf diese Art und Weise durch die Verwendung von
Namespaces dafür sorgen, dass das, was in meinem Dokument neu
definiert wird, nur in meinem Dokument gültig ist und der Parser das
eindeutig identifizieren kann.
Warum geht es?
Der Parser muss eindeutig identifizieren können, was das für ein Tag
ist, damit man damit später auch sinnvoll weiterarbeiten kann.
Also hier ist es ein ganz einfaches Beispiel.
Das diente nur dazu und zu zeigen, dass ich auf diese Art und Weise
diese unterschiedlichen Namenskonventionen oder Tag
-Benennungskonventionen für Beispiel Buch und Adresse voneinander
trennen kann.
Und damit habe ich die Konflikte beseitigt.
Kurze Erläuterung noch dazu.
Namen in XML bestehen also immer aus zwei Teilen.
Ich habe so einen eindeutigen Präfix und einen Namen dahinter.
Das kann eben sein, dass ich, wobei ich hier in dem Fall
Anführungszeichen dazuschreiben sollte, der eindeutige Präfix könnte
also eine URL sein oder ein Uniform Resource Identifier, URI.
Und dann steht dahinter dieser eigentliche Name Titel.
Und das, was vorne steht und das, was rechts steht, darf keinen
Doppelpunkt enthalten.
Deswegen muss das hier links in Anführungszeichen stehen, um
anzudeuten, dass hier der Doppelpunkt nicht ein Trennsymbol ist, um
Präfix und Namen zu trennen.
Also zwischen dem eindeutigen Präfix und dem Namen steht immer ein
Doppelpunkt.
Da komme ich gleich auch nochmal zu.
Also wie gesagt, das ist der Präfix, der dafür sorgt, dass die Namen,
die ich verwende, alle eindeutig sind.
Ich habe also als Präfix einen eindeutig gegebenen Namensraum.
Der muss für mein Dokument eindeutig sein.
Da kann ich also irgendeinen Namen hinschreiben.
Man nimmt zur Vereinfachung da häufig irgendwelche URLs oder URIs.
Und das sollte ich hier vielleicht mal wegklicken.
Und jetzt haben wir also diese Darstellung der Namen.
Ich glaube, das ist deutlich geworden.
Wenn sich ein Dokument explizit auf eine DTD bezieht, also ich kann ja
in der Titelzeile eines XML-Dokuments angeben, welche DTD zugrunde
liegt, dann habe ich damit einen Bezug auf den Namensraum.
Und ich muss den Namensraum nicht explizit aufschreiben in dem XML
-Dokument.
Wenn ich ihn also nicht explizit benenne, wird er implizit durch die
Angabe der DTD vom Parser verwendet.
Dann habe ich aber nur diesen einen Namensraum.
Wenn ich mehrere verschiedene haben will, dann muss ich die explizit
einsetzen.
Also, wie gesagt, ich kann sie, die Namensräume, definieren, indem ich
zu Anfang im Dokument, also oben im Dokument einfach diese Anweisung,
also hier diese XML-S gleich Anweisung, wenn ich die hier oben
irgendwo reinschreibe oder an irgendeiner Stelle, dann wird von dort
an oder in dem Bereich, der unterhalb dieses Knotens im XML-Baum
liegt, jedes XML-Dokument ist ja im Prinzip irgendeine Baumstruktur.
Und wenn ich an irgendeiner Stelle einen Namensraum definiere, auf die
Art und Weise, wie das hier angegeben ist, dann gilt unterhalb dieses
Knotens, also in dem Bereich, würde dann dieser Namensraum gelten.
Auch wieder implizit.
Bei dem Beispiel, das ich gerade genannt hatte, hatte ich eine andere
Definition verwendet.
Da hatte ich das so gemacht wie hier.
Book gleich.
Und da stand dort irgendeine URL.
In dem Fall kann ich durch explizite Verwendung des Präfixes book
andeuten, auf welchen Namensraum ich mich beziehe.
Das heißt, dann kann ich genau sagen, ich kann jetzt also hier innen
drin, da kann ich jetzt unterschiedliche Namensräume ansprechen,
einfach durch Verwendung dieses Namens, den ich bei der Definition des
Namensraumes verwendet habe.
Book oder, Sie erinnern sich, address.
Das ist etwas, was Sie aus Programmiersprachen so, also aus den
Standardprogrammiersprachen nicht kennen, dass Sie irgendeinen Präfix
mit einem Präfix auf unterschiedliche Sachen zugreifen können.
So ein bisschen gibt es das da, wenn Sie auf Teile eines Objekts
zugreifen, da können Sie also auf die Attribute auch im Prinzip über
diese geschachtelte Struktur zugreifen.
Da haben Sie ja auch die Möglichkeiten, irgendwelche Namen oder einen
Punkt, irgendeinen Namen und so weiter, wenn Sie so eine geschachtelte
Struktur haben mit Attributen da drin, können Sie auch auf die Art und
Weise etwas bezeichnen.
Also es sind Ähnlichkeiten da.
Und ich finde es einfach wichtig, darauf hinzuweisen, dass eigentlich
das, was wir machen hier bei den Dokumenten, etwas ist, was wir aus
anderen Bereichen durchaus kennen beim Programmieren.
Da gibt es bestimmte Konventionen und hier hat man zum Teil ein
bisschen andere Sachen sich noch überlegt, weil sie einfach gebraucht
werden, um mit der erforderlichen Flexibilität solche Dokumente
formulieren zu können.
Gut, noch ein Begriff, Q-Name, Qualified Name und NC-Name, Not No
Colon Name, sind zwei Begriffe, die man in diesem Zusammenhang
braucht.
Ich hatte doch eben gesagt, jeder Name besteht aus so einem Präfix und
einem dann dem Namen dahinter.
Das heißt, hier ist nochmal dieser Prefix und Local Name angegeben und
Prefix und Local Name sind jeweils NC-Names, das heißt No Colon Names,
ein Bezeichner, der keinen Doppelpunkt enthält.
Wenn also der Präfix eine URL ist, dann muss diese URL in
entsprechenden Anführungszeichen eingeschlossen sein.
Und damit haben wir jetzt, also als hier diese typischen Beispiele,
XSD wäre also ein solcher Präfix, der definiert ist als Name eines
Namensraumes und dahinter könnte jetzt Integer stehen, sofern Integer
ein Name ist, der innerhalb dieses Namensraumes bekannt ist.
Oder definiert worden ist.
Und AIFB Doppelpunkt MBO wäre auch ein möglicher Qualified Name.
Präfix wäre AIFB und dahinter steht halt MBO.
Also was Sie für einen Präfix verwenden, ist völlig beliebig.
Man muss nur gewährleisten, dass für die Dokumente, in denen dieser
Präfix vorkommt, der auch eindeutig ist.
Wenn der gleiche Präfix in verschiedenen Dokumenten verwendet wird,
wird das natürlich schlecht.
Also versucht man dort Namen zu nehmen für den Präfix, der garantiert
eindeutig ist.
Und über die URLs hat man solche eindeutigen Namen, deswegen nimmt man
häufig solche URLs.
Beispiele gibt es eine ganze Reihe, hier sind welche genannt.
Also Sie können an vielen Stellen Beispiele für solche Namen finden,
wo Sie immer nachschauen können, ist in self.html oder in den XML
Standards.
Da will ich jetzt gar nicht reingehen in dem Fall.
Schauen wir uns nochmal an, wie man solche Namensräume verwendet.
Einmal, wie gesagt, geht es so, dass man innerhalb eines Tags, hier
habe ich das Buch-Tag, verwende ich hier mein Attribut xmlns und gebe
hier den Namensraum an, dann bezieht sich der Namensraum auf dieses
und auf alle eingeschlossenen Elemente.
Also innerhalb des Tags Buch, irgendwann kommt ja hier hinter noch das
Tag Ende, Buch und alles dazwischen, da würde dieser Namensraum
gelten.
Gut, ich habe dadurch eine hierarchische Schachtelung von
Namensräumen, hatte ich auch schon angedeutet, damit kann ich also
solche Namensräume ineinander einbetten und ich kann aber eben auch
mehrere Namensräume zu Beginn eines Dokuments definieren, wie ich das
in dem Beispiel auch gemacht hatte durch Book und Address, kann ich
innerhalb des Dokuments jeweils genau angeben, auf welchen Namensraum
ich mich beziehe.
Wenn ich das machen will, muss ich eben explizit diese qualifizierten
Namen verwenden, weil ich hier nicht implizit darauf vertrauen kann,
welcher Namespace gemeint ist.
Was ich Ihnen jetzt präsentiert habe, das waren ein paar Beispiele,
wie man XML-Dokumente definiert durch eine DTD, also Dokumententyp
-Definitionen.
Und das ist so etwas Ähnliches wie das, was wir ja auch gesehen haben
bei EDI.
Da gab es unterschiedliche Konventionen für die Formulierung von EDI
-Nachrichten, bezogen auf unterschiedlichste Bereiche der Industrie.
Das war etwas, das waren sogenannte vertikale Standards, Automotive
-Bereich.
Ich kann noch weiter oben anfangen.
Es gibt individuelle oder interne Formate.
Ich kann also individuell spezifizieren für ein spezielles Dokument,
welche Struktur das haben soll.
Jetzt werden sich bestimmte Leute zusammentun und sagen, im Bereich
der chemischen Industrie sollen bestimmte Dokumenttypen verwendet
werden.
Dann einigt man sich auf eine Dokumententyp-Definition für Dokumente,
die in einem bestimmten Bereich der chemischen Industrie verwendet
werden.
Oder im Papinet, was immer das für Bereiche sind, Bereiche der
Industrie, in denen man für einen bestimmten Anwendungsbereich
Dokumente festlegt.
Im Bereich E-Learning gibt es dann solche Sprache.
Dann gibt es horizontale Anwendungen, die quer über Anwendungsbereiche
hinausgehen.
Da habe ich also sowas wie BizTalk oder XMI oder ECML oder SMIL.
Das sind Techniken oder das sind Konventionen, die in
unterschiedlichsten Bereichen eine Rolle spielen.
MathML zum Beispiel.
Formeln brauche ich in verschiedensten Bereichen.
Ich kann definieren, wie man Formeln spezifiziert und kann das dann in
unterschiedlichsten Bereichen einsetzen.
Das wären sogenannte horizontale Anwendungen.
Da habe ich also einmal die vertikalen Standards, die für bestimmte
Anwendungsbereiche gelten sollen.
Und horizontal dazu habe ich Standards, die in verschiedenen Bereichen
eingesetzt werden können.
Unten drunter steht natürlich irgendwo XML.
Und etwas, was wir uns noch nicht genau angeguckt haben, das ist das
hier, was ich jetzt gerade einrahme.
Das schauen wir uns gleich noch an.
Einrahmen soll nicht bedeuten, dass ich das weglasse, sondern das ist
ganz wichtig.
Damit ich aus einem XML-Dokument tatsächlich die Präsentationen, die
unterschiedlichsten Arten der Darstellung erzeugen kann, muss ich ja
irgendwann auf XSL kommen, die Extended Style Sheet Language.
Ich muss ein XML-Dokument transformieren in verschiedene
Darstellungen.
Und das heißt, ich muss dafür auch entsprechende Möglichkeiten haben,
auszudrücken, wie ich ein XML-Dokument transformiere in ein
entsprechendes z.B.
HTML-Dokument.
Und dafür gibt es eine ganze Reihe weiterer Erweiterungen von XML.
Das erste wäre XML-Schema, mit dem wir uns gleich beschäftigen.
Dann eine alternative Definition, die Struktur von Dokumenten
festzulegen.
Also etwas, was über die Möglichkeiten von DTDs hinausgeht.
Dann gibt es hier DOM und SAX, bestimmte Standards, um auch wieder
solche XML-Dokumente für bestimmte Bereiche zu erweitern.
Formatting Objects, XHTML.
Heutzutage, wenn Sie sich eine HTML-Seite anschauen, werden Sie
meistens XHTML oder sehr häufig XHTML-Seiten finden.
Und immer weniger HTML-Seiten, weil man mit den XHTML-Seiten halt mehr
machen kann, als mit den alten HTML-Seiten.
Da ist also HTML-Prinzip neu definiert worden in XML-Notationen.
Und dann haben wir hier auch noch Dinge wie XPath und XLink und
XPointer und eben XSLT.
XSL, Extended Style Sheet Language, T für Transformer.
Und das müssen wir uns jetzt alles noch anschauen, um den Weg
tatsächlich gehen zu können von einem XML-Dokument zu einer
Präsentation des XML-Dokuments, zum Beispiel im Webbrowser.
Diese Dinge hier unten sind sogenannte Kernstandards.
Das steht hier nochmal.
Und oben drüber, da haben wir dann Erweiterungen für verschiedene
Anwendungsbereiche.
Aber anders als das bei Edifact war, da hatte ich ja diese großen
Verzeichnisse, die auf diesen Webseiten bei den Vereinten Nationen
dort abgelegt waren, wo sehr genau angegeben war, welche Werte dort
verwendet werden durften, in einer Form, die eigentlich nicht
maschinenlesbar war, habe ich hier alles in einer maschinenlesbaren
Form.
Das ist alles in XML-Standards geschrieben und ich kann also hier ein
Dokument lesen mit einem XML-Parser und kann aus den Informationen,
die in dem Dokument drinstehen, alle weiteren relevanten Informationen
tatsächlich erhalten, durch die Referenzen auf eine DTD oder auf ein
Schema und auch auf die entsprechenden Präsentationsrichtlinien, die
durch XSLT dann auch gegeben sind.
Also hier habe ich die Flexibilität, die ich brauche, um entsprechend
den heutigen Möglichkeiten tatsächlich Dokumente zu beschreiben.
Ein anderer Punkt, den ich jetzt hier gar nicht so explizit
angesprochen habe, war, dass man in XML natürlich auch andere
Informationstypen einbetten kann, nicht nur Text, sondern durchaus
auch noch wesentlich mehr, also Bilder, Zeichnungen, alle möglichen
Arten von Informationen können dort eingebettet werden und all das war
ja bei EDI bzw.
EDFact nicht möglich.
Ich hatte gesagt, wir werden uns jetzt mit dem Begriff XML-Schema
beschäftigen.
XML -Schema ist etwas, was ähnlich ist zu den Dokumenttyp
-Definitionen, ist auf der gleichen Ebene zu sehen wie Klasse und
Objekt bei der objektorientierten Programmierung.
Die Klasse gibt also das Schema vor.
Das Wort Schema kennen Sie aus dem Datenbankbereich, da redet man vom
Datenbankschema und von den konkreten Einträgen in der Datenbank.
Also Sie sehen, dass Begriffe hier über verschiedene Bereiche immer
wieder verwendet werden, also Schema ist deutlich, gibt den Rahmen vor
für ein konkretes Objekt.
Und das hat natürlich eine DTD auch gemacht.
Ich sagte, DTD ist eine Grammatik, ein XML-Schema ist auch eine Art
Grammatik.
Gibt also vor, welchen Regeln ein Dokument entsprechen soll.
Bei DTDs hatten wir zwar schon viele Vorteile gegenüber HTML, aber
immer noch einige Probleme, nämlich nur relativ rudimentäre
Datentypen.
Ich hatte Ihnen gesagt, an dem Beispiel mit dem Wetter, da konnte ich
zwar über die Tags bestimmte Inhalte oder bestimmte Bedeutungen
suggerieren, aber das, was zwischen den Tags stand, zwischen Begin-Tag
und End-Tag, war dann jeweils nur einfach Character-Data, also ein
String.
Und mehr habe ich doch nicht gehabt, eine Folge von Zeichen.
Und ich hatte natürlich auch explizite Aufzählung, ich konnte sagen,
innerhalb eines Tags können bestimmte Elemente vorkommen.
Aber mehr hatte ich auch nicht als Möglichkeit, so ein Dokument zu
strukturieren.
Man konnte insbesondere keine komplexeren internen Strukturen
irgendwie definieren.
Und das ist etwas, was man eigentlich braucht, für die doch etwas
komplexeren Informationen, die man mit solchen Dokumenten darstellen
möchte.
Ein anderes Problem ist, dass wir bei DTDs nur eine rudimentäre
Unterstützung haben, also keine volle Unterstützung der Möglichkeiten
von Namensräumen.
Und deswegen hat man eben das erweitert und hat XML-Schemata
eingeführt, die noch ein paar Vorteile bieten, dass sie in der
gleichen Syntax geschrieben sind wie XML-Dokumente.
Für Dokument-Typ-Definitionen gibt es einige andere Vorgaben als für
die XML-Dokumente selbst.
Und das XML-Schema hat die gleiche Syntax wie XML-Dokumente, hat ein
stark verbessertes System von Datentypen, hat also wesentlich mehr
Möglichkeiten, Datentypen zu spezifizieren, da gehen wir gleich noch
darauf ein.
Wir haben Vererbungsmechanismen, ich kann also aus einem Datentyp
etwas vererben, kann also ein Datentyp zum Beispiel einschränken.
Das ist eine Vererbung, ich kann also Teilklassen wählen innerhalb
eines Datentyps.
Ich kann zusätzliche Datentypen definieren und habe hier eine breitere
Unterstützung von Namensräumen.
Jetzt kommen gleich Beispiele, ich hoffe, Sie können das, müsste groß
genug sein.
Ich habe also hier eine Datei, die soll hier adressen.xml heißen.
Diese Datei, adressen.xml, soll im Prinzip eine Adressenliste
enthalten.
Und dafür, für die Strukturierung dieser Adressenliste, verwende ich
eine Schema-Definition.
Da steht hier grammar.xsd, das ist also eine XML-Schema-Definition.
Und die sieht jetzt wie folgt aus.
Ich erkläre also das, ich werde gleich noch die einzelnen Teile
nochmal genauer erklären, auch an ein paar anderen Beispielen.
Aber an dem Beispiel kann man ganz gut sehen, was hier eigentlich drin
ist.
Also zunächst mal sieht man, das ist ein XML-Dokument, XML-Version 1.0
in dem Fall.
Und dann steht gleich als nächstes xsd, also ein Schema.
Und xmlns ist also xsd, ist definiert als den Namensraum für XML
-Schemata.
Sie können konkret auf diese URL gehen mit Ihrem Webbrowser und kommen
dann auf eine Webseite, die XML-Schemata definiert.
Und auf dieser Webseite finden Sie maschinenlesbare Informationen, die
können also dann von einem Parser tatsächlich angeguckt werden.
Und dann ist klar, welche Strukturelemente vorkommen können in so
einem XML-Schema.
Offensichtlich kann dort etwas vorkommen wie SimpleType.
SimpleType, in diesem Fall, hier steht Name, da wird also ein Name
angegeben für ein SimpleType.
Offensichtlich eine Typ-Definition.
Dieser Typ soll den Namen String 30 haben.
Und was für ein Typ ist das?
Dieser Typ entsteht durch Vererbung.
Und zwar durch eine Art der Vererbung, die hier Einschränkung genannt
ist, Restriction.
Und der Basistyp in dem Fall ist der xsd-String-Typ.
Also ein spezieller Typ, der innerhalb von dieser Schema-Definition,
die in XML standardisiert wurde, standardmäßig vorhanden ist.
Hier gehe ich also davon aus, xsd-String, dieser Qualified-Name für
diese Zeichenketten, ist bekannt.
Und das sind beliebig lange Zeichenfolgen, ähnlich wie CharacterData.
Und ich sage jetzt, dass diese Restriction in folgender Art und Weise
vorgenommen wird, dass die maximale Länge auf den Wert 30 festgelegt
wird.
Also habe ich in String 30 eine Menge von Möglichkeiten, die dadurch
eingeschränkt ist, dass ich nur Zeichenketten der Länge 30 vornehmen
oder dort drin haben kann.
Sowas kann wichtig sein, wenn Sie zum Beispiel irgendetwas formatieren
wollen, in einem bestimmten Bereich, wo Sie nur bestimmten Platz
haben, für die Darstellung von Objekten.
Wenn Sie wissen müssen, ich habe maximal 30 Zeichen in meinen Texten,
die dort stehen, dann können Sie das verwenden bei der Präsentation
dieser Objekte, Sie können entsprechend Platz dafür vorsehen.
Also dieser String 30 Datentyp ist ein SimpleType, der ich bekomme als
Einschränkung dieses allgemeineren Datentyps String.
Ich gebe Ihnen gleich noch eine Auflistung der Datentypen, die
standardmäßig vorhanden sind.
Das ist also hier diese Einschränkung.
NameTag für Restriction.
Und dann kommt dahinter ein ComplexType.
Muss ja was Komplizierteres sein.
Und dieser ComplexType soll den Namen erhalten, Adresstyp, das steht
hier.
Und dieser Name oder dieser Adresstyp, der wird jetzt im Folgenden
definiert.
Und hier steht, dass das Ganze eine Sequenz sein soll.
Also hier ist die Definition unseres komplexen Typs eine Folge von
bestimmten Elementen.
Und das heißt, was ist das für eine Folge?
Da steht ein Element, zunächst mal ein Ort, dann steht hier eine
Postleitzahl und da steht MinOccurrence gleich 0.
Also diese Postleitzahl muss nicht auftauchen, sie kann auch
wegfallen.
Wenn MinOccurrence 0 steht, heißt das, sie muss nicht unbedingt da
sein.
Also fange ich an mit einem Ort und dahinter steht jetzt eine
eventuelle Postleitzahl.
Ist halt hier in der Reihenfolge aufgeschrieben, hätte man auch in
einer anderen Reihenfolge aufschreiben können.
Dann haben wir einen weiteren komplexen Typ hier drin, eine Struktur,
die nennt sich Choice.
Choice ist eine Auswahl.
Ich kann hier auswählen zwischen zwei verschiedenen Möglichkeiten.
Die beiden Möglichkeiten sind hier gegeben.
Ich habe hier drin eine Sequenz.
Da steht entweder Straße und dahinter eine Hausnummer oder es steht
dort ein Postfach.
Das heißt, ein Dokument, das diesem Schema entspricht, wird hinter dem
Ort entweder eine Straße angeben mit Hausnummer oder ein Postfach.
Beide Möglichkeiten sind hier mit angegeben.
So, dann habe ich hier noch ein Attribut Name und das ist also die ID.
Typ ist ID, Use required.
Also Sie sehen, hier habe ich noch eine Attributsdefinition für das,
was hier als...
Ich begreife nicht, warum das immer wieder auftaucht hier.
Jetzt habe ich also hier diese Möglichkeiten, Dokumententypen
anzugeben.
Und damit ist also dieser Complex-Type damit beendet.
Das ist der Complex-Type insgesamt.
Und das ist auch schon mal ein ganzes Schema.
Ich habe zwei Typen drin definiert.
Ein Simple-Type, ein Complex-Type.
Das soll also die Adressenliste werden.
Gut, damit habe ich also diese Adressenliste von Orten, Postleitzahl,
Straßenhausnummer usw.
als Strukturierungselement in meinen XML-Dokumenten.
Das will ich jetzt nochmal ausführlicher machen.
Die Präambel in so einem XML-Schema sieht also so aus, dass oben
drüber steht immer dieser XML-Header.
Und dann steht hier etwas, was immer vorhanden sein muss.
Also jedes XML-Schema beginnt mit diesem Teil.
Dieser Name-Space, dieser URL für den Name-Space muss angegeben werden
in einer Definitionszeile für so ein XML-Schema.
Hier werden also in dieser URL, wie gesagt, die XML-Schema
-Konventionen alle dokumentiert.
Und dann steht hier unten noch ein Target-Name-Space, der muss nicht
da sein.
Der gibt an, wie ich in diesem...also das ist praktisch jetzt der Name
-Space für dieses Schema.
Da kann ich also ein Schema angeben.
Das heißt, alles, was hier als Namen definiert wird, wird mit diesem
Name -Space identifiziert.
Ich kann noch eine gewisse Annotation angeben, ich kann eine
Beschreibung des Schemas angeben.
Und hier steht also zum Beispiel eine Annotation.
Und diese Annotation besteht einfach nur darin, dass ich hier sage,
das wird in Englisch geschrieben.
Und der Inhalt ist hier kurz angegeben.
Also einfach nur eine Beschreibung, was wird mit dem Schema wirklich
gemacht.
Das ist also etwas für denjenigen, der sich sowas anguckt, damit er
weiß, wofür wird hier etwas definiert.
Dann werden die einzelnen Elemente in dem Schema, oder die haben
natürlich bestimmte Konventionen.
Hier habe ich also ein Element mit Namen Comment.
Und der Typ ist in dem Fall einfach nur irgendein String.
Sie haben eine Frage.
Sie können das beliebig wählen.
Also das ist so, dass Sie, ich hatte hier einfach vor vorigen Seite,
hier steht XMLNSXSD gleich.
Da können Sie auch Otto hinschreiben, Otto gleich.
Und dann würden Sie darunter immer Otto verwenden.
Es ist ja dann innerhalb des, so wie ich gesagt hatte, innerhalb
dieses Dokuments, wäre dann Otto die Bezeichnung Ihres Namensraums,
der sich auf die Schemata bezieht.
Das ist durch diese Anweisung hier festgelegt.
Hier vorne steht auch schon XSD.
Das ist aber etwas, was in der XML-Version bereits festgelegt ist.
Da wird angedeutet, dass das hier eben eine Schema-Definition ist.
Das muss bereits in XML so bekannt sein, damit das hier vernünftig
interpretiert werden kann.
Sie können aber bei der Definition oder bei der Angabe des Namensraums
hier unten, dann einen beliebigen Namen verwenden.
Man verwendet natürlich standardmäßig das XSD, weil das der sprechende
Name ist für XML-Schema-Definition.
Aber Sie können da auch einen beliebigen Namen nehmen.
So, jetzt haben wir so hier, wie gesagt, das was ganz ähnlich ist wie
die Element-Definition in der DTD.
Da war die Syntax ein bisschen anders.
Da hatte man diese Spitze-Klammer auf mit dem Ausrufezeichen daneben
und dann Element geschrieben.
Hier ist halt die Notation etwas anders.
Aber es wird eben über diese Attribute hier alles definiert.
Aber es ist, glaube ich, auch klar, wie man das machen soll.
Dann können Sie eben, das war das Beispiel für die Erstellung eines
neuen Datentyps über SimpleTypeString30, hatte ich Ihnen gerade
erläutert.
Hier wird eben dieser neue Typ String30 definiert und ich habe damit
eine Einschränkung dieses Bereichs.
Es gibt auch Möglichkeiten, einen Datentyp auszuweiten.
Das habe ich hier jetzt aber nicht dargestellt.
Das wäre eine Extension.
Da kann man sich angucken, wie Extension genau definiert ist.
Wichtig ist nur, man kann Datentypen einschränken auf verschiedene Art
und Weisen und sie auch noch erweitern.
Das Wichtigste sind die Complex Types, weil ich darüber die Struktur
von Inhalten deutlich wesentlich besser spezifizieren kann.
Also, ich habe in einem Complex Type weitere Elemente mit drin oder
Attribute.
In dem Beispiel AdressTyp habe ich eine Folge von Elementen, die durch
das erste Element Sequence definiert sind.
Ich habe also hier eine Sequence, da können also das, was hier steht,
beliebig häufig vorkommen.
Das Ganze ist jetzt ein Sequence-Type.
Es gibt dafür nicht nur Sequence, habe ich Ihnen gerade eben
vorgestellt, bei dem Beispiel drin.
Es gibt auch andere Dinge.
Es gibt Choice, es gibt All.
Choice kam auch schon vor in dem Beispiel, die Auswahl zwischen zwei
Möglichkeiten, Group und All.
Also schauen wir uns zunächst mal Choice an, das hatte ich Ihnen
gerade eben erläutert.
Choice bedeutet, dass ich auswählen kann zwischen den zwei Elementen,
die hier drin stehen.
Können auch mehrere sein.
Da wird eines von den Möglichkeiten in den Dokumenten dann ausgewählt.
Entweder also Straße, Hausnummer in dem Beispiel oder ein Postfach.
Dann gibt es die Möglichkeit, eine Gruppe zu definieren.
Das kann auch ganz sinnvoll sein.
Sie sehen, hier steht immer eine REF-Bezeichnung.
Es steht also REF Straße, REF Postfach.
Und Sie können dann später, wenn Sie das Straße verwenden, dann ist es
klar, es bezieht sich auf dieses Dokument.
Oder auf dieses Element, das da definiert ist.
Genauso können Sie eine Gruppe benennen, eine Menge von...
Sie haben also hier irgendeine Anzahl von Elementen definiert in Ihrem
Schema.
Und Sie fassen die zu einer Gruppe zusammen.
Dann können Sie dieser Gruppe irgendeinen Namen geben, zum Beispiel
Otto.
Und dann können Sie an anderer Stelle über Otto, im Prinzip genau auf
diese Elemente, oder dann haben Sie eine Referenz auf genau diese
Elemente, wann immer Sie den Namen Otto an anderen Stellen in Ihrem
Dokument verwenden.
Also das ist eine Möglichkeit, wie man referenzieren kann, sich
beziehen kann auf etwas, was an einer anderen Stelle im Dokument
gemacht wurde.
Ich muss nicht immer wieder das Gleiche hinschreiben, sondern ich
definiere es nur einmal und beziehe mich über solche Referenzen dann
auf die Definition, die woanders gemacht wurde.
Dann haben wir ALL.
Kann man auch verwenden.
Bei SEQUENCE ist die Reihenfolge der eingeschlossenen Elemente
wichtig, bei ALL ist das nicht wichtig.
Da können die Elemente in einer beliebigen Reihenfolge verwendet
werden.
Bei CHOICE, hatte ich schon gesagt, wird nur ein Element ausgewählt.
Und wenn ich, hier sehen Sie MIN OCCURSED, da kann ich also sagen, wie
häufig solche Elemente vorkommen dürfen.
Da steht also, wenn der MIN OCCURSED Null steht, muss es nicht
auftauchen.
Es könnte stehen MIN OCCURSED 17 und es kann auch MAX OCCURSED
angeben.
Ich kann also sagen, wie häufig ein Element in so einem komplexen Typ
auftauchen darf.
Wenn ich NICHTS angebe, dann nehme ich an, dass 1 gemeint ist.
Dass also genau einmal auftaucht.
Und dann kann ich auch noch Attribute definieren.
Also hier wird ein Name mit dem Wert ID definiert.
Also TYPE ist hier der Typ des Attributs.
Der Typ ist also ein Identifier.
Hier steht genau der Wert des Attributs NAME.
Und anschließend steht hier noch, ob das Ganze required ist oder
optional.
Sie erinnern sich, das hatten wir bei HTML auch gehabt, dass man Dinge
angeben kann, ob sie required oder optional sind.
Bei den Attributen, die dort definiert wurden.
Hier sieht die Definition ein bisschen anders aus.
Also auch bei den DTD-Definitionen hatten wir auch die Möglichkeit,
diese verschiedenen Dinge anzugeben.
Hier wird es halt in einer etwas anderen Syntax gemacht.
Jetzt haben wir hier nochmal ein Beispiel.
Das ganz kurz zurück.
Hier sehen wir also nochmal diese Anfangsdefinition.
Und eine etwas andere...
Ich will darauf jetzt gar nicht weiter eingehen.
Ich komme auf die einzelnen Elemente.
Die sehen wir hier.
Das, was jetzt auf den nächsten Folien kommt, sind also Ausschnitte
aus dem, was auf der vorigen Folie zu sehen war.
Hier habe ich jetzt ein...
Nein, ich habe hier ein Dokument.
Ich habe hier eine Liste XML.
Entschuldigung.
Hier habe ich eine konkrete Liste, die zu dem Dokument...
Da ist die Liste XML.
Und hier ist die Grammar XSD.
Und ich gebe im Folgenden jetzt den Inhalt von Liste an.
Und wir referenzieren dann hier auf die entsprechenden Einträge in
dieser Schema-Definition.
Wenn ich also in meinem Dokument, in diesem Fall an der Liste, hier
steht es Liste, Titel gleich Kundenliste, dann muss also in dem Schema
Stand drin Attribute Name Title und daneben steht, dass das einfach
nur ein String ist.
Das wird also überprüft vom Parser, ob entsprechend hier, wenn für
diese Liste dieses Attribut Titel zur Verfügung steht und welcher Wert
dort erlaubt ist.
Wir haben hier also noch eine Definition für so ein...
Da sehen Sie nochmal so ein Schema mit der Namensraum-Definition.
Und hier haben wir Referenzen in diesem Schema.
Ich hatte gesagt, wir verweisen auf andere Definitionen von Elementen.
Und hier wird oben ein Name, also hier steht Name gleich Name,
und in dieser unteren Stelle hier unten, in dieser Sequenz, diese
Sequenz, die hier definiert wird innerhalb eines Complex Types,
schauen wir uns mal genauer an, was hier passiert.
Also, hier oben haben wir ein Element Name definiert, ein Element E
-Mail, und hier steht Name hat also ein Typ, das steht XSD String, das
heißt, das ist irgendeine Folge von Zeichen.
E-Mail genauso ist nur irgendeine Folge von Zeichen.
Jetzt haben wir hier noch ein Attribut Namen Title, auch eine Folge
von Zeichen.
So, und im weiteren Schema wird jetzt das, was hier oben definiert
wurde, verwendet, an anderer Stelle.
Wir haben ein Element, das wir Kunden nennen, Name gleich Kunde, und
wir definieren hier einen komplexen Typ, Complex Type, das ist also
innerhalb dieses Elements definiert, da haben wir unsere Klammer.
Also, dieses Element ist ein komplexer Typ, und dieser komplexe Typ
besteht aus einer Sequenz, das heißt, ich habe hier eine Sequenz, die
beliebig oft auftaucht, Max occurs unbounded, eine Liste von Kunden
soll das werden, und hier drin steht jetzt, welche Elemente in dieser
Liste vorkommen, oder in dieser Sequenz vorkommen.
Das erste ist ein Name, steht als Ref gleich Name.
Durch dieses Ref gleich Name habe ich die Referenz auf das Element,
das bereits mit Name definiert wurde, das heißt, das ist die Referenz
auf das Ding hier oben.
Und wir wissen, ich brauche hier nicht nochmal hinzuschreiben, dass
das vom Typ XSD String ist, weil das bereits dort oben stand.
Genauso steht hier unten Ref gleich E-Mail, damit verweise ich auf die
Definition von E-Mail dort oben.
Ich weiß, das ist ein String, und dadurch brauche ich das hier nicht
nochmal hinzuschreiben.
Hier schreibe ich nur noch zusätzlich hin, dass diese E-Mail Adresse
nicht notwendigerweise auftauchen muss, aber es dürfen beliebig viele
auftauchen.
Null bis irgendwie viele.
Also eine beliebige Folge von E-Mail Adressen.
Und das ist also das Ende dieser Folge.
Diese Folge kann also beliebig lang sein.
Dann habe ich hier noch ein Attribute Ref Title, das heißt, ich habe
hier auch noch einen Titel für, das ist also hier der komplexe Typ,
der besteht auch noch hier hinter aus dem, da ist noch der Attribut
dabei, Titel und dieser Titel, welche Form der von welchem Typ der
ist, das ist wiederum oben angegeben, kommt hier noch ein Pfeil rein,
da habe ich die Referenz auf Titel und dort war als Wert für den
Titel, für das Attribut Titel angegeben, eine beliebige Zeichenfolge.
Und damit habe ich jetzt diesen komplexen Typ fertig definiert und
habe verwiesen auf Definitionen dabei, die im oberen Bereich bereits
vorgekommen waren.
An diesem einfachen Beispiel zeigt sich noch nicht so sehr der Vorteil
dieser Vorgehensweise, ich hätte diese Definition, die da oben steht,
genauso gut unten machen können in der Definition des komplexen Typs,
aber Sie sehen ja hier, da habe ich noch drei Punkte, das heißt, da
kann ich ja noch beliebig weitere Elemente definieren, indem ich auch
wieder auf diese Elemente zugreife, die ich dann eben nur
referenzieren muss, ich muss nicht nochmal hinschreiben, dass das
jeweils ein String ist.
Gut, ich hoffe, dass die Strukturierungsmöglichkeit hier deutlich
geworden ist.
Ah ja, hier ist nochmal eine Sequenz, also diese geordnete Gruppe von
Elementen hatte ich schon darauf hingewiesen und hier steht eben
nochmal, wie häufig dieses zweite Element vorkommen darf.
Da also null oder mehrfach.
Hier nochmal die verschiedenen Möglichkeiten bei der Definition von
Datentypen.
Ich kann Gruppen definieren, Elementgruppen definieren, ich kann
Attributgruppen definieren, Attribute, die vorkommen sollen innerhalb
eines Elements.
Das heißt, Sie könnten einmal eine Attributgruppe definieren und
machen später eine Referenz darauf und haben dann automatisch diese
Gruppe von Attributen in dem Element, das Sie jetzt definiert haben.
Dann haben wir die Möglichkeiten, eine Sequenz zu definieren, wir
können eine geordnete Folge von Elementen damit angeben und dabei
jeweils sagen, wie häufig die einzelnen Elemente vorkommen sollen.
Wir können eine ungeordnete Folge angeben und wir haben die
Wahlmöglichkeit über Choice.
Das waren also diese Strukturierungsmöglichkeiten.
Dann gab es die Möglichkeiten, ein Datentyp einzuschränken.
Da hatte ich Ihnen das Beispiel gegeben mit dem String, der aus 30
Zeichen besteht.
Und wir können gewisse Erweiterungen machen, wir können Datentypen
vereinigen und wir können außerdem einfach eine Liste von Elementen
machen, durch Zwischenraum getrennt.
Das heißt, weitere Möglichkeiten, Datentypen anzugeben und damit sehen
Sie, die Schemata liefern deutlich mehr Möglichkeiten in der
Strukturierung eines Dokuments und damit liefern sie auch mehr
Möglichkeiten, die Bedeutung der Inhalte eines Dokuments festzulegen.
Ich kann damit, wenn ich weiß, jetzt muss nach einem Tag ein
bestimmter Datentyp auftauchen, dann kann ich auch überprüfen, ob
genau dieser Datentyp vorgekommen ist in dem Dokument.
Und damit habe ich mehr Möglichkeiten zu überprüfen, ob also auch das,
was da drin steht, der vorgegebenen Bedeutung entspricht.
Das ist ein ganz wesentlicher Punkt.
Ich sagte, es gibt einige vorgegebene Datentypen in diesen XML
-Schemata, die sind hier angegeben.
Einfach Identifier, Identifier References, Entities und so weiter,
Entity oder Entities, NM-Token und so weiter.
Also verschiedenste Sachen.
Names, Qualified Names, Non-Colon Name, das sind sehr elementare
Datentypen.
Etwas interessanter sind diese hier für Zahlenbereiche.
Das hatten wir bei DTDs überhaupt nicht.
Da hatten wir gar keine Zahlen als mögliche Wertebereiche.
Hier können wir angeben, dass der Inhalt eines Tags, also das, was
zwischen Beginn- und Endtag steht, eine Zahl sein soll.
Meinetwegen ein Integerwert.
Integer ist hier nicht eingeschränkt in Bezug auf die Größe der
Zahlen.
Hier habe ich also eine beliebige ganze Zahl.
Eine beliebige ganze Zahl heißt, ich habe ein Vorzeichen, Minus oder
Plus, muss aber nicht vorkommen, wie Sie hier sehen.
Und dahinter habe ich eine Folge von Dezimalziffern und das wird
interpretiert als eine ganze Zahl.
Und wenn dort irgendein anderes Zeichen vorkommt, ist es keine ganze
Zahl.
Dann habe ich die Möglichkeit zu sagen, das ist eine Non-Positive
Integer, also nur etwas bis 0, aber ansonsten negativ.
Oder eine Negative Integer, dann ist halt die 0 weg.
Und dann kann ich auch, ähnlich wie in Programmiersprachen, mich
beziehen auf Zahlenbereiche, bei denen ich berücksichtige, wie viel
Platz ich im Rechner brauche, um diese Werte darzustellen.
Wenn ich also Long verwende, das ist genau das, was wir auch aus
Programmiersprachen kennen, bezieht sich auf Doppelwortzahlen,
Integer, die über 64 Bit dargestellt sind.
Dann geht mein Wertebereich von minus 2 auf 63 bis 2 auf 63 minus 1.
Das heißt, da habe ich 2 auf 64 verschiedene Möglichkeiten, Werte
anzugeben und die werden genauso hier erlaubt.
Sobald ich aus dem Bereich rauskomme, ist es kein Long-Typ mehr, kann
überprüft werden.
Int ist also dann der eingeschränkte Integer-Bereich, eingeschränkt
auf eine Wortbreite in 32 Bit-Rechnern, also 2 auf 32 verschiedene
Werte von minus 2 auf 31 bis 2 auf 31 minus 1.
Short wäre ein Halbwort, wie viel weiß das Halbwort bezeichnet, 16 Bit
für einen Wert.
Da habe ich also einen entsprechend kleineren Bereich.
Das kleinste wäre Byte.
Sie erinnern sich, in Java haben Sie genau diese Möglichkeiten, auch
solche Zahlenbereiche zu verwenden.
Hier können Sie das auch in XML-Dokumenten so angeben, dass der Wert,
der zwischen zwei Tags oder Beginn- und Endtags stehen soll, ein Byte
sein soll.
Dann muss das ein Wert sein zwischen minus 2 hoch 7, also irgendwie
minus 128 bis 127.
Ja, natürlich, 2 hoch 7 minus 1.
So, und dann haben wir hier noch die Möglichkeit, entsprechend None
-Negative -Integer anzugeben, Positive-Integer.
Und dann kommen noch ein paar weitere Sachen, Unsigned-Long, Unsigned
-In, Unsigned-Short, Unsigned-Byte.
Das heißt, der Bereich, wenn wir normalerweise einen Zahlenstrahl
anschauen, haben wir hier die Null, und haben hier entsprechend
irgendeinen negativen Wert, Minus-Maximalwert, und hier haben wir den
Plus -Maximalwert.
Und wenn Sie unsigned das Ganze machen, dann betrachten Sie das alles
von Null an bis zu diesem Wert.
Dann haben Sie nur positive Werte mit entsprechend Long, Int, Short,
Byte -Interpretationen.
Sie haben entsprechend 64, 32 oder 8 Bit zur Verfügung, um die Zahlen
darzustellen.
Entsprechend sind die Zahlenbereiche hier angegeben.
Das waren alles Integer-Werte.
In vielen Anwendungen tauchen reellwertige Inhalte auf.
Dafür kennen wir aus Programmiersprachen ebenfalls Möglichkeiten,
reelle Zahlen zu spezifizieren.
Da gibt es Float, da gibt es Double.
Da kennen Sie alle den IEEE-Standard, wie man einfach lange oder
doppelt lange reelle Zahlen spezifiziert.
Das heißt, genau in der Form können Sie hier Zahlen angeben, in den
Zahlenbereichen, die durch den IEEE-Standard auch gegeben sind.
Es kann also auch überprüft werden, ist das eine Zahl, die eben dann
genau übertragbar ist in einen Datentyp Float oder Double in einem
Programm.
Sie wollen ja solche XML-Dokumente mit Programmen bearbeiten können.
Dadurch, dass Sie diese Datentypen zur Verfügung haben, können Sie
überprüfen, ob im Dokument tatsächlich entsprechend den Restriktionen
der Datentypen die Werte richtig sind.
Und dann können die auch ohne das Fehler auftreten in Elemente im
Programm übernommen werden.
Sie müssen in Ihrem Programm, mit dem Sie das bearbeiten, nicht
explizit nochmal überprüfen, ob der Inhalt, der dort steht,
tatsächlich ein Float ist oder tatsächlich ein Short, sondern das wird
bereits durch den XML-Parser gemacht.
Dann gibt es etwas, was auch interessant ist, eine Decimal-Definition.
Decimal kennen Sie nicht als Datentyp.
Decimal ist im Prinzip so eine Art natürlichsprachliche Beschreibung
von reellen Zahlen, nämlich Sie können hier irgendeine Folge von
Vorzeichen, Dezimalziffern und auch Punkt da drin haben.
Also Sie können 3.1315 und sowas angeben.
Sie können genauso plus 1.0 hinschreiben.
Sie hätten auch plus 1.0 hinschreiben können.
Das heißt, bei Decimal haben Sie in Erweiterung zu dem, was hier oben
bei Integer stand, also Integer und Decimal, unterscheiden sich
dadurch, dass Sie bei Decimal irgendwo einen Dezimalpunkt setzen
können.
Das könnte eine beliebig lange Folge von Ziffern sein.
Da können Sie also beliebig große Genauigkeit hinschreiben.
Die Syntaxanforderungen sind nur, es muss beginnen mit einem Minus
oder Plus oder danach kommen halt irgendwelche Ziffern.
Und wenn ein Vorzeichen kommt, darf das nur ein Minus oder Plus sein.
Und dann kommen halt Ziffern und bei diesen Ziffern kann irgendwann an
irgendeiner Stelle ein Punkt stehen.
Es dürfen keine zwei Punkte auftreten, nur ein Punkt.
Das ist halt der Dezimalpunkt.
Und ansonsten dürfen das beliebig viele Ziffern sein.
Das heißt, Sie könnten im Prinzip irgendwelche Zahlen mit einer
beliebig großen Genauigkeit hier aufschreiben.
Wie das dann im Rechner interpretiert wird, ist wieder eine andere
Sache.
Wenn Sie also ein Programm verwenden und Sie wissen, an einer
bestimmten Stelle kommt ein Decimalwert vor, dann müssen Sie in Ihrem
Programm erstmal überprüfen, wie lang ist denn diese Folge von
Ziffern.
Und dann können Sie erst herausfinden, wenn Sie das jetzt überführen
wollten, meinetwegen in Gleitpunktnotation, was ist die richtige
Potenz, die Sie dafür verwenden müssen, was ist der Exponent und was
ist die sinnvollste Art, das darzustellen.
Brauchen Sie dafür Single oder Double oder Extended als Möglichkeit,
das als Gleitpunkt darzustellen.
Sie werden dann nur einen gewissen Teil verwenden oder Sie machen eine
mehrfach lange Darstellung.
Das ist Ihnen überlassen, wie Sie mit dem Wert umgehen.
Aber Sie können im Prinzip in den Dokumenten, bei denen der Typ
Decimal vorgesehen ist, an einer bestimmten Stelle, da können Sie
Dinge beliebig genau aufschreiben.
Sie wissen genau, sobald Sie reellwertige Operationen haben in
Programmen mit den Standard Datentypen, Standard Gleitpunktdatentypen,
da haben Sie immer nur eine beschränkte Genauigkeit, eine beschränkte
Anzahl von Dezimalstellen, die signifikant sind, die also verwendet
werden, der ganze Rest fällt weg und damit haben Sie die üblichen
Probleme mit der Genauigkeit von Rechnungen und das wird also hier
beim Typ Decimal zunächst mal ignoriert.
Und Sie haben schließlich noch den kleinsten Datentyp Boolean mit den
Werten True, Eins, False und Null, sogar vier Werte, aber es ist klar,
welche Interpretationen die haben.
Damit haben wir also jetzt wirklich das zur Verfügung, was wir an
Standard Datentypen auch aus Programmiersprachen kennen.
Wir haben sogar noch mehr zur Verfügung und wir können über diese
Complex -Type-Definitionen sogar daraus noch komplexere
Datenstrukturen machen.
Etwas, was für eine etwas intelligentere Beschreibung von Dokumenten
sicherlich sehr sinnvoll ist.
Es gibt sogar noch weitere Datentypen, die synthetisch funktionieren.
Also String fehlte ja noch.
Folge von irgendwelchen Zeichen eingeschlossen in Anführungszeichen
oben.
Sie haben ein Datumsformat vorgegeben.
Sie haben ein Zeitformat vorgegeben, also da haben wir eine Stunde und
Minuten und Sekunden und hier haben Sie eine Zeitverschiebung, also
bezogen auf Greenwich-Zeit, also eine gewisse Zeitverschiebung.
Sie können Time Instance und Time Periods angeben.
Und Time Period wäre hier zum Beispiel Period sieben Monate, sieben M.
Ein Monat wäre eine Period an one month.
Ein Jahr wäre Period one year.
Oder Sie können das Century angeben.
19 in dem Fall, hier an dem Beispiel.
Sie erinnern sich an das Jahr 2000 Problem.
Früher, als man anfing mit der Datenverarbeitung, hat man sich noch
nicht damit beschäftigt gehabt, dass sowas eine Rolle spielen könnte,
was die ersten beiden Ziffern sind.
Recurring Date, das wäre ein Recurring Date hier.
24 Stunden, alle 24 Stunden soll irgendwas gemacht werden.
Oder Recurring Day, das wäre zum Beispiel der zweite Tag in einem
Monat.
Also jeden zweiten Tag in einem Monat muss irgendetwas gemacht werden.
Oder Time Duration, ganz allgemein angegeben.
Hier haben wir die Anzahl der Jahre, Anzahl der Monate, Anzahl der
Tage und dann auch noch die Zeit, wie viele Stunden.
Also hier können Sie sehr genau angeben, hier habe ich das unten
nochmal für Time Duration, steht also die genaue Beschreibung hier
unten, Zitat aus der Definition, die Sie bei XML Schema finden.
Hier ist genau angegeben, wie so eine Zeitdauer angegeben wird.
Und also wie gesagt, ganz genau spezifizierbar bis runter sogar auf
den Sekundenbereich, was da oben gar nicht gemacht wurde.
Dann haben Sie eine Recurring Duration, Sie haben einen Binary Type,
Sie haben eine URI Referenz, können also hier URIs angeben, haben wir
auch schon oft genug gemacht.
Und Sie können auch noch Sprachen angeben, auch dafür Datentypen.
Jetzt wissen wir also, welche Datentypen hier so alles vorgegeben
sind.
Sie sehen eine Vielfalt von Möglichkeiten und damit habe ich Ihnen
jetzt über Schemata eigentlich einiges erzählt.
Ich habe Ihnen nicht die komplette Spezifikation von Schemata
beschrieben, ich habe Ihnen Beispiele gegeben für Schemata, um Ihnen
anzudeuten, was man machen kann.
Wenn Sie selber ein Schema schreiben müssen, Sie werden also in den
Übungen natürlich damit zu tun haben, dann müssen Sie sich halt die
Schemaspezifikation anschauen.
Das ist etwas, was ich schon mehrfach gesagt habe.
Man muss solche Standards, wenn man sie konkret einsetzen will, sich
halt konkret angucken und dann muss man sich halt die entsprechenden
Informationen dort zusammensuchen.
Das, was ich in der Vorlesung machen kann, ist nur Ihnen einen
Einblick geben oder Hinweise geben, welche prinzipiellen Möglichkeiten
dort vorhanden sind und die setzt man dann ein.
Gut, jetzt haben wir noch ganz paar Minuten Zeit, um eine weitere
Erweiterung von XML anzuschauen.
Das erste auf dieser Übersichtsfolie, die ich Ihnen vorhin gezeigt
hatte, war XML-Schema.
Hier kommt eine andere Erweiterung, X-Link.
Als ich Ihnen HTML vorgestellt habe, habe ich gesagt, ein ganz
wesentlicher Punkt bei HTML ist die Möglichkeit, dass man Dokumente
verlinkt.
Sie erinnern sich, ich habe eine Möglichkeit, in einem Dokument einen
Link zu spezifizieren und das heißt, Sie haben hier eine Adresse drin,
die verweist auf irgendein anderes Dokument.
Das heißt, ich habe die Möglichkeit, in einem Dokument zu sagen, von
hier geh bitte irgendwo anders hin.
Und in XML hat man das ein bisschen verallgemeinert.
Man könnte sich ja durchaus unterschiedliche Sachen vorstellen.
Es könnte ja sein, dass ich vielleicht noch ein weiteres Dokument
habe, auf das auch verwiesen werden kann.
Oder es könnte sein, dass es noch ein weiteres Dokument gibt, von dem
verwiesen wird.
Es könnten also zwei Dokumente auf zwei andere zeigen.
Wenn man nur HTML im Kopf hat, denkt man, wozu brauche ich das?
Wenn ich aber an die Beschreibung von Informationen, also an die
Beschreibung von Sachverhalten denke, die ich mit XML-Dokumenten
machen will, dann kann es sein, dass ich irgendwelche vernetzten
Strukturen habe, die ich inhaltlich beschreiben muss.
Und dann habe ich für die einzelnen Komponenten meiner vernetzten
Struktur die einzelnen Dokumente und die sind verlinkt vielleicht über
einen Link, der so aussieht, dass ich hier zwei Anfangsteile habe und
zwei Endteile.
Also etwas komplexere Links als diese einfachen Links, die wir aus
HTML kennen.
Und ich kann also kompliziertere Links mit mehreren Endpunkten
definieren und ich kann auch mit einem Link gewisse Informationen
verbinden.
Ich kann einem Link einen Namen geben.
Das kennen wir durchaus auch, dass man einen Link mit Namen belegt
hat.
Das wird ja in HTML auch gemacht.
Da habe ich einen bestimmten Namen.
Das steht drauf hier meinetwegen und ich klicke auf hier und ich gehe
zu der entsprechenden Adresse.
Und das kann ich hier eben auch machen.
Ich kann ja auch noch Attribute mit dazu nehmen.
Ich habe hier also mehr Möglichkeiten Links zu definieren.
Und zunächst mal also diese simple Links.
Da kann ich mir anschauen, wie das in HTML möglich war.
Das war hier das Tag A für Address.
Dann haben wir eine Hyper-Reference.
Das war hier die Bedeutung von diesem Namen, Hyper-Reference.
Da wird eine URL angegeben.
Sie erinnern sich an das Beispiel.
Dann steht dahinter der Name dieses Links, in dem Fall
Forschungsgruppe Effiziente Algorithmen.
Und das ist dann das Ende dieser Definition.
Der Anfangspunkt des Links ist der Ort in dem Dokument, wo dieses Tag
steht.
Der Endpunkt des Links in dem Fall ist die URL, die dort angegeben
ist.
Damit habe ich eindeutig diese Beziehung von einem Dokument auf ein
anderes Dokument hergestellt.
In XML muss man das explizit angeben.
Da kann ich über eine Adresse, jetzt sehen Sie Namespace, xlink, hier
kann ich zum Beispiel, wenn Sie diese Adresse hier, http://www.w3.org
.2000.xlink.namespace, wenn Sie die verwenden, kommen Sie auf einen
Bereich, auf eine Webseite, auf der xlinks definiert sind.
Und dann weiß man, was dort alles möglich ist.
Das wird also hier durch die Namespace-Definition angegeben.
Und jetzt ist es in dem Fall ein Simple Link.
Der Typ ist simple.
Das heißt, dass etwas ähnliches wie in HTML bekannt ist.
Da habe ich auch hier die Hyper-Reference, entsprechend der oberen
Angabe.
Ich habe ein Title.
Habe ich etwas abgekürzt.
Und dann habe ich hier noch etwas, da steht show="new".
show="new", soll bedeuten, wenn ich auf den Link raufklicke, wenn ich
ihn aktiviere, dann soll eine neue Seite angezeigt werden.
Dann will ich in ein neues Fenster gehen, soll ein neues Fenster
aufgehen in meinem Webbrowser und diese Seite anzeigen.
Deswegen new.
Ich könnte auch sagen, das soll nicht ein neues Fenster sein, sondern
soll an der Stelle eingebettet werden.
Dann geht also kein neues Fenster auf und ich bleibe in dem alten
Browser -Fenster, nur der Inhalt in einem bestimmten Bereich ändert
sich.
Und dann steht hier noch actuate, das heißt, wann wird der tatsächlich
aktiviert, dieser Link.
Da gibt es verschiedene Möglichkeiten, nämlich entweder onload, also
das heißt, wenn ich dieses Dokument tatsächlich in den Browser lade,
oder in das Dokument tatsächlich reinschaue, wenn ich das bearbeite,
dann soll dieser Link tatsächlich schon aktiviert werden oder erst
explizit durchs Raufklicken.
Und das wäre in dem Fall hier das Ende dieser Adresse.
Das hier Adresse steht, ist völlig willkürlich, da könnte irgendein
beliebiger Tag stehen.
Wichtig ist das, was hier steht, dass ich hier einen Link definiere.
Und wir werden dann beim nächsten Mal die Komplex-Links kennenlernen,
bei denen man halt mehr Möglichkeiten hat, als diese einfachen Links
bieten.
Das war es für heute, vielen Dank, bis in einer Woche.