Vorwort

Im Rahmen dieser Diplomarbeit wird die Implementierung eines XML-basierten Generators zur Erzeugung netzbasierter ¨

dem Generator ¨ uber eine einfach zu bedienendende, graphische Benutzeroberfl¨ ache Aufgabenstellungen, Arbeitsmaterialien, Hilfestellungen und Musterl¨ osungen ¨ jegliche Programmierkenntnisse eine ¨ aus selbst¨ andig eine Online- ¨ zur Verf¨ ugung gestellt werden kann. Die Fachhochschule Regensburg bietet im Rahmen der Virtuellen Hochschule Bayern (vhb) Online-Vorlesungen als zeit- und kostensparende Erg¨ anzung zu den Pr¨ asenzvorlesungen an. Ziel dabei ist u. a., durch den Einsatz moderner, didaktisch-methodischer Vermittlungstechniken einfach und intuitiv zu bedienende, multimediale Lernoberfl¨ achen anzubieten. Diese Lernoberfl¨ achen erm¨ oglichen die einfache Portierung technischen Wissens und die Vermittlung von Schl¨ usselqualifikationen, wie z. B. den Umgang mit dem Internet.

Prof. Dr. Csaba F¨ oldes ¨ uber den Einsatz der neuen Medien in der Lehre:

Die breite Nutzung von Multimedia wird k¨ unftig eine Aufwertung bestimm”

ter Disziplinen und wissenschaftlicher Denk- bzw. Blickrichtungen mit sich bringen, die bisher in dieser Sparte kaum eine Rolle gespielt haben, so etwa die wahrnehmungspsychologische Sicht (z. B. hinsichtlich der Gestaltung von Lernoberfl¨ achen).“ [1, S. 133]

Dabei ist es nicht minder notwenig, modernste Technik einzusetzen. Technologien wie das medienneutrale Datenformat XML und die Transformationssprache XSLT erlauben es, Weboberfl¨ achen zu erstellen, deren Inhalt, Struktur und Design strikt getrennt sind. Das Publishing Framework Cocoon erm¨ oglicht die automatisierte Generierung von statischen und dynamischen Webseiten, die z. B. mittels dynamischem PDF plattform- und browserunabh¨ angig korrekt dargestellt werden k¨ onnen. Die Hypertext Preprocessor Sprache PHP erm¨ oglicht die Implementierung dynamischer Contents und durch das XML-Parser-Toolkit den Zugriff auf XML-Strukturen. Diese Technologien erm¨ oglichen es, bei der Entwicklung von Weboberfl¨ achen das sog. ” Cross-Media-Publishing“ einzusetzen.

In dieser Arbeit werden die im Projekt verwendeten Technologien und deren Implementierung vorgestellt.

ii

Inhaltsverzeichnis

Vorwort   ii

1  Einf uhrung  1

1.1  Einleitung  1

1.2  Aufgabenstellung  3

1.2.1  Funktionale Anforderungen  4

1.2.2  Technische Anforderungen  4

1.2.3  Benutzerspezifische Anforderungen  4

1.3  Bisheriger L osungsansatz  5

1.4  Neuer L osungsansatz  5

1.5  Aufbau der Arbeit  6

2  Die Hypertext Preprocessor Sprache PHP  7

2.1  Geschichte  7

2.2  Die Aufgabe des Webservers  8

2.2.1  MIME-Typen  9

2.2.2  HTTP-Header  10

2.3  Kommunikation und HTTP-Methoden  10

2.4  Klassenkonzept  12

2.5  XML-Parser Toolkit  14

2.5.1  Erzeugen des Parsers  15

2.5.2  Parser-Optionen  15

2.5.3  Event Handler  16

iii

INHALTSVERZEICHNIS iv

3  XML  18

3.1  SGML  18

3.2  Definition von XML  20

3.3  Entwurfsziele und Vorteile  21

3.4  Stuktur von XML  22

3.4.1  Wohlgeformtheit  23

3.4.2  G ultigkeit  25

3.4.3  XML-Namespaces  26

3.5  XML-Parser  27

3.6  Verarbeitungs-Schnittstellen  28

3.6.1  JAXP  28

3.6.2  DOM  29

3.6.3  SAX  30

4  XSL/XSLT  32

4.1  Darstellung in HTML  32

4.2  Cascading Style Sheets  32

4.2.1  Formate und Eigenschaften  33

4.2.2  Browserkompatibilit at  34

4.3  Die Formatierungssprache XSL  35

4.4  XPath  37

4.4.1  Knotentypen  38

4.4.2  Achsen  39

4.4.3  Pr adikate  41

4.4.4  XPath-Funktionen  43

4.4.5  Zusammenfassung  43

4.5  XSL-Tranformation  44

4.5.1  Struktur  46

4.5.2  Templates  48

4.6  XSL(T)-Funktionen  50

4.7  Erzeugung von PDF-Dateien  51

4.8  XSL(T)-Verarbeitungsszenarien  51

INHALTSVERZEICHNIS v

5  Dynamisches PDF  52

5.1  Das PDF-Format  52

5.1.1  PDF-Viewer und PDF-Tools  53

5.1.2  PDF-Generatoren  54

5.2  PDFlib  55

5.3  PDFlib in PHP  55

5.4  Variable Datenbl ocke  59

5.5  Zusammenfassung  61

6  Das Publishing Framework Cocoon  62

6.1  Geschichte und Konzeption  62

6.2  Architektur  64

6.3  Komponentenmanagement  65

6.3.1  Logik-Komponenten  66

6.3.2  Verarbeitungs-Komponenten  66

6.3.3  Parser-Komponenten  66

6.4  Verarbeitungsprozess  67

6.4.1  Pipelines  67

6.4.2  Sitemaps  67

6.5  Die Skriptsprache XSP  70

6.6  Generierung  72

7  Projekt Teil 1: Implementierung XML-Generator  73

7.1   

Ubungsstruktur   74

7.2  Architektur des Generators  75

7.2.1  Modularisierung  76

7.2.2  Verlinkung  78

7.2.3  Datenhaltung  78

7.2.4  Die Generator-Klasse  79

7.3  XML-Generierung  81

INHALTSVERZEICHNIS vi

8  Projekt Teil 2: XSLT-Stylesheets zur PDF-Generierung  85

8.1  Block-Konzept  85

8.2  Stylesheet zur Step-Generierung  87

8.3  Stylesheets zur Men u-Generierung  89

8.3.1  Hauptmen u  89

8.3.2  Untermen u  90

