BSI: XML
Inhaltsangabe:
- Grundlegendes zu XML
- Geschäftsbrief
- XML Instanz mit DTD
- DTD – selbsterzeugte Regelwerke
- Hierarchisierung
- DTD Attribute
- DTD Attribute
- Validierung
Grundlegendes zu XML
XML (Extensible Markup Language) ist eine Metasprache zur Auszeichnung von Texten nach Definitionen verschiedener Dokumenttypen: XML liefert also Regeln, die beim Erzeugen von XML Instanzen angewendet werden müssen, damit ein standardisiertes Dokument als Datenbasis entsteht, das anschließend mit Softwarewerkzeugen weiter verarbeitet werden kann.
Sind diese Regeln vollständig eingehalten, spricht man von „Well-formedness“ (Wohlgeformtheit) einer XML Instanz. Diese muss gewährleistet sein, damit XML Prozessoren/Parser/Browser die XML-Dateien lesen können.
Es wird auf der Basis dieser Regeln mit einem einfachen Texteditor oder spezifischen XML Editoren verschachteltes deskriptives Markup (= semantische Tags) erzeugt, das eine Baumstruktur aufweist und einem bestimmten, in dem Dokumenttyp festgeschriebenen Konzept folgt. Mit welchen Elementen und auf welche Art und Weise die Verschachtelungen erfolgen sollen, wird für jeden Dokumenttypen in Form von Regeln in der Dokumenttyp-Definition festgelegt und unabhängig von den zu codierenden Daten in einer eigenen Datei definiert. Diese wird als Dokumenttyp-Definition (engl. document type definition, Abkürzung DTD) bezeichnet.
XML-fähige Software liest diese DTDs aus und beurteilen die Daten der darauf bezugnehmenden Instanz. Dabei kann die interpretierende Software feststellen, ob innerhalb der XML-Daten ungültige Notationen vorkommen. Das Verfahren zur Überprüfung einer XML-Datei nach den Regeln ihrer zugehörigen DTD, nennt man Validierung (von engl. valid = gültig).
Folgendes MUSS Beachtung finden:
- XML-Deklaration:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
- Root-Element Alle Elemente sind Child-Elements des Root-Elementes Elemente bestehen grundsätzlich aus:
1. Start-Tag
2. Inhalt
3. End-Tag
und dürfen nicht überlappen.
- Elementnamen können grundsätzlich frei gewählt werden, müssen aber mit einem Buchstaben oder einem Unterstrich beginnen und dürfen kein Leerzeichen oder Doppelpunkt enthalten. Ebenfalls untersagt sind Namen, die mit xml oder XML beginnen.
- ACHTUNG: XML ist case-sensitive!
- Elementen können Attribute zugewiesen werden, für die gilt:
1. pro Element ist der Attributname eindeutig.
2. Regeln für Attributname siehe Elementnamen.
- Kommentare (Bereiche, die nicht interpretiert werden) stehen entweder zwischen Elementen oder umfassen Start- und End-Tag (Auskommentieren):
…
<Elementname >Inhalt</Elementname >
<!– Kommentar dazu –> … <!– <Elementname >Inhalt</Elementname > –>
…
Geschäftsbrief
Soundsostadt, den 20.09.2019
Unternehmen So&So GmbH, Soundsostr. 1, 12345 Soundsostadt
Herr Sowieso
Sowiesostr. 2
54321 Sowiesostadt
Telefonnr.: 0842 2457158
Sehr geehrter Herr Sowieso,
Wir freuen Ihnen mitteilen zu dürfen, dass Sie ein Upgrade für Ihren Flug nach Timbuktu erhalten haben. Sie fliegen nun First Class.
Unter folgendem Link können Sie die aktuellen Flugdetails verfolgen.
http://firstclasssowieso.de
Sie können Ihre Flugdetails auch unter +499 711 48 68 69 abrufen.
Mit freundlichen Grüßen,
i.A. Sarah Soundso
ABC Amtsgericht
Musterstr. 1, 9876 Musterstadt
XML Instanz mit DTD
Das Erzeugen von XML Instanzen im Kontext des Seminars erfolgt zunächst immer mit dem Ziel, dass eine Ressource geschaffen werden soll, die einen Teil unserer Wirklichkeit so beschreibt, dass diese als Datenquelle für Informationssysteme genutzt werden kann. Dazu wird zunächst ein Konzept erarbeitet, dass den Realitätsausschnitt möglichst vollständig als hierarchische Baumstruktur beschreibt.
Im nachfolgenden Beispiel liegt eine Bildersammlung vor, die als über das Internet erreichbar ist. Die Sammlung hat einen Namen und enthält viele Bilder. Jedes Bild verfügt über einen Titel und eine URL, unter der es im Netz erreichbar ist und auf dem Bildern sind Menschen und/oder Bauwerke abgebildet.
Neue schöne Bilder
aus: http://www.bilder.de/
Mona Lisa vor dem Eiffelturm / Ritter, Burgen, Adel
Als Baumstruktur könnte dies wie folgt abgebildet werden:
Basierend auf diesem Baum kann nun eine XML Instanz geschrieben werden, die zusätzliche zu den konzeptuellen Beschreibungen des Baumes konkrete Werte enthält, die auf real vorliegenden Bildern beruhen, zum Beispiel diesen:
<bildersammlung>
<name>Neue schöne Bilder</name>
<lokalisation url="http://www.bilder.de/">
<bild>
<titel>Mona Lisa vor dem Eiffelturm</titel>
<url>http://www.woauchimmer.de</url>
<person>Mona Lisa</person>
<bauwerk>Eiffelturm</bauwerk >
</bild>
<bild>
<titel>Ritter, Burgen, Adel</titel>
<url>http://www.beispielseite.de</url>
<person>byzantinische Kaiserin</person>
<person>Ritter des 13.Jhd</person>
<person>fränkischer Edelmann</person>
<bauwerk>Wasserburg</bauwerk>
</bild>
</bildersammlung>
Die Datei wird unter einem beliebigen Namen mit dem Suffix .xml abgespeichert.
Damit Informationssysteme mit diesen Daten arbeiten können muss ein Prolog erzeugt werden:
- Jede XML Datei begint mit einer „Processing Instruction“ (PI), die durch die Klammerung mittels <? … ?>gekennzeichnet ist. Processing Instructions teilen in der Regel mit, welche Applikation die XML Datei verarbeiten soll beispielsweise ein XML-Browser. Dies wird durch die drei Buchstaben xml festgelegt.Die nachfolgenden Attribute der Processing Instruction geben idR 3 Eigenschaften des Dokuments an:
- version=“1.0″ steht vorläufig immer so – es gibt derzeit nur eine erste Version von XML.
- encoding=“UTF-8″ teilt mit, nach welchem Standard die Zeichen kodiert sind.
- standalone=“no“ teilt mit ob die Document Type Definition in der Instanz steht oder als externe Ressource vorhanden ist.
- Anschließend muß jede XML Datei angeben, welchen Dokumententyp sie verwendet. Dies geschieht durch eine Doctype Anweisung , die mit <! DOCTYPE … > gekennzeichnet ist. (Es ist möglich, den Typ des Dokuments direkt in der XML Datei zu definieren, dies wird jedoch definitiv nicht empfohlen.)
- Ergänzend wird nun der Name des obersten oder Wurzelelements, in unserem Fall also ‚bildersammlung‘, angegeben.
- Dahinter teilt das Schlüsselwort SYSTEM, nach einer Leerstelle gefolgt von einer URL in Anführungszeichen, mit, wo die Definition dieses Documententyps, die „Document Type definition“ zu finden ist.
DTD – selbsterzeugte Regelwerke
Die DTD, eine Definition eines Dokumententyps, ist eine Möglichkeit festzulegen, wie eine Baumstruktur aufgebaut sein muss, indem zu jedem Element (Tag) festgeschrieben wird, ob, welche und wie viele Kind-Elemente enthalten sein dürfen oder müssen. Eine ihr folgende XML- Instanz muss exakt nach diesem Muster aufgebaut sein muss.
Eine DTD sollte möglichst genau und streng das zu Grunde liegende Konzept abbilden, da dies eine wesentliche Voraussetzung für das Erstellen guter Instanzen darstellt.
DTDs sollten immer als externe Ressourcen erstellt werden, können aber auch in der Instanz selber stehen. Dies ist aber ausdrücklich NICHT empfehlenswert.
Die Datei wird unter einem beliebigen Namen mit dem Suffix .dtd abgespeichert.
Folgende syntaktische Regeln müssen beachtet werden:
- Jedes in einer Instanz notwendige Tag muß durch eine <!ELEMENT …> Deklaration explizit eingeführt werden.
- In dieser Deklaration folgt zunächst der Name des Tags, in exakt der gleichen Schreibung, in der er in der Instanz verwendet werden soll.
<!ELEMENT bildersammlung (name?, lokalisation, bild+)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT lokalisation EMPTY>
<! ATTLIST lokalisation
url CDATA #IMPLIED
postal CDATA #IMPLIED
>
<!ELEMENT bild (titel, url, abstract*, person+, bauwerk+)>
<!ELEMENT titel (#PCDATA)>
<!ELEMENT url (#PCDATA)>
<!ELEMENT abstract (#PCDATA)>
<!ELEMENT person (bezeichnung+)>
<!ELEMENT bauwerk (bezeichnung+)>
<!ELEMENT bezeichnung (#PCDATA)>
Das Content Modell oder Inhaltsmodell ist eine Spezifikationen, die Reihenfolge und Umfang der Kindelemente festlegt:
- In Form einer durch Kommata geordneten Liste werden alle Tags, die in dem betroffenen enthalten sein dürfen, in der Reihenfolge angegeben, in der sie vorkommen müssen.
- Steht hinter dem Namen kein Sonderzeichen, muß das Tag genau einmal vorkommen.
- Steht hinter dem Namen ein Pluszeichen, bedeutet dies, daß das Tag mindestens einmal vorkommen muß, aber auch öfter vorkommen kann.
- Steht hinter dem Namen ein Fragezeichen, bedeutet dies, daß das Tag einmal vorkommen darf, aber nicht muß.
- Steht hinter dem Namen ein Sternchen – ‚*‘, bedeutet dies, daß das Tag mehrmals vorkommen darf, aber auch ganz fehlen darf.
- Die spezielle Konstruktion #PCDATA teilt mit, daß an dieser Stelle beliebige Daten stehen dürfen. (PCDATA = „Parseable Character Data“)
- EMPTY als Keyword im Content Model bedingt, dass ein solches Tag nur aus einem Start-Tag besteht und keine Information umschlossen wird. Diese Tags enthalten häufig Attribute, die spezifische Information beinhalten.
Hierarchisierung
Elemente können/müssen über beliebig viele Ebenen gestaffelt sein. In DTDs tritt eine deutliche Hierarchisierung auf: ein Baum mit Eltern,- Kind,- und Geschwisterelemente (Vorfahren und Nachfahren).
Je mehr Hierarchieebenen eine XML-Datei aufweist, umso komplexer und genauer ist die Beschreibung der Ressource.
Beispiel:
streng genommen ist ‚Eiffelturm‘ nicht das Bauwerk selbst sondern es handelt sich um eine Bezeichnung für dieses. Ebenso verhät es sich mit ‚Mona Lisa‘. Diese Vereinbarung kann in das Konzept einbezogen werden:
Es folgt eine Erweiterung der Instanz:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE bildersammlung SYSTEM "bild01.dtd">
<bildersammlung>
<name>Neue schöne Bilder</name>
<lokalisation url=http://www.bilder.de/>
<bild>
<titel>Mona Lisa vor dem Eiffelturm</titel>
<url>http://www.woauchimmer.de</url>
<person>
<bezeichnung>Mona Lisa</bezeichnung>
</person>
<bauwerk>
<bezeichnung>Eiffelturm</bezeichnung>
</bauwerk >
</bild>
<bild>
<titel>Ritter, Burgen, Adel</titel>
<url>http://www.beispielseite.de</url>
<person>
<bezeichnung>byzantinische Kaiserin</bezeichnung>
</person>
<person>
<bezeichnung>Ritter des 13.Jhd</bezeichnung>
</person>
<person>
<bezeichnung>fränkischer Edelmann</bezeichnung>
</person>
<bauwerk>
<bezeichnung>Wasserburg</bezeichnung>
</ bauwerk >
</bild>
<bild>
....
</bild>
</bildersammlung>
(Bildbeschreibungen zu Mona Lisa vor dem Eiffelturm und Ritter, Burgen, Adel)
DTD Attribute
Codierung der Attribute
<!ELEMENT bildersammlung (name?, lokalisation, bild+)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT lokalisation EMPTY>
<!ATTLIST lokalisation
url CDATA #IMPLIED
postal CDATA #IMPLIED>
<!ELEMENT bild (titel, url, abstract*, person+, bauwerk+)>
<!ELEMENT titel (#PCDATA)>
<!ELEMENT url (#PCDATA)>
<!ELEMENT abstract (#PCDATA)>
<!ELEMENT person (bezeichnung+)>
<!ELEMENT bauwerk (bezeichnung+)>
<!ELEMENT bezeichnung (#PCDATA)>
Enthält ein Element Attribute, so werden diese durch eine <!ATTLIST … > Definition festgelegt.
Sie legt zunächst fest, für welches Element eine Attributliste definiert wird. Danach folgen für jedes Attribut, das innerhalb dieses Elements verwendet werden soll, mindestens zwei, oft auch mehere Angaben, und zwar:
- Der Name des Attributes,
- sein Typ (CDATA = Character Data) und optional
- weitere Angaben, die zum Teil von verschiedenen Attributtypen erwartet werden; häufig aber auch Schlüsselwörter die vorschreiben, wie das Attribut verwendet werden soll. Über die Keywords REQUIRED (obligatorisch) und IMPLIED (optional) können die Verbindlichkeiten für Attribut-Zuweisungen in einem Element festgelegt werden. Das Attribut @identifier des Typs ID muss (#REQUIRED), das Attribut @zustand kann (#IMPLIED) im <bild>-Tag gesetzt werden.
Mittels der obigen DTD ist beispielsweise diese Instanz validierbar:
<!DOCTYPE bildersammlung SYSTEM "beispiel.dtd">
<bildersammlung>
<name>Neue schöne Bilder</name>
<lokalisation url=http://www.bilder.de
postal="Musterstadt"/>
<bild>
<titel>Mona Lisa vor dem Eiffelturm</titel>
<url>http://www.woauchimmer.de</url>
<abstract>Hier steht die Mona Lisa vor
dem Eiffelturm</abstract>
<person>
<bezeichnung>Mona Lisa</bezeichnung>
</person>
<bauwerk>
<bezeichnung>Eiffelturm</bezeichnung>
</bauwerk>
</bild>
<bild>
....
</bild>
<bild>
....
</bild>
</bildersammlung>
Validierung
Die eingereichten Aufgaben müssen wellformed und valid sein. Um das zu gewährleisten, müssen beide Dokumente zweimal überprüft werden:
Ist dies nicht der Fall, kann die Einreichung ab jetzt nicht mehr angenommen werden.
Zum Weiterlesen finden Sie auf den folgenden Unterseiten weitere Informationen: