Implementierung eines XML-basierten Generators für Online-Praktika


Tesis, 2004

151 Páginas, Calificación: 1,00


Extracto


Inhaltsverzeichnis

Vorwort

1 Einfuhrung
1.1 Einleitung
1.2 Aufgabenstellung
1.2.1 Funktionale Anforderungen
1.2.2 Technische Anforderungen
1.2.3 Benutzerspezifische Anforderungen
1.3 Bisheriger Lösungsansatz
1.4 Neuer Lösungsansatz
1.5 Aufbau der Arbeit

2 Die Hypertext Preprocessor Sprache PHP
2.1 Geschichte
2.2 Die Aufgabe des Webservers
2.2.1 MIME-Typen
2.2.2 HTTP-Header
2.3 Kommunikation und HTTP-Methoden
2.4 Klassenkonzept
2.5 XML-Parser Toolkit
2.5.1 Erzeugen des Parsers
2.5.2 Parser-Optionen
2.5.3 Event Handler

3 XML
3.1 SGML
3.2 Definition von XML
3.3 Entwurfsziele und Vorteile
3.4 Stuktur von XML
3.4.1 Wohlgeformtheit
3.4.2 Gültigkeit
3.4.3 XML-Namespaces
3.5 XML-Parser
3.6 Verarbeitungs-Schnittstellen
3.6.1 JAXP
3.6.2 DOM
3.6.3 SAX

4 XSL/XSLT
4.1 Darstellung in HTML
4.2 Cascading Style Sheets
4.2.1 Formate und Eigenschaften
4.2.2 Browserkompatibilität
4.3 Die Formatierungssprache XSL
4.4 XPath
4.4.1 Knotentypen
4.4.2 Achsen
4.4.3 Prädikate
4.4.4 XPath-Funktionen
4.4.5 Zusammenfassung
4.5 XSL-Tranformation
4.5.1 Struktur
4.5.2 Templates
4.6 XSL(T)-Funktionen
4.7 Erzeugung von PDF-Dateien
4.8 XSL(T)-Verarbeitungsszenarien

5 Dynamisches PDF
5.1 Das PDF-Format
5.1.1 PDF-Viewer und PDF-Tools
5.1.2 PDF-Generatoren
5.2 PDFlib
5.3 PDFlib in PHP
5.4 Variable Datenblöcke
5.5 Zusammenfassung

6 Das Publishing Framework Cocoon
6.1 Geschichte und Konzeption
6.2 Architektur
6.3 Komponentenmanagement
6.3.1 Logik-Komponenten
6.3.2 Verarbeitungs-Komponenten
6.3.3 Parser-Komponenten
6.4 Verarbeitungsprozess
6.4.1 Pipelines
6.4.2 Sitemaps
6.5 Die Skriptsprache XSP
6.6 Generierung

7 Projekt Teil 1: Implementierung XML-Generator
7.1 Übungsstruktur
7.2 Architektur des Generators
7.2.1 Modularisierung
7.2.2 Verlinkung
7.2.3 Datenhaltung
7.2.4 Die Generator-Klasse
7.3 XML-Generierung

8 Projekt Teil 2: XSLT-Stylesheets zur PDF-Generierung
8.1 Block-Konzept
8.2 Stylesheet zur Step-Generierung
8.3 Stylesheets zur Menü-Generierung
8.3.1 Hauptmenü
8.3.2 Untermenü
8.3.3 Step-Übersicht
8.4 PDF-Generierung

9 Projekt Teil 3: Implementierung Cocoon
9.1 Sitemaps
9.1.1 Kontext-Sitemap
9.1.2 Sub-Sitemap
9.2 Verzeichnisstruktur
9.3 Offline-Generierung

10 Zusammenfassung

A XML-Schema
A.1 Listing index.xsd
A.2 Listing step.xsd

B Generator
B.1 Listing index.php
B.2 Listing edit module.php
B.3 Listing edit chapter.php
B.4 Listing edit step.php
B.5 Listing tree.php
B.6 Listing top.html
B.7 Listing Frameset index.html
B.8 Listing CSS generator.css

C XML-Strukturen
C.1 Beispiel-Listing Hauptmenü index.xml
C.2 Beispiel-Listing Untermenü index.xml
C.3 Beispiel-Listing Step-Übersicht index.xml
C.4 Beispiel-Listing Step step.xml

D Stylesheets
D.1 Listing step 2pdf.xsl
D.2 Listing documents 2php.xsl
D.3 Listing menue 2php.xsl
D.4 Listing index 2pdf.xsl
D.5 Listing module index 2pdf.xsl
D.6 Listing chapter index 2pdf.xsl
D.7 Listing index redirect 2html.xsl

E PDF-Generierung
E.1 Listing global page elements.inc
E.2 Listing make step.inc
E.3 Listing make menue.inc
E.4 Listing make document list.inc
E.5 Listing send page.inc
E.6 Listing redirect.php

F Cocoon
F.1 Listing Pipeline in Kontext-Sitemap sitemap.xmap
F.2 Listing Sub-Sitemap sitemap.xmap

Kapitel 1

Einfuhrung

1.1 Einleitung

Die Virtuelle Hochschule Bayern (vhb, http://www.vhb.org ) hat in den letzten Jahren in Zusammenarbeit mit den Universitäten und Fachhochschulen in Bayern ein Lernnetzwerk aufgebaut, welches den Studenten interaktive Online-Kurse als Erweiterung zu den üblichen Präsenzvorlesungen zur Verfügung stellt. Die Hochschulen übernahmen dabei die Trägerschaft der vhb und verantworten diese Online-Kurse völlig eigenständig. Bisher befinden sich neben 17 staatlichen Fachhochschulen auch zahlreiche weitere Universitäten und Hochschulen in diesem Lernverbund.

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

Für den Studierenden lassen sich folgende Vorteile durch das Angebot erkennen:

- Virtuelle Vorlesungen sind weder ortsnoch zeitgebunden.
- Steigerung der Qualität und Attraktivität der Lehre durch den Einsatz multimedialer Mittel
- Zeitund ortsunabhängige Kommunikation mit dem Dozenten
- Erfolgskontrolle und Einschätzung der eigenen Leistung
- Aneignung von Schlüsselqualifikationen durch die Nutzung dieses Lernmittels

Für den Lehrenden bieten virtuelle Vorlesungen folgende Vorteile:

- Flexiblere Zeitgestaltung, da Präsenzveranstaltungen größtenteils wegfallen
- Fortlaufende Erfolgskontrolle, z. B. wenn Übungen abgegeben werden müssen
- Fortlaufende Einschätzung der Seminarziele und rasches Erkennen von defizitiären Wissensständen

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ät bestätigt, zeigen die Fakten aus der Lernpsychologie:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.1: Fakten aus der Lernpsychologie [4, S. 3]

Aus dem Diagramm lässt sich folgendes ableiten: Das, was man selbst erarbeitet und selbst durchdacht hat, behält man zu gut 100 %. Durch die Online-Kurse werden die Studenten dazu animiert, Thematiken eigenständig zu erforschen, Gedankengänge eigenständig zu studieren und Übungsaufgaben selbständig zu lösen. So bleiben natürlich mehr Inhalte hängen als bei so mancher Vorlesung.

Neueste Informationsund 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ür diesen Begriff lautet:

Definition 1.1 (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 zeitund ortsunabhängigen Vermittlung digitaler Inhalte und der Kommunikation mit dem Lehrenden.

Thomas Edison über den Einsatz neuer Medien in der Lehre:

Bücher werden in unseren Schulen bald überflüssig 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 Übersicht der Kurse kann unter http://vhb.fh-regensburg.de/ eingesehen werden (siehe Abbildung 1.2).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.2: vhb-Kurse der FH Regensburg

Das dieser Diplomarbeit vorausgehende Projekt wurde mit dem Ziel initiiert, eine Platt form für Online-Kurse zu entwickeln. Der Kurs BIO -Bildverarbeitung Interaktiv Online“ an der FH Regensburg fand nach seiner Einführung im Sommersemester 2003 starken An klang bei den Studenten. Das war der Anlass, die dabei entstandenen Werkzeuge weiterzuentwickeln.

Die Ansätze zur Verbesserung und Erweiterung der Ergebnisse des Projektes ” “ werden im Folgenden näher erläutert:

1.2 Aufgabenstellung

Bisher wurden den Studenten begleitend zu den Vorlesungen in unbestimmten Zeitabständen Materialien zur Verfügung gestellt, teilweise im Internet, teilweise auf Papier. Falls es überhaupt Weboberflächen gab, fand man Übungsmaterialien zu gegebener Zeit im Netz. Diese Weboberflächen, 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ältig gepflegt, da der Aufwand zu groß ist.
- Die Darstellung der Webseiten ist oft browserabhängig.
- Darstellung und Inhalt sind nicht getrennt (HTML).
- Es existieren verschiedene Oberflächenstrukturen 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äumen und ein Konzept zu entwicklen, so dass der Dozent

- über eine trivial zu bedienende Schnittstelle Übungsstruktur und Aufgaben bereitstellen kann.
- getrennt vom Inhalt das Design festlegen kann.
- die Übungsoberflächen automatisch generieren lassen kann.
- keinen komplizierten Quellcode zu Gesicht bekommt.

Die Übungsaufgaben sollen direkt per Internet Browser interaktiv bearbeitet werden können. Somit wird die Übungsoberfläche zum Interaktionsmedium und verliert auf diesem Wege das Image einer reinen, undurchsichtigen Distributionsplattform.

Die Interaktivität 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ässt sich wie folgt darstellen:

1.2.1 Funktionale Anforderungen

Das Online-Praktikum soll sich layoutmäßig in den Kurs einbetten lassen und es soll innerhalb der Kursoberfläche aufgerufen werden können, ohne den Kursrahmen zu verlassen. Eine gegenseitige Verlinkung über das Menü ist ebenso erforderlich. Desweiteren soll das Layout der Kursoberfläche schnell und unkompliziert austauschbar sein.

1.2.2 Technische Anforderungen

Da die Kursoberfläche 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ür 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 Übungsstruktur und der Aufgaben soll übersichtlich und intuitiv zu bedienen sein. Zudem steht die Browserunabhängigkeit und die Einhaltung eines einheitlichen Layouts im Vordergrund. Es erfolgt eine Zugangskontrolle beim Aufruf des Praktikumssystems.

Im Folgenden wird nun der Lösungsansatz des Vorgänger-Projektes ” Interaktiv On line“ vorgestellt:

1.3 Bisheriger Lösungsansatz

Um Layout und Inhalt zu trennen, wurde der Einsatz von XML gewählt. XML dient als Meta- Ebene für die gesamte Übungs-Oberfläche. 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ät und Wohlgeformtheit prüfen 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 weiter verarbeitet, bleibt dem Anwender überlassen. Beim Projekt ” “ setzte man auf die Weiter- BIO önnen. Zudem verarbeitung mit XSL/XSLT, um am Ende statische Dokumente erstellen zu k wurden die Aufgaben mittels Formatting-Objects-Prozessor in PDF umgewandelt, um eine Printversion zu erzeugen.

Die Übungsoberfläche selbst wurde in HTML und JavaScript entwickelt. Somit erkennt man einen Nachteil des Konzeptes: Über einen Umweg werden Printversionen der browserabhängig dargestellten Inhalte erzeugt.

Um Darstellung und Inhalte verknüpfen zu können, wurde das auf Java-Servlet-Technologie basierte Publishing Framework Cocoon“ gewählt. Cocoon ist ein Open-Source-Projekt der Apache Software Foundation ” ermöglicht 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ösen, der die komplette Übungsoberfläche statisch erzeugt. [6]

1.4 Neuer Lösungsansatz

Im Rahmen dieser Arbeit wird die Idee der Trennung von Darstellung und Inhalt weitergeführt, weshalb auch hier XML und XSLT zum Einsatz kommen. Allerdings wird nun eine Benutzeroberfläche in PHP entwickelt, mit der die XML-Dateien automatisch erstellt bzw. die Inhalte und die Übungsstruktur festgelegt werden, so dass die XML-Erzeugung auch durch Laien möglich 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äche. Durch die Verwendung der Block-Funktionen in Adobe Acrobat wird die darstellungsspezifische Austauschbarkeit gewährleistet. Die Übungsseiten werden dynamisch blockweise gefüllt, wodurch das Layout kursspezifisch durch Manipulierung der Blockgrößen und -positionen verändert werden kann. Das Design ist somit komplett austauschbar und die Darstellung ist durch die Verwendung des PDF-Plugins im Browser von diesem unabhängig.

Der Dozent soll über eine einzige Aktivierung den kompletten Kurs generieren können, ohne die Teile einzeln erstellen zu müssen. Dies erfolgt durch eine Abarbeitungsreihenfolge, die von Cocoon nach dem Aufruf der Konsolenanwendung (Command Line Interface, CLI) bearbeitet wird.

Der gesamte Erzeugungsprozess für einen Kurs ist vom Betriebssystem unabhängig. Sowohl Webserver, Komponenten als auch die erforderlichen Plugins sind für nahezu alle Betriebssysteme verfügbar.

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ührung 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ür ” Hypertext Preprocessor“, eine weitverbreitete Open Source Skriptsprache. PHP ähnelt von der Syntax her C/C++ bzw. Java oder Perl und besitzt die Fähigkeit, dynamische Webseiten zu generieren. PHP kann in HTML eingebettet werden, ähnlich wie ASP oder JavaScript. Wie ASP ist auch PHP eine serverseitige Skriptsprache, wobei der PHP-Code nicht auf dem Client ausgeführt 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ür 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 nann ” te seine Sammlung eben Personal Home Page Tools“. Der Zusatz

” /FI“ bedeutete ” Forms ” Interpreter“. Hier lässt sich anmerken, dass es sich bei PHP bzw. seinem Vorgänger PHP/FI um eine reine Interpretersprache handelt (wie JavaScript, nur Server-basiert).

PHP/FI war eine Alternative zu Perl, besaß ebenso Variablen, eine ähnliche Syntax und konnte mit Formulardaten umgehen. PHP/FI wurde zwei Jahre später noch einmal überarbeitet 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ätzlich um Protokolle, APIs (Application Programmers Interfaces) und die Möglichkeit zur Einbindung von Zusatzmodulen (Extensions). Im Jahre 1998 lief PHP 3.0 bereits auf 10 % aller Webserver.

Im Mai 2000 wurde eine weitere Überarbeitung von PHP freigegeben: PHP 4.0. Es besaß 7 einen komplett neu geschriebenen Kern, die sog. Zend Engine, die performanter lief als die alte. Zusätzlich wurden neue Funktionen eingeführt wie z. B. Sessions, eine Ausgabepufferung und verschiedene neue Sprachkonstrukte. PHP 4 wird ständig 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ärtskompatibel zu zukünftigen Versionen von PHP.

In Abbildung 2.1 ist die Architektur von PHP dargestellt:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Architektur von PHP [8]

2.2 Die Aufgabe des Webservers

PHP unterscheidet sich von clientseitigen Sprachen wie JavaScript dadurch, dass der Code auf dem Server ausgeführt wird. Das Einsehen von PHP-Code auf dem Client im Browser ist deshalb (zum Glück) nicht möglich. Die Ausführung des PHP-Codes übernimmt ein auf dem Webserver installiert PHP-Interpreter bzw. -Prozessor (php.exe).

Der Markt bietet eine Reihe von unterschiedlichen Webservern mit unterschiedlichen Komplexitäten 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äge 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"

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

# Einrichtung eines MIME-Typs für PHP

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

# Hier erfährt 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ünglich für E-Mails gedacht, erwies sich aber nicht nur dazu als nützlich.

Bei der HTML-Programmierung stöß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 über 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ägstrich getrennt – der Angabe eines Untertyps. Folgende Medientypen sind bekannt:

image für Grafiken text für Textdateien video für Videoclips audio für Soundateien

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

multipart für mehrteilige Dateien (beim Datei-Upload in HTML-Formularen)

model für die Darstellung von mehrdimensionalen Strukturen

message für Nachrichten

Server-eigene Subtypen werden mit x-“ vor der eigentlichen Subtyp-Bezeichnung notiert. Somit ist nun klar, warum in obiger ” der MIME-Typ application/x-httpd php eingetragen wird und nicht application/php.

MIME-Typen können auch in einem HTTP-Header stehen. [10]

2.2.2 HTTP-Header

Das W3C definiert das HTTP-Protokoll wie folgt:

Definition 2.2.2 (HTTP):

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ür die Kommunikation zwischen Clients und Servern. Wird im Browser auf der Clientseite eine Webseite angefordert, so wird diese Anforderung (Request) über 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.

die

Beim Antworten sendet der Server eine Anfangsinformation, den sog. Header“, und die angeforderte Seite bzw. deren Inhalt. Der Header gibt dem Browser ” Information, wie er

die Daten anzeigen soll (z. B. eine PDF-Datei durch das dazugehörige Plugin, siehe Anhang E.5). [10]

Abbildung 2.2 stellt diesen Ablauf graphisch dar:

Abbildung 2.2: HTTP-Request [10]

2.3 Kommunikation und HTTP-Methoden

In diesem Abschnitt wird detaillierter auf die Client-Server-Kommunikation in Bezug auf die Ausführung von PHP-Scripts und die Möglichkeiten, wie der Browser Daten (z. B. Formulardaten) übertragen kann, eingegangen.

Das Verfahren beim Aufruf einer PHP-Seite im Browser ist ähnlich wie in Abschnitt 2.2.2: Der Client (Browser) baut zum Webserver eine HTTP-Verbindung über Port 80 auf und schickt eine Anfrage (Request), wenn eine PHP-Seite aufgerufen wird. Der Webserver verarbeitet nun den Request und führt das PHP-Script aus. Nach der Verarbeitung des Scripts wird der HTTP-Header und die erzeugte Ausgabe über die HTTP-Verbindung zurück zum Client gesendet (Respond). Es erfolgen weder Verbindungsaufnoch abbau, da das HTTP-Protokoll verbindungslos ist (Datagramm).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: Verarbeitung eines PHP-Scripts

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 übertragene 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: Überträgt man die Daten mittels POST, so werden die Daten direkt und ohne Caching an den Server übertragen. Die Daten sind somit für den Client nicht sichtbar. 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:

Abbildung in dieser Leseprobe nicht enthalten

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

URL des aufgerufenen Scripts sieht folgendermaßen aus: ”

h ttp://. . . /login.php?username=xxx&password=xxx

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

Abbildung in dieser Leseprobe nicht enthalten

Erfolgt die Auswertung des Formulars mittels POST, so wird der Inhalt direkt übertragen und die Eingaben sind im URL nicht sichtbar:

h ttp://. . . /login.php

In der Konfigurationsdatei von PHP kann festgelegt werden, ob globale Variablen verwendet werden dürfen. Ist diese Funktion deaktiviert, so können die gesendeten Daten nur über sog. GET- und POST-Arrays abgerufen werden ($ HTTP GET VARS und $ HTTP POST VARS bis PHP 4.1.0 bzw. $ GET und $ POST ab Version 4.1.0). Andernfalls können die Variablen mit ihrem Formular-Namen abgefragt werden ($username bzw. $password). Zur Erhöhung der Sicherheit sollte die globale Variante durch die Zeile

register_globals = off

deaktiviert werden. [8]

2.4 Klassenkonzept

Ziel des zweiten Kapitels soll nicht sein, Grundlagen in PHP-Programmierung zu vermitteln, sondern einen groben Einblick in die Funktionsweise und die Implementierung von Konstrukten zu geben, die auch in dieser Diplomarbeit Anwendung finden.

In der Objektorientierung wird man mit zwei Begriffen konfrontiert:

P olymorphie (späte Bindung)

und

V ererbung .

Unter

Definition 2.4 (1. Polymorphie):

Polymorphie versteht man das Ver-

halten von objektorientierten Sprachen, die Signatur einer Funktion als Bestand-

teil des Funktionsnamens bei einem Aufruf zu betrachten.“ [11]

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

Definition 2.4 (2. Vererbung):

hanismus, durch den speziellere Ele-

Mec

mente die Struktur und das Verhalten allgemeinerer Elemente übernehmen.“

[12]

Eine Klasse kann also Grundfunktionalitäten von einer bereits existierenden Klasse übernehmen, z. B. um diese zu überschreiben. Vererbung ist in PHP implementiert und besitzt die gleiche Funktionalität wie in höheren Programmiersprachen, z. B. C++.

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

Abbildung in dieser Leseprobe nicht enthalten

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ür verschiedene XML-Ereignisse ermöglicht. XML wird in Kapitel 3) ausführlich 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öglicht nur die Generierung von Ausgabeströmen innerhalb der Event Handler. Es werden drei Zeichenkodierungen unterstützt:

- US-ASCII
- ISO-8859-1
- UTF-8

UTF-16 wird leider (noch) nicht unterstützt.

Die Windows-Version von PHP unterstützt standardmäßig diese XML-Extension, weshalb keine zusätzlichen Extensions hinzugeladen werden müssen, um die Parser-Funktionen verwenden zu können. 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önnen 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önnen:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.1: Parser-Optionen [8]

Case-folding“ lässt sich wiefolgt definieren: ”

Case-folding

Definition 2.5.2 (Case-folding):

is defined by the XML stan- 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.3 Event Handler

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

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

Tabelle 2.2 listet die zur Verfügung stehenden Event Handler auf:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.2: Event Handler [8]

Beide Handler erwarten die Namen der Handler-Funktionen1 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>).

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:

<?php

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

// Lese den Start-Tag aus bzw. seinen Namen function startElement($parser, $name, $attrs)

{ echo "Node: $name<br>"; }

// Lese den Inhalt des Nodes aus function characterData($parser, $data)

{ echo "$data<br>"; }

// 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 Markup1 Language) ist eine von SGML abgeleitete Meta2 -Sprache für 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ür Systeme, die die Definition bestimmter Schlüsselwörter 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öglicht (deskriptives Markup). Die Grundidee einer solchen Auszeichnungssprache ist die Trennung von Struktur uˆnd 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 ISO3 -Standard 8879 erklärt.

SGML ist keine vordefinierte Menge von Tags zum Markieren von Textpassagen, wie das vielleicht bei LATEX zu sehen ist. LATEX ist ein Satzsystem, bei dem das Aussehen des Dokumentes im ausgedruckten Zustand im Vordergrund steht (die vorliegende Arbeit wurde in LATEX geschrieben). Dazu benutzt LATEX u.a. bestimmte Zeichen (z. B. geschweifte Klammern), welche natürlich unterschiedlich interpretiert werden können, wenn das Dokument auf einen anderen Rechner übertragen wird. SGML löst sich von diesen Sonderzeichen- Abhängigkeiten. 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önnen bezeichnet werden.

Ein Beispiel für ein mit SGML definiertes ” ag“ wäre T <headline>

Die Grundprinzipien von SGML sind:

- Trennung von Inhalt und Struktur
- Hardund Softwareunabhängige Portabilität zwischen Publishing-Systemen
- Einbettung von Multimedia (Sprache, Animationen, Bilder)
- Einfache Notation
- Kompatibilität 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ückblickende (transitional) DTD und
- eine DTD für Framesets (frameset).

Den DTD-Typ kann man in der Präamel einer HTML-Seite einsehen:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

bzw.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

bzw.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "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öglichkeit, das Design auszutauschen, ohne die ganze HTML-Datei umzuschreiben bzw. zu ändern. Um 1995 wurde ein Design-Standard eingeführt, die Cascading Style Sheets (CSS), der es erlaubte, das Layout einer Seite getrennt vom Inhalt zu formatieren. Dieser Standard existiert bis heute, jedoch führt er auch nicht 100%ig zum gewünschten Erfolg.

Man arbeitete weiterhin an einer Lösung, mit der man SGML auf einfachere Weise jedermann zugänglich machen konnte, ohne Flexibilitätseinbußen in Kauf zu nehmen. So entstand

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):

Markup Language, abbreviated XML, de-

scribes 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).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.1: Bestandteile eines Dokumentes [14]

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

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.2: Die Historie von XML [14, S. 36] Abbildung 3.3 zeigt die Einbettung von XML in SGML:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.3: XML als Teilmenge von SGML [15]

3.3 Entwurfsziele und Vorteile

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

- XML shall be straightforwardly usable over the Internet.
- 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ünglich bekannt als SGML Editoral Review Board) unter der Schirmherrschaft des W3C aufgestellt.

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

XML bietet folgende Vorteile:

- XML ist international.
- XML lässt sich strukturieren.
- XML-Dokumente lassen sich zusammensetzen.
- XML kann als Datencontainer dienen.
- XML bietet Flexibilität.
- XML bietet eine einfache Syntax.
- XML bietet Standardformate.

3.4 Stuktur von XML

Wie bereits erwähnt, 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: ”

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: ”

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.]

Die logische Struktur beschreibt also die Auszeichnung des Dokumentes durch Deklarationen, Elemente, Kommentare und deren Aufbau, wohingegen die physische Struktur die Reihenfolge und die Anordnung dieser Entities festlegt. Beide Beschreibungstypen müssen innerhalb eines XML-Dokumentes korrekt sein.

Eine XML-Struktur kann als Baum gesehen werden, bei dem die Inhalte hierarchisch geordnet sind. Die physische Struktur legt fest, dass der Baum ein einziges Wurzelelement besitzt, z. B.:

<root>

<child1></child1>

<child2></child2>

</root>

Jede XML-Struktur beginnt mit einer XML-Deklaration, dem sog. Prolog“:

<?xml version="1.0" encoding="ISO-8859-1"?>

Dieser Prolog beinhaltet die XML-Version, die Codierung der Struktur in ISO oder UFT und laut Definition eine Dokumenttyp-Deklaration (diese wurde im obigen Beispiel vernachlässigt).

Die XML-Struktur kann u. a. folgende logische Auszeichnungen enthalten:

- Markup, d. h. Elemente (nodes) und deren Attribute (attributes)
- Dokumenttyp-Deklarationen
- Kommentare
- Verarbeitungsanweisungen (processing instructions)
- CDATA4 -Abschnitte (verhindern die Interpretation als Markup)

Ein XML-Dokument ist nur dann gültig (valid), wenn es eine Dokumenttyp-Deklaration be-

sitzt. Davon unabhängig kann es aber wohlgeformt sein. Die Begriffe ”

ohlgeformt“ und w gültig“ werden in den nächsten Abschnitten erklärt. ”

3.4.1 Wohlgeformtheit

Die Wohlgeformtheit eines XML-Dokumentes definiert das W3C so:

Definition 3.4.1 (Wohlgeformtheit):

textuelles Objekt ist ein wohlge-

formtes XML-Dokument, wenn:

1. es als Gesamtheit betrachtet zu der mit document bezeichneten Produktion passt,
Abbildung in dieser Leseprobe nicht enthalten
4CDATA = Character Data (Zeichenketten).
2. es alle Wohlgeformtheitsbeschränkungen dieser Spezifikation erfüllt und
3. jede seiner parsed Entities, welches direkt oder indirekt referenziert wird, wohlgeformt ist.

document ::= prolog element Misc*

Dass ein Dokument zur document-Produktion passt, impliziert:

1. Es enthält ein oder mehrere Elemente.
2. Es existiert genau ein Element, genannt Wurzeloder Dokument-Element, von dem kein Teil im Inhalt eines anderen Elements enthalten ist. Für alle anderen Elemente gilt: Wenn sich das Start-Tag im Kontext eines anderen Elements befindet, dann befindet sich das End-Tag im Kontext des selben Elements. Einfacher ausgedrückt: Die Elemente, begrenzt durch Startund End-Tag, sind korrekt ineinander verschachtelt.“ [13]

Kriterien für wohlgeformte XML-Dokumente sind folgende:

1. Das Dokument darf nur ein Wurzelelement enthalten.
2. Jedes XML-Dokument beginnt mit der XML-Deklaration.
3. Jedes Element muss korrekt verschachtelt sein.
4. Attribute werden in Start-Tags erklärt.
5. Jedes Attribut darf nur einen Wert haben.
6. Attribute können als Wert nur einfachen Text enthalten.
7. Alle Attributwerte müssen in doppelte oder einfache Anführungszeichen gesetzt sein.
8. Für jedes Element muss ein Startund ein Ende-Tag existieren, falls es sich nicht um ein leeres Element handelt.
9. Leere Elemente werden mit einem einzelnen Tag dargestellt, das mit einem Slash endet.
10. Isolierte Auszeichnungen sind im Inhalt nicht erlaubt. Die Sonderzeichen <, & und
> haben in Inhaltsabschnitten die Syntax &lt;, &amp; und &gt;.
11. Doppelte Anführungszeichen haben in Inhaltsabschnitten die Syntax &quot; und einfache Anführungszeichen die Syntax &apos;.
12. Die Zeichenfolgen <[[ und ]]>dürfen nicht verwendet werden.
13. Wenn es für ein Dokument keine DTD gibt, müssen alle Attribute standardmäßig Werte des Typs CDATA haben.
14. Kommentare beginnen und enden mit genau zwei Bindestrichen.
15. Die Namen von Elementen und Attributen beginnen mit einem Buchstaben.