8.3.3  Step-  

Ubersicht   91

8.4  PDF-Generierung  92

9  Projekt Teil 3: Implementierung Cocoon  93

9.1  Sitemaps  93

9.1.1  Kontext-Sitemap  93

9.1.2  Sub-Sitemap  94

9.2  Verzeichnisstruktur  97

9.3  Offline-Generierung  98

10  Zusammenfassung  100

A  XML-Schema  106

A.1  Listing index.xsd  106

A.2  Listing step.xsd  106

B  Generator  108

B.1  Listing index.php  108

B.2  Listing edit module.php  110

B.3  Listing edit chapter.php  111

B.4  Listing edit step.php  113

B.5  Listing tree.php  119

B.6  Listing top.html  120

B.7  Listing Frameset index.html  120

B  8 Listing CSS generator css  120

INHALTSVERZEICHNIS vii

C  XML-Strukturen  122

C.1  Beispiel-Listing Hauptmen u index.xml  122

C.2  Beispiel-Listing Untermen u index.xml  122

C.3  Beispiel-Listing Step-  

Ubersicht  index.xml  123

C.4  Beispiel-Listing Step step.xml  123

D  Stylesheets  124

D.1  Listing step 2pdf.xsl  124

D.2  Listing documents 2php.xsl  127

D.3  Listing menue 2php.xsl  128

D.4  Listing index 2pdf.xsl  129

D.5  Listing module index 2pdf.xsl  129

D.6  Listing chapter index 2pdf.xsl  130

D.7  Listing index redirect 2html.xsl  131

E  PDF-Generierung  132

E.1  Listing global page elements.inc  132

E.2  Listing make step.inc  133

E.3  Listing make menue.inc  136

E.4  Listing make document list.inc  138

E.5  Listing send page.inc  139

E.6  Listing redirect.php  139

F  Cocoon  141

F.1  Listing Pipeline in Kontext-Sitemap sitemap.xmap  141

F  2 Listing Sub-Sitemap sitemap xmap  141

Kapitel 1

Einf ¨ uhrung

1.1 Einleitung