Wenn ein XML-Dokument auf Wohlgeformtheit überprüft wurde, so ist ebenso die Gültigkeit des Dokumentes zu überprüfen. Viele XML-Editoren beherrschen dieses Feature und bieten auch Hilfe bei der Fehlersuche. Ebenso prüfen XML-Parser die Wohlgeformtheit, wenn XML-Dokumente im Internet Browser angezeigt werden, nicht aber die Gültigkeit.

Die Rolle der Gültigkeit von XML-Dokumenten wird im nächsten Abschnitt erläutert:

3.4.2 Gü ltigkeit

XML stellt einen Mechanismus zur Verfügung, um Beschränkungen der logischen Struktur zu definieren. Diese Beschränkungen legen fest, wie die Struktur aussehen darf, d. h. welche und wie viele Elemente wo vorkommen dürfen und mit welchen Attributen etc. Hält sich ein XML-Dokument an diese Vorgaben, so ist es gültig (valid).

Gültigkeit wird vom W3C folgendermaßen definiert:

Definition 3.4.2 (1. XML):

XML-Dokument ist gültig, wenn es eine da- zugehörige Dokumenttyp-Deklaration besitzt und wenn sich das Dokument an die darin formulierten Beschränkungen hält.“ [13]

Es gibt zwei Möglichkeiten, die Strukturinformationen in einer externen Datei zu definieren: Durch Anlegen einer

- DTD (Document Type Definition)
- XSD (eXtensible Schema Definition)

Das W3C defniert diese beiden Strukturdefinitionen so:

Definition 3.4.2 (2. DTD):

XML-Dokumenttyp-Deklaration enthält oder verweist auf Markup-Deklarationen, die eine Grammatik für eine Klasse von Do- kumenten bilden. Diese Grammatik ist bekannt als Dokumenttyp-Definition, kurz DTD. Die Dokumenttyp-Deklaration kann entweder auf eine externe Teilmenge (eine besondere Art eines externen Entity) verweisen, die Markup-Deklarationen enthält, oder sie kann Markup-Deklarationen direkt in einer internen Teilmenge enthalten oder beides. Die DTD für ein Dokument besteht aus beiden Teilmengen zusammen.“ [13]

Definition 3.4.2 (3. XSL-Schema): XML Schema Definition (XSD) bil- det eine vollständige in XML-Syntax formulierte kontextfreie Grammatik zur For- mulierung beliebiger XML-Strukturen ab.“ [13] Folgende Erläuterungen beziehen sich auf diesen XML-Code:

<adressbuch>

<kontakt>Meier</kontakt>

<kontakt>Huber</kontakt>

</adressbuch>

DTD: Bei der DTD werden die Elemente als Entities mit dem zugehörigen Datentyp (z. B. CDATA) eingetragen. Beispiel:

<!ELEMENT adressbuch (kontakt*)> <!-- Ein Adressbuch kann keinen

oder mehrere (*) Kontakte beinhalten -->