Die Virtuelle Hochschule Bayern (vhb, http://www.vhb.org) hat in den letzten Jahren in Zusammenarbeit mit den Universit¨ aten und Fachhochschulen in Bayern ein Lernnetzwerk aufgebaut, welches den Studenten interaktive Online-Kurse als Erweiterung zu den ¨ ublichen

Pr¨ asenzvorlesungen zur Verf¨ ugung stellt. Die Hochschulen ¨ ubernahmen dabei die Tr¨ agerschaft der vhb und verantworten diese Online-Kurse v¨ ollig eigenst¨ andig. Bisher befinden sich neben 17 staatlichen Fachhochschulen auch zahlreiche weitere Universit¨ aten und Hochschulen in diesem Lernverbund.

Angeboten werden Kurse aus nahezu allen Fachbereichen, u. a. Informatik, Ingenieurwissenschaften, Lehramt, Wirtschafts- und Rechtswissenschaften oder Medizin. Die vhb arbeitet intensiv an einem weiteren Ausbau des Kursangebotes. [2]

F¨ ur den Studierenden lassen sich folgende Vorteile durch das Angebot erkennen:

• Virtuelle Vorlesungen sind weder orts- noch zeitgebunden.

• Steigerung der Qualit¨ at und Attraktivit¨ at der Lehre durch den Einsatz multimedialer Mittel

• Zeit- und ortsunabh¨ angige Kommunikation mit dem Dozenten

• Erfolgskontrolle und Einsch¨ atzung der eigenen Leistung

• Aneignung von Schl¨ usselqualifikationen durch die Nutzung dieses Lernmittels

F¨ ur den Lehrenden bieten virtuelle Vorlesungen folgende Vorteile:

• Flexiblere Zeitgestaltung, da Pr¨ asenzveranstaltungen gr¨ oßtenteils wegfallen

• Fortlaufende Erfolgskontrolle, z. B. wenn ¨ Ubungen abgegeben werden m¨ ussen

• Fortlaufende Einsch¨ atzung der Seminarziele und rasches Erkennen von defiziti¨ aren Wissensst¨ anden

1

1.1. EINLEITUNG 2

Die Lerntheorie von Konfuzius sagt:

Sage es mir, und ich vergesse es; zeige es mir, und ich erinnere mich; lass ”

es mich tun, und ich behalte es“ [3, S. 21]

Dass sich diese Theorie in der Realit¨ at best¨ atigt, zeigen die Fakten aus der Lernpsychologie:

Aus dem Diagramm l¨ asst sich folgendes ableiten: Das, was man selbst erarbeitet und selbst durchdacht hat, beh¨ alt man zu gut 100 %. Durch die Online-Kurse werden die Studenten dazu animiert, Thematiken eigenst¨ andig zu erforschen, Gedankeng¨ ange eigenst¨ andig zu studieren und ¨ Ubungsaufgaben selbst¨ andig zu l¨ osen. So bleiben nat¨ urlich mehr Inhalte h¨ angen als bei so mancher Vorlesung.

Neueste Informations- und Kommunikationstechnologien in der Lehre einzusetzen, ist ein weltweiter Trend. Der Begriff des ” E-Learning“ steht im Zentrum dieser Entwicklung. Die Definition von Vaughan Waller und Jim Wilson f¨ ur diesen Begriff lautet:

Definition 1.1 (E-Learning): ” E-Learning is the effective learning process

created by combining digitally delivered content with (learning) support and services.“ [5, S. 21]

E-Learning ist also die Kombination aus der zeit- und ortsunabh¨ angigen Vermittlung digitaler Inhalte und der Kommunikation mit dem Lehrenden.

Thomas Edison ¨ uber den Einsatz neuer Medien in der Lehre:

B¨ ucher werden in unseren Schulen bald ¨ uberfl¨ ussig sein. . . man kann jede ”

Art von menschlichem Wissen mit der neuen Technik lehren.“ [3, S. 3]

Die Fachhochschule Regensburg bietet seit geraumer Zeit solche E-Learning-Kurse an. Eine ¨ Ubersicht der Kurse kann unter http://vhb.fh-regensburg.de/ eingesehen werden (siehe Ab- bildung 1.2).

1.2. AUFGABENSTELLUNG 3

Das dieser Diplomarbeit vorausgehende Projekt wurde mit dem Ziel initiiert, eine Platt-form f¨ ur Online-Kurse zu entwickeln. Der Kurs ” BIO - Bildverarbeitung Interaktiv Online“

an der FH Regensburg fand nach seiner Einf¨ uhrung im Sommersemester 2003 starken Anklang bei den Studenten. Das war der Anlass, die dabei entstandenen Werkzeuge weiterzuentwickeln.

Die Ans¨ atze zur Verbesserung und Erweiterung der Ergebnisse des Projektes ” BIO“ werden im Folgenden n¨ aher erl¨ autert:

1.2 Aufgabenstellung

Bisher wurden den Studenten begleitend zu den Vorlesungen in unbestimmten Zeitabst¨ anden Materialien zur Verf¨ ugung gestellt, teilweise im Internet, teilweise auf Papier. Falls es ¨ uberhaupt Weboberfl¨ achen gab, fand man ¨ Ubungsmaterialien zu gegebener Zeit im Netz. Diese

Weboberfl¨ achen, zum Großteil HTML-basiert, bieten eine Reihe von Nachteilen:

• Die (Web-)Technik wird meistens dazu missbraucht, um teilweise schlecht aufbereitete Lernmaterialien zum Download anzubieten.

• Die Webseiten werden oft nicht sorgf¨ altig gepflegt, da der Aufwand zu groß ist.

• Die Darstellung der Webseiten ist oft browserabh¨ angig.

• Darstellung und Inhalt sind nicht getrennt (HTML).

• Es existieren verschiedene Oberfl¨ achenstrukturen und -gestaltungen, ein einheitliches Layout bzw. Konzept ist nicht zu erkennen.

• Druckausgaben sind oft sehr schlecht, da keine spezielle Druckversion existiert.

Das Ziel dieser Arbeit ist, diese Nachteile auszur¨ aumen und ein Konzept zu entwicklen, so dass der Dozent

1.2. AUFGABENSTELLUNG 4

uber eine trivial zu bedienende Schnittstelle ¨ • ¨ Ubungsstruktur und Aufgaben bereitstellen kann.

• getrennt vom Inhalt das Design festlegen kann.

• die ¨ Ubungsoberfl¨ achen automatisch generieren lassen kann.

• keinen komplizierten Quellcode zu Gesicht bekommt.

Die ¨ Ubungsaufgaben sollen direkt per Internet Browser interaktiv bearbeitet werden k¨ onnen. Somit wird die ¨ Ubungsoberfl¨ ache zum Interaktionsmedium und verliert auf diesem Wege das Image einer reinen, undurchsichtigen Distributionsplattform.

Die Interaktivit¨ at innerhalb des gesamten Kurses soll zudem durch den Einsatz von Multimedia sichergestellt werden, u. a. durch die Einbindung von Real-Audio-Sprachausgaben.

Welche Anforderungen an das System gestellt werden, l¨ asst sich wie folgt darstellen:

1.2.1 Funktionale Anforderungen

Das Online-Praktikum soll sich layoutm¨ aßig in den Kurs einbetten lassen und es soll innerhalb der Kursoberfl¨ ache aufgerufen werden k¨ onnen, ohne den Kursrahmen zu verlassen. Eine gegenseitige Verlinkung ¨ uber das Men¨ u ist ebenso erforderlich. Desweiteren soll das Layout der Kursoberfl¨ ache schnell und unkompliziert austauschbar sein.

1.2.2 Technische Anforderungen

Da die Kursoberfl¨ ache im Browser zu bedienen sein soll, wird der Einsatz eines Webservers notwendig. Verwendet wird ein kostenloser Apache 2 Server, auf den die Tomcat-Servlet-Engine in der Version 4.1 aufgesetzt wird. F¨ ur die automatisierte PDF-Generierung wird das Cocoon Publishing Framework in der Version 2.0.4 installiert. Im Webserver ist die TCP/IP-Architektur implementiert, als Kommunikations-Gateway dient das HTTP-Protokoll. Als serverseitige Scriptsprache kommt die Open Source Sprache PHP zum Einsatz. Zur PDF-Generierung wird eine aktuelle Version der PDFlib von Thomas Merz verwendet. Auf den Clients wird ein Browser-Client installiert, vorzugsweise der Microsoft Internet Explorer 6. Desweiteren muss auf der Client-Seite ein Plugin zur Anzeige von PDF-Dokumenten installiert sein.

1.2.3 Benutzerspezifische Anforderungen

Die Benutzerschnittstelle zur Erzeugung der ¨ Ubungsstruktur und der Aufgaben soll ¨ ubersichtlich und intuitiv zu bedienen sein. Zudem steht die Browserunabh¨ angigkeit und die Einhaltung eines einheitlichen Layouts im Vordergrund. Es erfolgt eine Zugangskontrolle beim Aufruf des Praktikumssystems.

Im Folgenden wird nun der L¨ osungsansatz des Vorg¨ anger-Projektes ” BIO - Interaktiv On- line“ vorgestellt:

1.3. BISHERIGER L ¨ OSUNGSANSATZ 5

1.3 Bisheriger L¨ osungsansatz

Um Layout und Inhalt zu trennen, wurde der Einsatz von XML gew¨ ahlt. XML dient als Meta-Ebene f¨ ur die gesamte ¨ Ubungs-Oberfl¨ ache. Ein Vorteil besteht u. a. darin, dass die Erstellung von XML-Code nicht an eine Anwendung gebunden ist, sondern ein XML-Dokument von verschiedenen Anwendungen verarbeitet werden kann. Nachteilig dabei ist, dass man die XML-Dateien manuell erstellen und auf Validit¨ at und Wohlgeformtheit pr¨ ufen muss.

Durch die Frage, wie der XML-Code dann weiterverarbeitet werden kann, kommt der Bruch zwischen Inhalt und Darstellung zur Erscheinung. Wie und womit man XML-Code weiterverarbeitet, bleibt dem Anwender ¨ uberlassen. Beim Projekt ” BIO“ setzte man auf die Weiterverarbeitung mit XSL/XSLT, um am Ende statische Dokumente erstellen zu k¨ onnen. Zudem wurden die Aufgaben mittels Formatting-Objects-Prozessor in PDF umgewandelt, um eine Printversion zu erzeugen.

Die ¨ Ubungsoberfl¨ ache selbst wurde in HTML und JavaScript entwickelt. Somit erkennt man einen Nachteil des Konzeptes: ¨ Uber einen Umweg werden Printversionen der browserabh¨ angig dargestellten Inhalte erzeugt.

Um Darstellung und Inhalte verkn¨ upfen zu k¨ onnen, wurde das auf Java-Servlet-Technologie basierte Publishing Framework ” Cocoon“ gew¨ ahlt. Cocoon ist ein Open-Source-Projekt der

Apache Software Foundation und erm¨ oglicht eine serverseitige, dynamische Transformation von XML in verschiedene Ausgabeformate, u. a. (X)HTML, WML und PDF. Durch diese Technik kann der Dozent einen Automatismus ausl¨ osen, der die komplette ¨ Ubungsoberfl¨ ache statisch erzeugt. [6]

1.4 Neuer L¨ osungsansatz

Im Rahmen dieser Arbeit wird die Idee der Trennung von Darstellung und Inhalt weitergef¨ uhrt, weshalb auch hier XML und XSLT zum Einsatz kommen. Allerdings wird nun eine Benutzeroberfl¨ ache in PHP entwickelt, mit der die XML-Dateien automatisch erstellt bzw. die Inhalte und die ¨ Ubungsstruktur festgelegt werden, so dass die XML-Erzeugung auch durch Laien m¨ oglich ist. Es wird dabei vorausgesetzt, dass die Aufgabenstellung im PDF-Format vorliegt bzw. die Unterlagen zu den einzelnen Aufgaben in beliebigen Formaten.

Die XSL-Stylesheets beinhalten ein Konzept zur statischen Erzeugung von PHP-Scripts als Ausgabemedium, die wiederum mittels PDFlib dynamisch PDF-Dateien erzeugen - die eigentliche Kursoberfl¨ ache. Durch die Verwendung der Block-Funktionen in Adobe Acrobat wird die darstellungsspezifische Austauschbarkeit gew¨ ahrleistet. Die ¨ Ubungsseiten werden

dynamisch blockweise gef¨ ullt, wodurch das Layout kursspezifisch durch Manipulierung der Blockgr¨ oßen und -positionen ver¨ andert werden kann. Das Design ist somit komplett austauschbar und die Darstellung ist durch die Verwendung des PDF-Plugins im Browser von diesem unabh¨ angig.

Der Dozent soll ¨ uber eine einzige Aktivierung den kompletten Kurs generieren k¨ onnen, ohne die Teile einzeln erstellen zu m¨ ussen. Dies erfolgt durch eine Abarbeitungsreihenfolge, die von Cocoon nach dem Aufruf der Konsolenanwendung (Command Line Interface, CLI) be- arbeitet wird.

1.5. AUFBAU DER ARBEIT 6

Der gesamte Erzeugungsprozess f¨ ur einen Kurs ist vom Betriebssystem unabh¨ angig. Sowohl Webserver, Komponenten als auch die erforderlichen Plugins sind f¨ ur nahezu alle Betriebssysteme verf¨ ugbar.

1.5 Aufbau der Arbeit

In den folgenden Kapiteln wird zuerst auf die verwendeten Technologien eingegangen. Danach folgt die Beschreibung der einzelnen Projektschritte.

Kapitel 1 Einf¨ uhrung und Aufgabenstellung

Kapitel 2 Die Hypertext Preprocessor Sprache PHP

Kapitel 3 XML

Kapitel 4 XSL/XSLT

Kapitel 5 Dynamisches PDF

Kapitel 6 Das Publishing Framework Cocoon

Kapitel 7 Projekt Teil 1: XML-Generator

Kapitel 8 Projekt Teil 2: XSL-Stylesheets zur PDF-Generierung

Kapitel 9 Projekt Teil 3: Implementierung Cocoon

Kapitel 10 Zusammenfassung

Kapitel 2

Die Hypertext Preprocessor Sprache

PHP

PHP steht umgangssprachlich f¨ ur ” PHP: Hypertext Preprocessor“, eine weitverbreitete Open Source Skriptsprache. PHP ¨ ahnelt von der Syntax her C/C++ bzw. Java oder Perl und besitzt

die F¨ ahigkeit, dynamische Webseiten zu generieren. PHP kann in HTML eingebettet werden, ¨ ahnlich wie ASP oder JavaScript. Wie ASP ist auch PHP eine serverseitige Skriptsprache, wobei der PHP-Code nicht auf dem Client ausgef¨ uhrt wird sondern der Client mit dem Server nur kommuniziert und Daten austauscht (siehe Abschnitt 2.3, S. 10).

2.1 Geschichte

Die Entwicklung von PHP begann anno 1995, als Rasmus Lerdorf einen Nachfolger f¨ ur das sog. PHP/FI geschaffen hatte. PHP/FI war eine Zusammenstellung von Perl Scripts, um die Zugriffe auf seine Homepage zu erfassen. Daher kam auch die Bezeichnung ” PHP“: Er nannte seine Sammlung eben ” Personal Home Page Tools“. Der Zusatz ” /FI“ bedeutete ” Forms

Interpreter“. Hier l¨ asst sich anmerken, dass es sich bei PHP bzw. seinem Vorg¨ anger PHP/FI um eine reine Interpretersprache handelt (wie JavaScript, nur Server-basiert).

PHP/FI war eine Alternative zu Perl, besaß ebenso Variablen, eine ¨ ahnliche Syntax und

konnte mit Formulardaten umgehen. PHP/FI wurde zwei Jahre sp¨ ater noch einmal ¨ uberarbeitet und bekam die Versionsnummer 2.0. Im Jahre 1997 waren laut Statistik ca. 500.000 Domains registriert und ca. 1 % davon nutzte bereits den PHP/FI-Nachfolger. Das Projekt war von Beginn an ein Open Source Projekt, so dass jedermann neue Komponenten beisteuerte.

Im gleichen Jahr begann die Entwicklung von PHP 3.0, eine komplett neu geschriebene, verbesserte und erweiterte Fassung von PHP/FI 2.0 mit einer objektorientierten Syntax. Andi Gutmans, Zeev Suraski und Rasmus Lerdorf erweiterten das alte PHP/FI um Komponenten zur Anbindung von Datenbanken und zus¨ atzlich um Protokolle, APIs (Application Programmers Interfaces) und die M¨ oglichkeit zur Einbindung von Zusatzmodulen (Extensions). Im Jahre 1998 lief PHP 3.0 bereits auf 10 % aller Webserver.

Im Mai 2000 wurde eine weitere ¨ Uberarbeitung von PHP freigegeben: PHP 4.0. Es besaß

7

2.2. DIE AUFGABE DES WEBSERVERS 8

einen komplett neu geschriebenen Kern, die sog. Zend Engine, die performanter lief als die alte. Zus¨ atzlich wurden neue Funktionen eingef¨ uhrt wie z. B. Sessions, eine Ausgabepufferung und verschiedene neue Sprachkonstrukte. PHP 4 wird st¨ andig erweitert und verbessert und ist zur Zeit auf ca. 20 % der Webserver installiert.

Momentan arbeitet man an der Entwicklung der Zend Engine 2.0, die eine Performance-Steigerung und neu entworfene Leistungsmerkmale implizieren soll. [7]

Die PHP-Scripts im Rahmen dieser Diplomarbeit wurden in PHP 4.3.4 entwickelt und sind aufw¨ artskompatibel zu zuk¨ unftigen Versionen von PHP.

In Abbildung 2.1 ist die Architektur von PHP dargestellt:

2.2 Die Aufgabe des Webservers

PHP unterscheidet sich von clientseitigen Sprachen wie JavaScript dadurch, dass der Code auf dem Server ausgef¨ uhrt wird. Das Einsehen von PHP-Code auf dem Client im Browser ist deshalb (zum Gl¨ uck) nicht m¨ oglich. Die Ausf¨ uhrung des PHP-Codes ¨ ubernimmt ein auf

dem Webserver installiert PHP-Interpreter bzw. -Prozessor (php.exe).

Der Markt bietet eine Reihe von unterschiedlichen Webservern mit unterschiedlichen Komplexit¨ aten und Features an. Der bekannteste Server ist der Apache HTTP Server [9]. Er ist kostenlos und lizenzfrei, seit der Version 2.0 extrem schnell und bietet ein großes Funktionsspektrum.

Konfiguriert wird der Server durch die Eintr¨ age in der Datei httpd.conf im conf-Verzeichnis. Hier wird unter anderem der PHP-Interpreter zur Verwendung mit dem Apache durch folgende Zeilen eingerichtet:

# Einbinden der Apache-internen PHP-Bibliothek, die die Verwendung # des Parser vorbereitet LoadFile "/webserver/apache/bin/php4ts.dll" LoadModule php4_module "/webserver/apache/bin/php4apache2.dll"

2.2. DIE AUFGABE DES WEBSERVERS 9

# Einrichtung eines Alias f¨ ur PHP mit Angabe des Pfades zum Parser ScriptAlias /php/ "/webserver/php/"

# Einrichtung eines MIME-Typs f¨ ur PHP

AddType application/x-httpd-php .php .php4 .php3 .phtml

# Hier erf¨ ahrt der Server, dass er den eben festgelegten MIME-Typ # mit PHP verarbeiten soll

Action application/x-httpd-php "/webserver/php/php.exe"

Der Server verwendet sog. ” MIME-Typen“ zur Verarbeitung unterschiedlicher Medienformate: [10]

2.2.1 MIME-Typen

MIME (Multipurpose Internet Mail Extensions) ist ein Schema zur Erkennung von Datentypen anhand standardisierter Typangaben. Es war urspr¨ unglich f¨ ur E-Mails gedacht, erwies sich aber nicht nur dazu als n¨ utzlich.

Bei der HTML-Programmierung st¨ oßt man bei manchen Elementen auf ein Attribut, welches die Angabe eines MIME-Typs erwartet, u. a. bei ^< form ^> , ^< object ^> und ^< script ^> . Dem Webserver ist ¨ uber die http.conf eine Liste genormter MIME-Typen bekannt, so dass der Server bei der Kommunkation mit Webseiten entscheiden kann, ob er den MIME-Typ akzeptiert oder nicht. Browser akzeptieren dagegen in der Regel fast alle MIME-Typen. Die Notation dieser Typangaben ist standardisiert, weshalb sich bei der Entwicklung von Anwendungen, die solche Typen explizit verwenden, die Beibehaltung der genormten Namen empfiehlt.

Ein MIME-Typ besteht aus zwei Teilen: Der Angabe eines Medientyps und - durch einen Schr¨ agstrich getrennt - der Angabe eines Untertyps. Folgende Medientypen sind bekannt:

image f¨ ur Grafiken

text f¨ ur Textdateien

video f¨ ur Videoclips

audio f¨ ur Soundateien

application f¨ ur Dateien, die nur von bestimmten Anwendungen verarbeitet werden (z. B. PDF)

multipart f¨ ur mehrteilige Dateien (beim Datei-Upload in HTML-Formularen)

model f¨ ur die Darstellung von mehrdimensionalen Strukturen

message f¨ ur Nachrichten

Server-eigene Subtypen werden mit ” x-“ vor der eigentlichen Subtyp-Bezeichnung notiert.

Somit ist nun klar, warum in obiger Konfigurationszeile der MIME-Typ application/x-httpdphp eingetragen wird und nicht application/php.

MIME-Typen k¨ onnen auch in einem HTTP-Header stehen. [10]

2.3. KOMMUNIKATION UND HTTP-METHODEN 10

2.2.2 HTTP-Header

Das W3C definiert das HTTP-Protokoll wie folgt:

Definition 2.2.2 (HTTP): ” The Hypertext Transfer Protocol (HTTP) is an

application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [...].“ [10]

Das HTTP-Protokoll ist ein generisches Protokoll f¨ ur die Kommunikation zwischen Clients und Servern. Wird im Browser auf der Clientseite eine Webseite angefordert, so wird diese Anforderung (Request) ¨ uber das HTTP-Protokoll (Port 80) an den Server geschickt (z. B. GET /index.html HTTP/1.1). Dieser Anfrage antwortet der Server mit einem Response. Beim Antworten sendet der Server eine Anfangsinformation, den sog. ” Header“, und die an-

geforderte Seite bzw. deren Inhalt. Der Header gibt dem Browser die Information, wie er die Daten anzeigen soll (z. B. eine PDF-Datei durch das dazugeh¨ orige Plugin, siehe Anhang E.5). [10]

Abbildung 2.2 stellt diesen Ablauf graphisch dar:

2.3 Kommunikation und HTTP-Methoden

In diesem Abschnitt wird detaillierter auf die Client-Server-Kommunikation in Bezug auf die Ausf¨ uhrung von PHP-Scripts und die M¨ oglichkeiten, wie der Browser Daten (z. B. Formulardaten) ¨ ubertragen kann, eingegangen.

Das Verfahren beim Aufruf einer PHP-Seite im Browser ist ¨ ahnlich wie in Abschnitt 2.2.2:

Der Client (Browser) baut zum Webserver eine HTTP-Verbindung ¨ uber Port 80 auf und

schickt eine Anfrage (Request), wenn eine PHP-Seite aufgerufen wird. Der Webserver verarbeitet nun den Request und f¨ uhrt das PHP-Script aus. Nach der Verarbeitung des Scripts wird der HTTP-Header und die erzeugte Ausgabe ¨ uber die HTTP-Verbindung zur¨ uck zum Client

gesendet (Respond). Es erfolgen weder Verbindungsauf- noch abbau, da das HTTP-Protokoll verbindungslos ist (Datagramm).

2.3. KOMMUNIKATION UND HTTP-METHODEN 11

Abbildung 2.3 zeigt die Kommunikation beim Aufruf einer PHP-Seite im Browser.

Jede Anfrage eines Clients beginnt mit der Angabe einer Methode. Folgende Methoden stehen zur Auswahl:

• GET: Mittels GET-Methode ¨ ubertragene Daten sind im URL des aufzurufenden Scripts

sichtbar. Sie werden in einer Umgebungsvariablen gespeichert und vom Server ausgelesen und verarbeitet (z. B. http://www.domain.de/datei.php?name=meinedatei).

• POST: ¨

Ubertr¨ agt man die Daten mittels POST, so werden die Daten direkt und ohne Caching an den Server ¨ Diese Methode findet in der Implementierung der PHP-Scripts in dieser Diplomarbeit Anwendung.

Beispiel:

Folgende HTML-Seite bietet ein Formular an, mit dem sich der Benutzer an einem System anmelden kann:

if ($_GET["submit"]) {

if (($_GET["username"]=="buchner") && ($_GET["password"]=="zugang")) echo "Zugang erlaubt!"; else echo "Zugang abgewiesen!"; } ?>

2.4. KLASSENKONZEPT 12

In diesem ersten Beispielcode wird die GET-Methode verwendet. Gibt der Benutzer die er-forderlichen Daten ein, schickt er diese durch Klicken auf ” Anmelden“ an den Server. Der

URL des aufgerufenen Scripts sieht folgendermaßen aus:

http://. . . /login.php?username=xxx&password=xxx

Die zu ¨ ubertragenden Daten sind somit f¨ ur den Client bzw. den Benutzer sichtbar. Standardm¨ aßig wird bei Formularauswertungen GET verwendet, weshalb die Angabe der Methode im Formular-Kopf nicht zwingend ist.

...

if (($_POST["username"]=="buchner") && ($_POST["password"]=="zugang")) echo "Zugang erlaubt!"; else echo "Zugang abgewiesen!"; } ?> ...

2.4. KLASSENKONZEPT 13

In der Objektorientierung wird man mit zwei Begriffen konfrontiert:

Polymorphie (sp¨ ate Bindung)

und

Vererbung.

Definition 2.4 (1. Polymorphie): ” Unter Polymorphie versteht man das Ver-

halten von objektorientierten Sprachen, die Signatur einer Funktion als Bestandteil des Funktionsnamens bei einem Aufruf zu betrachten.“ [11]

Als Signatur bezeichnet man den Return- und Parametertyp einer Funktion. Trotz des ausgereiften Klassenkonzeptes von PHP muss bei der Entwicklung leider auf Polymorphie verzichtet werden, da PHP keine explizite Deklaration von Return- und Parametertypen erfordert. Innerhalb einer Funktion muss der Variablentyp durch Typ-Funktionen abgefragt werden.

Definition 2.4 (2. Vererbung): ”

mente die Struktur und das Verhalten allgemeinerer Elemente ¨ [12]

Eine Klasse kann also Grundfunktionalit¨ aten von einer bereits existierenden Klasse ¨ ubernehmen, z. B. um diese zu ¨ uberschreiben. Vererbung ist in PHP implementiert und besitzt die gleiche Funktionalit¨ at wie in h¨ oheren Programmiersprachen, z. B. C++.

Das folgende Beispiel soll einen Einblick in die objektorientierte Programmierung von PHP geben:

class myClass { // Klassenvariable var $zahl1;

// Konstruktor

function myClass($zahl2) {

// Wird $zahl2 ¨ ubergeben, so wird diese intern gespeichert if ($zahl2) $this->zahl1 = $zahl2;

// Andernfalls wird die Klassenvariable mit 5 vorbelegt else $this->zahl1 = 5; }

// Klassenfunktion (bzw. -methode)

function berechnen($zahl3) {

// Gibt die Wurzel aus $zahl3 * $zahl1 zur¨ uck return sqrt($zahl3 * $this->zahl1); } }

2.5. XML-PARSER TOOLKIT 14

// myClass2 erbt alle Klassenvariablen und Methoden von myClass class myClass2 extends myClass {

// Diese Funktion wird ¨ uberschrieben, um nun das Produkt zu berechnen. // $zahl1 wird von myClass geerbt und steht in myClass2 zur Verf¨ ugung. function berechnen($zahl4) {

// Gibt das Produkt aus $zahl4 * $zahl1 zur¨ uck return $zahl4 * $this->zahl1; } }

$zahl2 = 6; $zahl3 = 6;

// Konstrukturaufruf, $zahl2 wird mit 6 vorbelegt

$myClass = new myClass($zahl2);

// Berechnung der Wurzel aus 6 * 6, der Funkt. berechnen() wird 6 ¨ ubergeben echo "Die Wurzel aus $zahl2 * $zahl3 ist: ". $myClass->berechnen($zahl3)."

"; // Ergebnis -> 6

$zahl4 = 5;

// Konstrukturaufruf ohne Vorbelegung, $zahl1 besitzt deshalb den Wert 5 $myClass2 = new myClass2();

// Berechnung des Produktes aus 5 * 5, der ¨ uberladenen Funktion berechnen() // wird 5 ¨ ubergeben

echo "Das Produkt aus ".$myClass2->zahl1." * $zahl4 ist: ". $myClass2->berechnen($zahl4)."

"; // Ergebnis -> 25 ?>

Die objektorientierte Programmierung findet bei der Implementierung des XML-Generators (siehe Kapitel 7) Anwendung.

2.5 XML-Parser Toolkit

PHP besitzt eine XML-Extension, die eine Erzeugung von XML-Parsern und die Definition von Handlern f¨ ur verschiedene XML-Ereignisse erm¨ oglicht. XML wird in Kapitel 3) ausf¨ uhrlich behandelt, weshalb in diesem Abschnitt nicht auf die Definition eingegangen wird.

Das XML-Parser Toolkit erlaubt das Parsen von XML-Dokumenten, nicht aber die Validierung (Kapitel 3.4.2). Der Parser erm¨ oglicht nur die Generierung von Ausgabestr¨ omen innerhalb der Event Handler. Es werden drei Zeichenkodierungen unterst¨ utzt:

• US-ASCII

• ISO-8859-1

• UTF-8

UTF-16 wird leider (noch) nicht unterst¨ utzt.

2.5. XML-PARSER TOOLKIT 15

Die Windows-Version von PHP unterst¨ utzt standardm¨ aßig diese XML-Extension, weshalb keine zus¨ atzlichen Extensions hinzugeladen werden m¨ ussen, um die Parser-Funktionen verwenden zu k¨ onnen. Es ist außerdem anzumerken, dass die Extension in der php.ini nicht deaktiviert werden kann, da kein Eintrag existiert.

In den folgenden Abschnitten werden die XML-Parser-Funktionen bzw. die Event Handler und deren Verwendung vorgestellt. Die Beschreibung orientiert sich an [8].

2.5.1 Erzeugen des Parsers

Der Parser wird durch folgenden Funktionsaufruf generiert:

$xml_parser = xml_parser_create();

Anschließend k¨ onnen die Optionen festgelegt werden.

2.5.2 Parser-Optionen

Jeder XML-Parser besitzt zwei Optionen, die je nach Bedarf nach dem Erzeugen des Parsers festlegt werden k¨ onnen:

Case-folding“ l¨ asst sich wiefolgt definieren:

”

Definition 2.5.2 (Case-folding): ”

dard as ’ a process applied to a sequence of characters, in which those identified as non-uppercase are replaced by their uppercase equivalents‘“. [8]

Festgelegt wird die Option durch die Funktion

bool xml_parse_set_option (resource parser, int option, mixed value),

wobei

Parser das Handle des XML-Parsers

Option die Optionskonstante (siehe Tabelle 2.1)

Value den Optionswert darstellen.

2.5. XML-PARSER TOOLKIT 16

2.5.3 Event Handler

In diesem Projekt werden nur zwei Event Handler verwendet, weshalb sich die detaillierte Darstellung auf folgende beschr¨ ankt:

xml_set_element_handler($xml_parser, "startElement", "endElement");

xml_set_character_data_handler($xml_parser, "characterData");

Tabelle 2.2 listet die zur Verf¨ ugung stehenden Event Handler auf:

Beide Handler erwarten die Namen der Handler-Funktionen ¹ als Parameter. Werden Elemente gehandled, so behandeln die Funktionen startElement und endElement den Anfang und das Ende eines Elementes (element node oder kurz node, z. B. ^< page ^> ).

¹ Die Funktionen, die den eigentlichen Text parsen.

2.5. XML-PARSER TOOLKIT 17

Im Projekt wird nur startElement verwendet. Der Zeichenhandler liest anschließend den textuellen Inhalt aus (text node, z. B. den Text ” Seite 1“ aus ^< page ^> Seite 1 ^< /page ^> ).

Die Event-Handler-Funktionen

function startElement($parser, $name, $attrs)

function characterData($parser, $data)

lesen den Namen, die Attribute und den textuellen Inhalt der Elemente aus:

startElement erwartet vom Handler die Referenz des Parsers, den Namen des aktuellen Elementes und ein Array mit den Attributen des Feldes (z. B. ^< page id=1 ^> ).

characterData erwartet vom Handler die Referenz des Parsers und den textuellen Inhalt des aktuellen Nodes.

Folgender Beispielcode parst eine XML-Struktur und gibt den Titel des element nodes und des text nodes aus:

$file = "struktur.xml"; // XML-Struktur

// Lese den Start-Tag aus bzw. seinen Namen

function startElement($parser, $name, $attrs) { echo "Node: $name
"; }

// Lese den Inhalt des Nodes aus

function characterData($parser, $data) { echo "$data
"; }

// Erzeuge einen neuen XML-Parser

$xml_parser = xml_parser_create();

// Lege die Handler-Funktionen bzw. deren Namen fest

xml_set_element_handler($xml_parser, "startElement", "endElement"); xml_set_character_data_handler($xml_parser, "characterData");

// ¨ Offne die XML-Datei und lese sie aus falls m¨ oglich

if (!($fp = fopen($file, "r"))) die("could not open XML input");

while ($data = fread($fp, 4096))

{

if (!xml_parse($xml_parser, $data, feof($fp))) {

die(sprintf("XML error: %s at line %d", xml_error_string(xml_get_error_code($xml_parser)), xml_get_current_line_number($xml_parser))); } }

// Parser freigeben

xml_parser_free($xml_parser); ?>

Kapitel 3 behandelt nun das strukturierte Datenformat XML in seinen Einzelheiten.

Kapitel 3

XML

XML (eXtensible Markup ¹ Language) ist eine von SGML abgeleitete Meta ² -Sprache f¨ ur das Definieren von Dokumenttypen. Genauer gesagt liefert XML die Regeln, die beim Definieren von Dokumenttypen angewendet werden.

3.1 SGML

Bei der Standard Generalized Markup Language (SGML) handelt es sich um eine Art Programmiervereinbarung f¨ ur Systeme, die die Definition bestimmter Schl¨ usselw¨ orter erlauben, mit denen die Bedeutung z.B. von Dokumentenabschnitten festgelegt wird. Diese Bedeutung (Markup) ist keine Formatierungsanweisung (prozedurales Markup) sondern eine Klassifizierung, die eine Weiterverarbeitung beliebiger Art erm¨ oglicht (deskriptives Markup). Die Grundidee einer solchen Auszeichnungssprache ist die Trennung von Struktur ˆ und Inhalt eines Dokumentes.

SGML wurde in den 70er Jahren von Ray Lorie, Chales Goldfarb und Ed Mosher (IBM) als Nachfolger der 1969 verabschiedeten Generalized Markup Language (GML) entwickelt. Erst 1996 wurde SGML zum ISO ³ -Standard 8879 erkl¨ art.

SGML ist keine vordefinierte Menge von Tags zum Markieren von Textpassagen, wie das vielleicht bei L ^A T E X zu sehen ist. L ^A T E X ist ein Satzsystem, bei dem das Aussehen des Dokumentes im ausgedruckten Zustand im Vordergrund steht (die vorliegende Arbeit wurde in L ^A T E X geschrieben). Dazu benutzt L ^A T E X u.a. bestimmte Zeichen (z. B. geschweifte Klammern), welche nat¨ urlich unterschiedlich interpretiert werden k¨ onnen, wenn das Dokument auf einen anderen Rechner ¨ ubertragen wird. SGML l¨ ost sich von diesen Sonderzeichen-Abh¨ angigkeiten. Außerdem beschreibt SGML nicht das Aussehen des Textes, sondern erlaubt die Beschreibung seiner strukturellen Komposition. SGML strukturiert und kennzeichnet Inhaltselemente eines Dokuments in Form von Text. Mit Hilfe von festgelegten Markup-Anweisungen (Markierungen wie z. B. Title, Chapter, Footnote) kann ein Dokument strukturiert und seine Inhaltselemente (Text, Bilder, Tabellen) k¨ onnen bezeichnet werden.

¹ Markup Language wird im deutschen Sprachgebrauch auch als ” Auszeichnungssprache“ bezeichnet.

² Meta (griech.) bedeutet ” ¨ uber, oberhalb“. Als Meta-Sprachen werden ¨ ubergeordnete Sprachen bezeichnet.

³ ISO = International Organization for Standardization - http://www.iso.org.

18

3.1. SGML 19

Ein Beispiel f¨ ur ein mit SGML definiertes ” Tag“ w¨ are

Die Grundprinzipien von SGML sind:

• Trennung von Inhalt und Struktur

• Hard- und Softwareunabh¨ angige Portabilit¨ at zwischen Publishing-Systemen

• Einbettung von Multimedia (Sprache, Animationen, Bilder)

• Einfache Notation

• Kompatibilit¨ at zwischen den Dokumentenformaten

Zur Definition konkreter Dokumenttypen in SGML werden sog. Document Type Definitions (DTDs) verwendet (siehe Abschnitt 3.4.2). Tim Barners Lee verwendete 1989 ein Subset dieser DTDs und vereinte SGML-Elemente mit einfachen Stylesheets und der Idee, auf den Seiten Hyperlinks zu verwenden. Somit war die Hypertext Markup Language (HTML) geboren, die im World Wide Web zum Standard geworden ist. Mit der Version 4.0 bekam HTML im Jahre 1997 erstmals eine standardisierte DTD, die vom W3C angenommen wurde. Genaugenommen gibt es drei DTDs:

• Eine strenge (strict) DTD,

• eine r¨ uckblickende (transitional) DTD und

• eine DTD f¨ ur Framesets (frameset).

Den DTD-Typ kann man in der Pr¨ aamel einer HTML-Seite einsehen:

bzw.

bzw.

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Es gab nun eine Trennung zwischen Inhalt und Struktur eines Dokumentes. Allerdings hat HTML einen wesentlichen Nachteil: Inhalt und Design sind fest miteinander verbunden. Es gab bisher keine M¨ oglichkeit, das Design auszutauschen, ohne die ganze HTML-Datei umzuschreiben bzw. zu ¨ andern. Um 1995 wurde ein Design-Standard eingef¨ uhrt, die Cascading Style Sheets (CSS), der es erlaubte, das Layout einer Seite getrennt vom Inhalt zu formatieren. Dieser Standard existiert bis heute, jedoch f¨ uhrt er auch nicht 100%ig zum gew¨ unschten Erfolg.

Man arbeitete weiterhin an einer L¨ osung, mit der man SGML auf einfachere Weise jeder- mann zug¨ anglich machen konnte, ohne Flexibilit¨ atseinbußen in Kauf zu nehmen. So entstand

3.2. DEFINITION VON XML 20

die Auszeichnungssprache XML als Teilmenge von SGML mit vereinfachter Komposition.

Das World Wide Web Consortium (W3C) defininiert XML in seiner Empfehlung wie folgt:

3.2 Definition von XML

Definition 3.2 (XML): ” Extensible Markup Language, abbreviated XML, describes a class of data objects called XML documents and partially describes the behavior of computer programs which process them.“ [13]

XML teilt ein Dokument in 3 Bestandteile: Stuktur, Informationen und Inhalt (siehe Abbildung 3.2).

Die Entwicklung von XML aus den GML/SGML-Standards l¨ asst sich so darstellen:

3.3. ENTWURFSZIELE UND VORTEILE 21

Abbildung 3.3 zeigt die Einbettung von XML in SGML:

3.3 Entwurfsziele und Vorteile

Die 10 Entwurfsziele f¨ ur XML werden in der W3C-Recommendation f¨ ur XML 1.0 wie folgt dargestellt: [13]

• XML shall be straightforwardly usable over the Internet.

3.4. STUKTUR VON XML 22

• XML shall support a wide variety of applications.

• XML shall be compatible with SGML.

• It shall be easy to write programs which process XML documents.

• The number of optional features in XML is to be kept to the absolute minimum, ideally zero.

• XML documents should be human-legible and reasonably clear.

• The XML design should be prepared quickly.

• The design of XML shall be formal and concise.

• XML documents shall be easy to create.

• Terseness in XML markup is of minimal importance.

Diese Entwurfsziele wurden von der XML Working Group (urspr¨ unglich bekannt als SGML Editoral Review Board) unter der Schirmherrschaft des W3C aufgestellt.

XML bietet somit alles, was die Entwickler immer forderten. Dadurch er¨ offnen sich f¨ ur das World Wide Web v¨ ollig neue M¨ oglichkeiten. Aber nicht nur f¨ ur das WWW wird XML zum Standard: Man hat erkannt, dass sich XML auch f¨ ur viele weitere Anwendungsbereiche eignet, wie z. B. als Datenaustauschformat f¨ ur Software.

XML bietet folgende Vorteile:

• XML ist international.

• XML l¨ asst sich strukturieren.

• XML-Dokumente lassen sich zusammensetzen.

• XML kann als Datencontainer dienen.

• XML bietet Flexibilit¨ at.

• XML bietet eine einfache Syntax.

• XML bietet Standardformate.

3.4 Stuktur von XML

Wie bereits erw¨ ahnt, trennt XML Inhalt und Darstellung. Deshalb stellt die Auszeichnung durch XML auch nicht die Gestaltung dar, sondern nur die inhaltliche Bedeutung bzw. die Strukturierung des Inhalts.

Jedex XML-Dokument besitzt eine logische und eine physische Struktur:

• Logisch: ” Each XML document contains one or more elements, the boundaries of which are either delimited by start-tags and end-tags, or, for empty elements, by an empty-element tag. Each element has a type, identified by name, sometimes called its generic identifier‘ (GI), and MAY have a set of attribute specifications.“ [13, 3.] ’ • Physisch: ” An XML document may consist of one or many storage units. These are called entities; they all have content and are all (except for the document entity and the external DTD subset) identified by entity name.“ [13, 4.]