<!ELEMENT kontakt (#PCDATA)> <!-- Ein Kontakt besteht aus Text -->

XSD: XML-Schema bietet mehr Möglichkeiten als DTDs, die Restriktionen können exakter definiert werden und es sind sogar Mustervergleiche möglich.

<xs:element name="adressbuch">

<xs:complexType>

<xs:sequence>

<xs:element ref="kontakt" minOccurs="0"

maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="kontakt" type="xs:string"/>

Es gibt verschiedene XML-Editoren, die in der Lage sind, XML-Dokumente nicht nur auf Wohlgeformtheit sondern auch auf Validität zu prüfen. XMLSpy von Altova [16] ist einer dieser professionellen XML-Editoren, der zusätzlich in der Lage ist, anhand von XML-Code automatisch XSDs oder DTDs zu generieren. Dies bietet enorme Zeitvorteile und verringert das Fehlerrisiko bei der Entwicklung von Schemata.

Natürlich müssen die Schemata nachträglich korrigiert werden, da der Generator oft bestimmte Strukturen nicht richtig erkennt. Im vorhergehenden XML-Beispiel würde der Generator z. B. nicht erkennen, dass es beliebig viele Kontakte geben kann. Die Restriktionen würden demnach strenger formuliert werden als der Entwickler beabsichtigt.

XML-Schemata lösen Struktur und Inhalt des Dokumentes von den Regeln zur Erstellung der Struktur. Somit können die Regeln unabhängig vom XML-Dokument ausgetauscht werden, genauso wie die Darstellungsdefinitionen.

Es besteht weiterhin die Möglichkeit, Datenbankstrukturdefinitionen in XML-Schemata zu überführen und diese Regeln auf die XML-Dokumente anzuwenden, deren Inhalte aus einer Datenbanktabelle übernommen wurden. So wird XML zum universellen Datenaustauschformat zwischen Datenbanken und Applikationen unter Einhaltung der Strukturdefinitionen.

3.4.3 XML-Namespaces

Bei der Anwendung von XML-Schema fällt die geringfügig abgeänderte Notation ins Auge. Die Element-Namen (auch die Datentypen) beginnen nicht wie gewohnt mit einem Buch staben, sondern sie sind durch einen Doppelpunkt von einer sog. Namespace“-Angabe getrennt. ”

Namespaces ermöglichen die Unterscheidung von gleichnamigen Elementnamen innerhalb eines XML-Dokumentes. Es kann vorkommen, dass zwei Elemente mit gleichem Namen unterschiedliche Bedeutungen oder unterschiedliche Herkunft besitzen. Namespaces sind also eindeutige Zeichenfolgen (URIs5 ), die vor dem Element-Namen eingeschoben werden, getrennt durch einen Doppelpunkt. Besitzen mehrere gleichnamige Elemente verschiedene Namespaces, so sind sie trotz gleichen Namens unterschiedlich.

Beispiel:

<!-- myadb = my addressbook -->

<myadb:kontakt xmlns:myadb="http://www.adressbuch.de/schema"> Meier

</myadb:kontakt>

Die Angabe xmlns:“ (XML-Namespace) weist auf die Verwendung eines Namespaces hin. Es ist ” en, dass Namespaces durch einen URI identifiziert werden, also nicht durch eine Internetadresse (URL6 ). Bei der Einführung von Namespaces wurde festgelegt, dass diese durch eine eindeutige Zeichenkette identifiert werden sollen, die natürlich auch anders lauten könnte. Jedoch sollte man sich bei der Verwendung von Namespaces an die Vorgabe halten.

Es gibt weiterhin die Möglichkeit, einen Default-Namespace anzugeben, der dann für alle Elemente gilt.

3.5 XML-Parser

Programmiersprachen wie C++ oder Java besitzen einen Compiler, der den Quellcode in eine lauffähige Anwendung übersetzt. Quellcode einer Interpreter-Sprache wie JavaScript oder PHP wird – wie der Name bereits erkennen lässt – von einem Interpreter verarbeitet. XML- Code hingegen wird von einem sog. Parser“ (bzw. Prozessor) verarbeitet, der die XML- Spezifikation erfüllen muss. ”

Folgende Definition wurde vom W3C herausgegeben:

Definition 3.5 (XML-Parser):

Software-Modul, genannt XML-Prozessor,

dient dazu, XML-Dokumente zu lesen und den Zugriff auf ihren Inhalt und ihre

Struktur zu erlauben [..].“ [13]

Die Verarbeitung des XML-Codes erfolgt in mehreren Schritten, u. a. durch eine

1. lexikalische Analyse (Behandlung von lexikalischen Fehlern und das Komprimieren von Quellcode)
2. syntaktische Analyse (Erkennen von syntaktischen Strukturen und Feststellung von Fehlern)

Parsen im eigentlichen Sinne ist die syntaktische Analyse einer von einer (in diesem Fall kontextfreien) Grammatik erzeugten formalen Sprache. Kann der Parser einen Ableitungsbaum erstellen, so ist die Eingabemenge (ein XML-Fragment) syntaktisch korrekt. Erkennt der Parser Fehler, so weist er durch eine Fehlermeldung darauf hin und unterbricht die Verarbeitung des Codes. [17]

XML-fähige Internet Browser besitzen einen eigenen XML-Parser, z. B. der Internet Explorer von Microsoft, der den MSXML-Parser verwendet. Dieser Parser analysiert das XML- Dokument und meldet Fehler, falls das Dokument nicht korrekt sein sollte.

Neben dem Internet Explorer besitzen auch Netscape Navigator und Mozilla einen eigenen XML-Parser, letzterer den James Clark’s expat parser.

Man unterscheidet Parser, die die Validität von XML-Code überprüfen können (validierend) und solche, die diese Fähigkeit nicht besitzen (nichtvalidierend). Letztere prüfen die Wohlgeformtheit der XML-Struktur.

Der Markt bietet eine Reihe von Parsern, die die XML-Spezifikation (größtenteils) erfüllen:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3.1: XML-Parser [19]

Die bekanntesten Schnittstellen zur XML-Verarbeitung sind

- DOM (Document Object Model) und
- SAX (Simple API for XML).

Beide Schnittstellen werden im nächsten Abschnitt präsentiert.

3.6 Verarbeitungs-Schnittstellen

Die genannten Schnittstellen verwenden eine sog. API“ (Application Programming Interface), d. h. eine Sammlung von Schnittstellen für ” Parsen von XML-Dokumenten. Durch

diese Schnittstellen können die Methodenaufrufe des Parsers erweitert oder geändert werden. Neben SAX und DOM existieren noch weitere Schnittstellen bzw. APIs, z. B. JAXP (Java XML Parsing API).

3.6.1 JAXP

JAXP wurde von einem Projektteam unter der Führung von Sun entwickelt und stellt Standard- Schnittstellen zum Parsen und Manipulieren von XML-Dokumenten zur Verfügung. Allerdings überlässt es die Wahl eines bestimmten Parsers dem Entwickler, der über einen sog. Plugability Layer“ den zu benutzenden Parser festlegen kann.

Java Optional Package“ und besitzt den Paketnamen javax.xml.parsers. ”

Wie man an dem javax Präfix sieht, gehört es damit schon zu den Standarderweiterungen des JDK (wie z.B. auch die swing-Pakete im Paket javax.swing.*), wird zur Zeit aber noch nicht zusammen mit dem JSDK ausgeliefert.

JAXP besteht aus 6 Klassen, davon sind 4 abstrakt und definieren die Schnittstellen für das Erzeugen eines SAXParsers bzw. DOMBuilders, sowie für das Arbeiten mit Instanzen von ihnen. Die anderen zwei Klassen sind zur Fehlerbehandlung vorgesehen.

Um einen Parser in das JAXP-Paket pluggen“ zu können, muss dieser einige Voraussetzungen erfüllen: ”

- Er muss die Kodierungen ASCII, UTF-8 und UTF-16 unterstützen.
- Er muss ein Dokument auf seine Wohlgeformtheit überprüfen können.
- Er muss ein Dokument auf seine Gültigkeit anhand der DTD überprüfen können.

Ein großer Vorteil dieses Parsers ist seine hohe Konformität zum XML-Standard und seine Geschwindigkeit. Zudem bietet er eine Vielzahl an Beispielen (z.B. Adapterklassen, um DOM-Modelle in einem JTree darzustellen) und zusätzliche Dokumentation.

3.6.2 DOM

Das Document Object Model arbeitet anhand eines generischen Ansatzes. Dabei werden die Elemente der XML-Stuktur einzeln als Objekte betrachtet. Das W3C hat die Spezifikation für den neuesten DOM-Ansatz Level 3 Core am 7. November 2003 herausgegeben.

Definition 3.6.2 (DOM):

Document Object Model is a platformand language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents. The document can be further processed and the results of that processing can be incorporated back into the presented page. This is an overview of DOM-related materials here at W3C and around the web. The goal of the DOM group is to define a programmatic interface for XML and HTML. The DOM is separated into three parts: Core, HTML, and XML. The Core DOM provides a low-level set of objects that can represent any structured document. While by itself this interface is capable of representing any HTML or XML document, the core interface is a compact and minimal design for manipulating the document’s contents. Depending upon the DOM’s usage, the core DOM interface may not be convenient or appropriate for all users. The HTML and XML specifications provide additional, higher-level interfaces that are used with the core specification to provide a more convenient view into the document. These specifications consist of objects and methods that provide easier and more direct access into the specific types of documents. Key industry players are participating in the DOM Working Group, including editors and contributors from ArborText, IBM, Inso EPS, JavaSoft, Microsoft, Netscape, Novell, the Object Management Group, SoftQuad, Sun Microsystems, Texcel, and W3C.“ [18]

Die DOM Spezifikation besteht aus 3 Leveln:

- Level 1 konzentriert sich auf den aktuellen Kern, HTML und XML-Dokumente. Es beinhaltet Funktionalität zur Dokumentennavigationund manipulation.
- Level 2 beinhaltet ein Style Sheet Objektmodell und definiert die Funktionalität für die Manipulation der Style Sheet Informationen, die dem Dokument beiliegen.
- Level 3 betrifft sowohl das Laden und Speichern von Dokumenten als auch Content Modelle mit einer Validierungsfunktion.

Das DOM-Modell nutzt die Baumstruktur des XML-Dokumentes und besitzt eine Reihe von Schnittstellen, die benutzerdefiniert verarbeitet werden können. Beim Parsen wird eine Kopie der Baumstruktur erstellt, die dann verarbeitet werden kann. Daher kommt auch der Begriff generisch“ zum Ansatz. Nach dem Parsen wird der Baum wieder aus dem Speicher gelöscht ” bzw. entladen.

Dieses Modell besitzt neben den Vorteilen auch eine Reihe von Nachteilen, insbesondere die enorme Speicherbelastung, da bei jedem Parsen die komplette Struktur im Speicher abgebildet wird. Für große XML-Dokumente ist diese Technik ungeeignet, weshalb man in diesem Fall lieber zur SAX-Variante greifen sollte.

3.6.3 SAX

SAX bedeutet Simple API for XML Access“ und ist keine vom W3C standardisierte Schnittstelle zur ” Verarbeitung. Jedoch gibt es mittlerweile Unterstützung für eine Reihe von

Programmiersprachen, u. a. PHP (siehe Kapitel 2.5). SAX bietet folgende Vorteile:

- SAX kann Dateien beliebiger Größe parsen.
- Eigene Datenstrukturen können aufgebaut werden.
- Schnittstellen können benutzerdefiniert genutzt werden.
- SAX ist einfach und schnell.

Dem stehen allerdings auch einige Nachteile gegenüber:

- SAX bietet keinen freien Zugriff auf beliebige Teile eines Dokumentes.
- Komplexe Suchoperationen können nur schwer implementiert werden.
- DTDs stehen nicht zur Verfügung.
- SAX ist auf Read-Only beschränkt, die XML-Struktur kann somit nicht manipuliert werden.
- Lexikale Informationen stehen nicht zur Verfügung.
- SAX wird (noch) nicht von Browsern unterstützt.

SAX arbeitet ereignisgesteuert (wie bereits in Kapitel 2.5 erwähnt), d. h.

- der Parser läuft durch das gesamte Dokument und informiert die Anwendung bei jedem erkannten Element.
- Der Benutzer definiert eine Event-Handler-Klasse, in der festgelegt wird, was bei dem jeweiligen Event zu tun ist.
- Ein Objekt der Klasse wird dann beim Parser registriert und während des Parsens aufgerufen.

[...]


1 Die Funktionen, die den eigentlichen Text parsen.

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

2 Meta (griech.) bedeutet über, oberhalb“. Als Meta-Sprachen ” ” werden übergeordnete Sprachen bezeichnet.

3 ISO = International Organization for Standardization – http://www.iso.org.

4 CDATA = Character Data (Zeichenketten).

5 URI = Uniform Resource Identifier, ein Konzept zur Ermöglichung einer einheitlichen Adressierung aller Ressourcen im Netz.

6 URL = Uniform Resource Locator, eine einheitliche Adresse für Angebote im WWW.

Final del extracto de 151 páginas

Detalles

Título
Implementierung eines XML-basierten Generators für Online-Praktika
Universidad
University of Applied Sciences Regensburg
Calificación
1,00
Autor
Año
2004
Páginas
151
No. de catálogo
V116671
ISBN (Ebook)
9783640183579
ISBN (Libro)
9783640183777
Tamaño de fichero
2376 KB
Idioma
Alemán
Notas
VDI-Preis 2005 für "hervorragende Diplomarbeit"V
Palabras clave
Implementierung, XML-basierten, Generators, Online-Praktika
Citar trabajo
Dipl.-Inf. (FH) Michael Buchner (Autor), 2004, Implementierung eines XML-basierten Generators für Online-Praktika, Múnich, GRIN Verlag, https://www.grin.com/document/116671

Comentarios

  • No hay comentarios todavía.
Leer eBook
Título: Implementierung eines XML-basierten Generators für Online-Praktika



Cargar textos

Sus trabajos académicos / tesis:

- Publicación como eBook y libro impreso
- Honorarios altos para las ventas
- Totalmente gratuito y con ISBN
- Le llevará solo 5 minutos
- Cada trabajo encuentra lectores

Así es como funciona