XML Toolbox

Fachhochschule Vorarlberg GmbH.
Bachelorarbeit im
Fachhochschul-Bachelorstudiengang Informatik
Implementierung einer
XML Toolbox für Matlab
ausgeführt von
Philip Masser
0410247028
Dornbirn, im August 2007
Betreuer Dipl.-Inform. Thomas Feilhauer

Ich erkläre hiermit ehrenwörtlich, dass ich die vorliegende Arbeit selbstständig
angefertigt habe. Die aus fremden Quellen direkt oder indirekt übernommenen
Gedanken sind als solche kenntlich gemacht. Die Arbeit wurde bisher keiner anderen
Prüfungsbehörde vorgelegt und auch noch nicht veröffentlicht.
Philip Masser
Zusammenfassung
Dieses Dokument beschreibt die XML Toolbox als ein Ersatz für die Geodise Toolbox.
Zunächst werden die Gründe für die Entwicklung und Anforderungen an die Lösung
erläutert. Ein klares Ziel war es, performanter (sowohl Laufzeit als auch Speicherver-
brauch betreffend) als die Geodise Toolbox zu sein. Es wird der Aufbau der Lösung
dargestellt und die Funktionen der einzelnen Schichten erläutert. Weiters werden De-
tails der Implementierung beschrieben, die wichtig für die Performanz der Toolbox sind.
Die möglichen Ausgabeformate und der Aufruf der Kommandos für Export und Import
aus der Matlab Umgebung werden kurz dargestellt. Es wird auf Probleme der Toolbox
hingewiesen, die bei der Benutzung auftreten können. Am Ende werden die Ergebnisse
der durchgeführten Tests für Laufzeit und Speicherverbrauch kurz beschrieben und in-
terpretiert. Es wird auch ein Vergleich zur Geodise Toolbox gemacht, und gezeigt, dass
diese Toolbox in jedem getesteten Fall performanter ist als die Geodise Toolbox.
Abstract
This document describes the XML Toolbox, which is an alternative for the Geodise
Toolbox for Matlab. The reasons that led to the development of this Toolbox as well as
the requirements claimed to it are explained. To achieve better performence in the sense
of run time and memory consumption compared to the Geodise Toolbox was declared
as a first degree goal. Next, the general design of the solution and the tasks of each layer
are explained. The available output formats and how the commands for importing and
exporting data from/to the Matlab environment are described shortely. problems that
may occurre while using the XML Toolbox are pointed out. Finally the results of the
memory and run time tests that were performed are described and interpreted. These
are compared with the Geodise Toolbox, and it will be shown that this Toolbox performs
better in every test case.
iii
Inhaltsverzeichnis
1 Einleitung 1
1.1 Was macht die XML Toolbox? . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Stand der Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Motivation und Anforderungen . . . . . . . . . . . . . . . . . . . . . . . 2
2 Aufbau der XML Toolbox 4

2.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Plattform Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Unicode Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 XML Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.1 Allgemeines zur XML Schicht . . . . . . . . . . . . . . . . . . . . 7
2.4.2 Schreiben von XML Dokumenten . . . . . . . . . . . . . . . . . . 7
2.4.3 Lesen von XML Dokumenten . . . . . . . . . . . . . . . . . . . . 8
2.5 Matlab Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.6 Client Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.7 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 Implementierung 13
3.1 Stringfunktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 MemoryVector Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Memory Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4 Verwendung der Unicode Schicht . . . . . . . . . . . . . . . . . . . . . . 21
4 Anwendung 22
4.1 Client Handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2 Aufruf aus Matlab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3 XML Parser Bibliotheken . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.4 Probleme der XML Toolbox . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4.1 Mangelnde Fehlerinformationen . . . . . . . . . . . . . . . . . . . 26
iv
Inhaltsverzeichnis
4.4.2 XML Attribut Stil . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5 Test 27
5.1 Testmethodik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2 Testergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.3 Test der Wachstumsfunktion . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.3.1 Theoretische Tests . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.3.2 Praktische Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6 Zusammenfassung und Ausblick 33
Appendix A – Inhalt der CD 37
Appendix B – Programmteile 39
Appendix C – Testfälle und -ergebnisse 43
v
1 Einleitung
1.1 Was macht die XML Toolbox?

Matlab ist eine technische Programmiersprache und eine Entwicklungs- und Laufzeit-
umgebung für diese Sprache. Sie ist optimiert für die Behandlung großer Matrizen und
Felder und ermöglicht schnellere Abarbeitung von berechnungsintensiven Algorithmen
als mit herkömmlichen Programmiersprachen1 .
Um die Möglichkeiten dieser Programmiersprache mit bestehenden Applikationen zu

koppeln, oder auch die Analyse von Datensätzen in einem Grid zu verteilen, müssen
Daten aus Matlab Umgebungen importiert und exportiert werden. Matlab bietet bereits
Möglichkeiten, dies zu bewerkstelligen, diese sind jedoch nicht immer zufriedenstellend
oder ausreichend2 . Auch existieren bereits zusätzliche Kommunikationsschnittstellen, die
ebenfalls ihre Vor- und Nachteile besitzen.
Das Ziel dieser Arbeit war es, eine neue Schnittstelle für das Importieren und Ex-
portieren von Daten in bzw. aus Matlab zu erarbeiten. Der Austausch der Daten sollte
dabei über XML geschehen. Dieses Dokument beschreibt die technische Lösung dieser
Aufgabenstellung, mit den daran gestellten Anforderungen, dem Design und die Imple-
mentierung der Lösung, sowie Testverfahren und -ergebnisse.
1.2 Stand der Technik

Matlab bietet bereits Schnittstellen, um Daten zu exportieren und importieren. All
diese Methoden haben jedoch Nachteile, die sie für die Nutzung als Datenaustausch-
schnittstellen im Grid oder mit Fremdapplikationen ungeignet machen. Zum einen bie-
tet Matlab die Möglichkeit, Daten in Textdateien zu exportieren3 . All diese Funktionen
1
siehe [Mat07a]
2
siehe 1.2
3
Siehe csvread, csvwrite, dlmread, dlmwrite, textread und textscan unter [Mat07b]
1
1 Einleitung
haben jedoch den Nachteil, dass kein XML Text erzeugt wird und meist nur numerische
Matrizen, aber keine komplexen Objekte wie Cell-Arrays oder Strukturen geschrieben
bzw. gelesen werden können. Bei Matlabs eingebauten XML-Funktionen andererseits
wird mit DOM XML-Knoten Objekten gearbeitet4 . Beim Exportieren muss solch ein
Objekt zuerst aufgebaut werden, und nach dem Importieren muss dieses wieder analy-
siert werden. Dies ist jedoch nicht praktiktisch für automatisierten Import und Export;
dafür müsste eine Konvertierungsfunktion geschrieben werden.
Matlab bietet weiters eine Möglichkeit, beliebige Datenobjekte zu exportieren und

zu importieren. Dies erfolgt über sogenannte MAT-Dateien, die mittels den Komman-
dos save und load geschrieben bzw. gelesen werden können. Der Nachteil an diesem
Format ist, dass es ein proprietäres, binäres Format ist und sich daher schlecht für die
Nachbearbeitung oder für die Erstellung durch Applikationen von Drittanbietern eignet.
Neben den von Matlab gebotenen Schnittstellen gibt es weiters sogennante Toolboxes
von Drittanbietern. Darunter ist die Geodise XML Toolbox5 die meist verwendete. Mit
ihr können Matlab Variablen als XML-Dateien exportiert werden und wieder zurück.
Die Geodise Toolbox hat jedoch Probleme betreffend Speicherverbrauch und Geschwin-
digkeit.
Die Liste der hier erwähnten Schnittstellen zum Datenimport und -export ist nicht
vollständig. Es soll hier nur ein Überblick über die wichtigsten gegeben und die Probleme
kurz aufgezeigt werden, die mit diesen zusammenhängen.
1.3 Motivation und Anforderungen

Wie bereits erwähnt sollte eine Toolbox entwickelt werden, mit der Matlab Variablen
mittels XML importiert und exportiert werden können. Dabei diente die Geodise XML
Toolbox als Vorlage für die Implementierung. Die neue Toolbox sollte kompatibel zur
Geodise Toolbox sein, jedoch deren Probleme beheben. Des weiteren sollte es einfach
sein, die Toolbox um weitere Formate für die XML Dateien zu erweitern. Sie sollte auf
allen System arbeiten, auf denen eine Matlab Distribution verfügbar ist.
4
Siehe xmlwrite bzw. xmlread bei [Mat07b]
5
Siehe [GEO07]
2
1 Einleitung
Generell gibt es vier Möglichkeiten, mit der Matlab Umgebung zu komunizieren. Die
erste sind .M Dateien. Dabei handelt es sich um in der Sprache Matlab geschriebene
Algorithmen, die von der Matlab Umgebung interpretiert werden. Diese eignen sich nicht
für die Entwicklung der XML Toolbox, da sie an die Möglichkeiten von Matlab selbst
gebunden sind, und ein Export bzw. Import nur umständlich implementiert werden kann.
Die zweite stellt die Matlab Engine dar. Das ist eine Art Pipe von einem gewöhnlichem
Programm in beliebiger Programmiersprache zu der Matlab Umgebung. Mit ihr können
Matlab Kommandos ausgeführt werden. Hier tritt das Problem auf, dass nur wenig
Informationen über die Struktur von Objekten ermittelt werden kann.
Die dritte Möglichkeit stellt Java Klassen dar. Diese können direkt aus der Matlab
Umgebung angesprochen werden, sofern diese Umgebung mit einer JVM gestartet wurde.
Es war aber ein erklärtes Ziel, dass keine JVM verwendet werden soll, um die XML
Toolbox auch in der reinen Kommandozeilenumgebung zur Verfügung zu stellen.
Die letzte Möglichkeit sind .MEX Dateien. Dies sind in C oder Fortran geschriebene
und kompilierte Erweiterungen, die ähnlich einer DLL aus Matlab heraus aufgerufen
werden können. Hier werden zusätzliche Methoden angeboten, die in den vorher ge-
nannten Varianten nicht zur Verfügung stehen. Auch ist eine komplette Untersuchung
von Matlab Objekten möglich. Außerdem kann in einer MEX Bibliothek jeder beliebige
Code ausgeführt werden, da zum einen alle Matlab Funktionen zur Verfügung stehen,
jedoch auch alle anderen Möglichkeiten der Sprachen genutzt werden können. Aufgrund
dieser Tatsache wurde die XML Toolbox als C++ MEX Biblothek implementiert.
3
2 Aufbau der XML Toolbox
Dieses Kapitel beschreibt das Gesamtdesign der XML Toolbox und einige Details der
einzelnen Komponenten. Es werden die wichtigsten Konzepte erläutert und wie diese
in Zusammenhang mit den Anforderung stehen. Das hier dargestellte Design ist daher
nicht vollständing, sondern konzentriert sich auf die Hauptbestandteile.
2.1 Überblick
Bei dem Design der XML Toolbox stand die Wartbarkeit und Wiederverwendbarkeit
im Vordergrund. Es stellte sich heraus, dass sich das Importieren und Exportieren in
mehrere, klar getrennte Aufgabengebiete teilen ließ. Jede dieser Elemente konnte für sich
gesehen wieder anderweitig von Nutzen sein. Daher wurden diese Teile in leicht trennbare
Schichten aufgeteilt. Die Schichten bauen zwar aufeinander auf, diese Schnittstellen sind
aber leicht ersetzbar. Abbildung 2.1 zeigt das Schichtenmodell der XML Toolbox. Die
einzelnen Schichten sind:
• Plattform Schicht, für die Abstraktion der unterliegenden Plattform
• Unicode Schicht, für das Lesen und Schreiben von Unicode Dateien und Strings
• XML Schicht, für das Lesen und Schreiben von XML Dateien und Strings
• Matlab Schicht, als Schnittstelle zur Analyse und zum Aufbau von Matlab Objek-
ten
• Client Schicht, als eigentliche Implementierungsschicht für die Clientapplikation
Die folgenden Abschnitte erläutern nun die einzelnen Schichten im Detail.
4
Abbildung 2.1: Übersicht über die XML Toolbox Schichten
2.2 Plattform Schicht

Wie in Kapitel 1.3 erwähnt, sollte die XML Toolbox auf allen Computern funktionie-
ren, auf denen Matlab zur Verfügung steht1 . Dabei sind auch unterschiedliche Prozessor-
architekturen und Betriebssysteme zu beachten.
Um den Umgang mit diesen Unterschieden zu vereinfachen, wurde die Plattform

Schicht eingebaut. Sie abstrahiert von der Plattform2 und erleichtert die weitere Ent-
wicklung.
1
Bei der Implementierung wurden Windows 32 und 64 Bit, MacOS X und Linux berücksichtigt
2
Mit Plattform ist hier der verwendete Compiler, das Betriebssystem und die Architektur der Zielma-
schine gemeint
5
Die wichtigste Aufgabe dieser Schicht sind Typdefinitionen. Hier werden alle grund-
legenden Datentypen definiert, die in den höheren Schichten benötigt werden, und zwar
derart, dass sie bei allen unterstützten Compilern dieselben Datentypen darstellen. Ein
Beispiel hierfür ist die Definition eines vorzeichenbehafteten, 8-Bit Ganzzahltyps. Im
Normalfall ist dies der C-Datentyp char. In Microsoft Visual C++ ist es aber möglich,
den char Datentyp als vorzeichenlos zu definieren. Somit wäre char der falsche Datentyp
für die vorherige Definition, sondern signed char.
Eine weitere Aufgabe dieser Schicht ist die Bereitstellung von Betriebssystemspezifi-
schen Funktionen, wie z.B. das Konvertieren von lokal 8-Bit kodierten Strings in Uni-
code Strings und umgekehrt. Weiters werden hier noch Klassen definiert, die von allen
Schichten gemeinsam genutzt werden. Diese sind IOException, als eine Ein- Ausgabe
Ausnahme, die theoretisch in jeder Schicht auftreten kann, und MemoryHandler, als eine
Klasse zur Allokierung und Deallokierung von Speicher3 .
2.3 Unicode Schicht

Diese Schicht ist verantwortlich für das Kodieren (TextEncoder) und Dekodieren
(TextDecoder) von Unicode-kodierten Dateien und Strings. Die Klassen arbeiten auf
STL4 Stream Objekten, und können somit von allen stromorientierten Eingabequellen
lesen bzw. schreiben. Es werden die gängigen Kodierungsarten UTF-16 (sowohl Big als
auch Little Endian) und UTF-85 , aber auch eine einfache ISO-8859-1 (Latin-1) Kodie-
rung unterstützt.
Ein weiterer wichtiger Bestandteil dieser Schicht sind Stringkonvertierungsfunktio-

nen. Dabei handelt es sich um Templateklassen, die Stringobjekte von einem Datentyp
in ein Stringobjekt eines anderen Datentyps umwandeln. Wenn möglich wird dabei das
ursprüngliche Objekt zurückgegeben, um sowohl Ausführungszeit als auch Speicherver-
brauch niedriger zu halten.
Ursprünglich wurde die Unicode Schicht als optionale Schicht implementiert. Die feh-
lenden Schnittstellen wären dann von der darüberliegenden XML Schicht bereitgestellt
3
Siehe dazu 3.3
4
STL: Standard Template Library; die C++ Basisbibliothek
5
Siehe [Con06, Kap. 3.9, 3.10]
6
worden. In Kapitel 3.4 wird erklärt, wieso diese Schicht in der endgültigen Version ent-
halten sein sollte.
2.4 XML Schicht

2.4.1 Allgemeines zur XML Schicht
Die XML Schicht bietet Klassen und Schnittstellen für das Lesen und Schreiben von
XML Dateien. Sie baut auf der Unicode Schicht auf, womit alle Kodierungen dieser
Schicht unterstützt werden. Da in der XML Toolbox nur einfache XML Dateien ge-
schrieben bzw. gelesen werden müssen, sind die hier definierten Klassen recht einfach
gehalten. Sie sind auch nicht konform mit den W3C6 Spezifikationen für SAX Parser oder
DOM Builder. Sie sind zugeschnitten auf die Bedürfnisse der übergeordneten Schichten
der XML Toolbox. Sie können aber dennoch auch anderweitig von Nutzen sein, wenn
nur einfache XML Unterstützung benötigt wird.
2.4.2 Schreiben von XML Dokumenten
Abbildung 2.2: Komponenten für das Schreiben von XML Dokumenten
Die Klassen, die für das Schreiben von XML zuständig sind, und deren Abhängigkei-
ten, sind in Abb. 2.2 dargestellt. Die hier eingezeichnete Klasse TextEncoder ist jene aus
der Unicode Schicht. Sie hat eine Referenz auf einen Ausgabestrom der STL, in den das
Ergebnis als entsprechend kodierter Unicode String geschrieben wird. Dieser Unicode
Kodierer wird von einem XMLTextEncoder verwendet. Um in Strings zu schreiben, muss
die XMLStringEncoder Klasse verwendet werden.
6
W3C: World Wide Web Consortium
7
Die XMLTextEncoder Klasse ist ein Wrapper um den Unicode Textkodierer, um die
Trennung von XML und Unicode Schicht zu ermöglichen. Sie stellt die Schnittstelle
für die XMLEncoder Klasse dar. Diese Klasse überprüft die Gültigkeit von Zeichen in
einem gewissen Kontext innerhalb von XML Dateien (z.B. Attributname, Elementname,
Attributwert, Text). Gegebenenfalls wird ein Zeichen durch eine entsprechende Entität
ersetzt oder eine Ausnahmebedingung ausgelöst. Die Implementierung hält sich dabei
an die W3C XML Spezifikation (siehe [W3C06, Kap. 2]).
Die von Benutzern direkt verwendete Klasse ist XMLWriter. Sie bietet eine einfache
High-Level API zum Erstellen von XML Dokumenten. Sie enthält Methoden für das
Öffnen von Elementen (inklusive Angabe von Attributen), Schließen von Elementen,
Schreiben von Text, . . .
Das Schreiben von XML Dokumenten wurde bewusst einfach gehalten. Ein W3C
konformer Ansatz mit DOM Builder würde verlangen, dass zuerst der gesammte Inhalt
des XML Dokuments als DOM Baum im Arbeitsspeicher aufgebaut wird, und erst dann
serialisiert werden kann. Durch den einfacheren Ansatz ist eine Zwischenspeicherung
nicht notwendig, das Dokument kann sofort in die Datei bzw. den String geschrieben
werden, womit weniger Speicher zur Laufzeit verbraucht wird (v.a. beim Schreiben von
Dateien).
2.4.3 Lesen von XML Dokumenten
Abbildung 2.3: Komponenten für das Lesen von XML Dokumenten
Das Lesen von XML Dokumenten mittels der XML Schicht basiert auf dem SAX
Parser Prinzip der W3C XML Spezifikation. Es gibt eine abstrakte Handler Klasse, hier
XMLHandler genannt, die von Benutzern abgeleitet werden muss. Eine Instanz solch
8
einer Klasse wird über Ereignisse während des Parses eines Dokuments informiert. Das
eigentliche Parsen des Dokuments übernimmt eine Instanz einer XMLReader Klasse, die
ebenfalls abstrakt ist. Diese liest das XML Dokument über einen STL Eingabestrom.
Instanzen der XMLReader Subklassen werden mit der Singletonklasse XMLReaderFactory
erzeugt. Diese Zusammenhänge sind in Abb. 2.3 abgebildet.
Das Factory-Pattern wird hier verwendet, um einfach die zugrundeliegende XML

Parser Bibliothek auszutauschen. Die XML Schicht selbst implementiert lediglich die
Schnittstellen, jedoch keinen Parser. In Abb. 2.3 wird zur Veranschaulichung ein Apache
Xerces-C7 Wrapper mit Bibliothek dargestellt. In Zukunft können weitere XML Biblio-
theken angebunden werden. Es muss lediglich eine Wrapperklasse geschrieben werden,
die die entsprechenden Methoden der Handler Instanz aufruft. Somit können schnellere
oder speicherschonendere Bibliotheken je nach Bedarf verwendet werden.
2.5 Matlab Schicht

Die Matlab Schicht ist die Schnittstelle zur Matlabumgebung. Sie bietet Klassen für
das Auslesen und das Erstellen von Matlab Variablen. Sie ist funktional unabhängig von
den darunterliegenden Schichten, benutzt jedoch deren Typdefinitionen und Hilfsfunk-
tionen.
Die Matlab Schicht bietet zum Auslesen von Variablen die Klasse MatlabAnalyzer.
Diese Klasse bietet alle Low-Level Funktionen zur Auswertung von Matlab Objekten, die
die Matlab Umgebung selbst bietet. Für komplexe Objekte jedoch bietet sie Hilfsfunk-
tionen für den leichteren Umgang z.B. mit Cell-Arrays, Strukturen und dünnbesetzten
Matrizen (Sparse Matrices).
Für das Definieren von Matlab Objekten wird die Klasse MatlabBuilder, zusammen
mit MatlabElement Objekten verwendet. Ein MatlabElement ist ein Informationscon-
tainer, der mit allen relevanten Daten gefüllt wird. Es kann logische, ganzzahlige, reelle
und Textdaten aufnehmen, zusammen mit einem Namen und Typinformationen. Diese
Elemente werden dann von einem MatlabBuilder in die entsprechende Matlabdarstel-
lung umgewandelt. Dabei können Elemente Teile von anderen Elementen werden, z.B.
7
Siehe http://xml.apache.org/xerces-c/
9
bei Feldern einer Struktur, aber auch bei Real- und Imaginärteil von komplexen Matri-
zen.
Intern arbeitet der MatlabBuilder mit zwei Stacks von MatlabElementen. Der erste ist
der sogenannte Parsed-Stack, der zweite der Built-Stack. Geparste Elemente, die evtl.
noch zu bearbeiten sind, werden auf den Parsed-Stack gelegt. Solange sie hier liegen,
können sie noch verändert werden. Wenn alle Daten gesammelt sind, können sie in den
entsprechenden Matlab Datentyp umgewandelt werden, und werden auf den Built-Stack
verschoben. Containerelemente auf dem Parsed-Stack besitzen einen Stackpointer auf
den Built-Stack. Alle Elemente, die über diesem Pointer liegen, sind Unterelemente des
Containerelements.
Als Beispiel für die Funktionsweise des MatlabBuilders wird eine kleine Struktur er-
stellt. Sie besitzt zwei Felder: Description, die einen Text enthält, und Value, eine
komplexe Matrix. Die aufzubauende Struktur soll schematisch folgende Form haben:
Structure {
Description = ‘‘6. Wurzel aus 4096’’
Value = [6 3+5.196i -3+5.196i -6 -3-5.196i 3-5.196i]
}
Als XML Dokument könnte diese Strukture z.B. wie folgt aussehen:
<r o o t type=” s t r u c t ” s i z e=”1 1”>
<D e s c r i p t i o n type=” c h a r ” s i z e=” 1 18 ”>6 . Wurzel aus 4096</ D e s c r i p t i o n>
<Value type=” complex ” s i z e=”1 6 ”>
<item type=” d o u b l e ” s i z e=”1 6 ”>6 3 −3 −6 −3 3</ item>
<item type=” d o u b l e ” s i z e=”1 6 ”>0 5 . 1 9 6 5 . 1 9 6 0 −5.196 −5.196</ item>
</ Value>
</ r o o t>
Abbildung 2.4 zeigt schrittweise den Vorgang, wie solch eine Struktur erstellt werden
kann. Die türkise Farbe stellt MatlabElemente dar, die noch nicht zu Matlab Datentypen
umgewandelt wurden, die grüne jene, bei denen dies geschehen ist. Zuerst wird das um-
schließende Strukturelement auf den Parsed-Stack gelegt (a). Sein Stackpointer zeigt auf
das Ende des Built-Stacks. Somit werden alle folgenden Elemente Felder dieser Struktur
werden. Als nächstes wird der Beschreibungstext als Stringelement geparst (b). Da keine
10
Build Simple Type
String
Struct Struct
Parsed Built Parsed Built
a) b)
Complex
Struct String Struct String
c) d)
Build Simple Type

Build Simple Type
Double Double
Complex Complex Double
e) f)
Build
Complex
Double
Complex Double Complex
g) h)
Build
Structure
Complex
i) Struct String j) Struct
Abbildung 2.4: Beispiel: Arbeiten mit den MatlabBuilder Stacks
Unterelemente möglich sind, wird es sofort auf den Built-Stack übertragen (c). Wie zu
sehen ist, wird der Text dabei nicht in die Matlab-interne Datenstruktur umgewandelt;
mehr dazu später. Das Element der komplexen Matrix wird als nächstes geparst und
auf den Parsed-Stack gelegt (d). Der Stackpointer zeigt über das Textelement. Dieses
gehört nicht zur Matrix. Der Inhalt der Matrix muss als nächstes geparst werden. Dies
sind der Real- und Imaginärteil, jeweils ein Double-Array. Sie werden auf den Built-Stack
verschoben (e - f). Auch diese Elemente werden nicht in ihre Matlab-Darstellung umge-
wandelt. Das liegt daran, dass solche Elemente ein Bestandteil eines anderen Elementes
werden können, und nicht als eigenständige Objekte an Matlab übergeben werden. Im
Beispiel werden die Double-Arrays Teile der komplexen Matrix.
Jetzt sind alle Informationen für die komplexe Matrix vorhanden. Sie kann umge-
wandelt werden. Dazu werden alle Unterelemente vom Built-Stack (die beiden Double-
Arrays) und das Matrix Element vom Parsed-Stack genommen. Es wird eine komplexe
11
Matrix als Matlab Datentyp erzeugt und auf den Built-Stack gelegt (h). Nun bleibt nur
noch das Strukturelement übrig. Es wird vom Parsed-Stack genommmen, und zusam-
men mit den Unterelementen vom Built-Stack in eine Matlab Struktur umgewandelt (i).
Das Textelement wird dabei ebenfalls in den entsprechenden Matlab Typ umgewandelt.
Die fertige Struktur mit dem Text- und Matrixelement landet auf dem Built-Stack (j).
2.6 Client Schicht

In der Client Schicht wird die eigentliche Import- und Exportlogik implementiert. Sie
benutzt die Matlab Schicht, um Variablen auszuwerten und mittels der XML Schicht zu
kodieren, oder erzeugt mit Hilfe von XML Handlern und Matlab Buildern Objekte in
der Matlab Umgebung. Sie bietet dazu zwei abstrakte Klassen, MatlabExportHandler,
um Matlab Objekte zu exportieren, und MatlabImportHandler, um XML Dokumente
zu importieren. Letztere Klasse ist direkt von XMLHandler abgeleitet, und somit an
die XML Schicht gebunden. Diese Klassen werden abgeleitet, um ein bestimmtes XML
Format zu erzeugen und zu lesen. Es können somit beliebige Erweiterungen am Format
vorgenommen werden.
Die weiteren Klassen (MatlabExporter und MatlabImporter) dienen als Hilfsklassen,

welche die Infrastruktur um die Handlerimplementierungen aufbauen. So erzeugen sie
beispielsweise den Aus- bzw. Eingabestrom, den XML Parser, oder eine MatlabAnalyzer
Instanz.
2.7 Zusammenfassung
In diesem Kapitel wurden die Grundlagen der XML Toolbox erläutert. Das Schicht-
modell mit der Plattform-, Unicode-, XML-, Matlab- und Client-Schicht, sowie die Be-
deutung und Aufgabe jeder einzelnen Schicht wurden erklärt. Auch wurde dargelegt,
inwiefern die einzelnen Schichten zur Performanz bzw. Erweiterbarkeit beitragen. Auch
wurden die beiden Erweiterungsmöglichkeiten erläutert, zum einen in der XML Schicht,
indem eine andere XML Parser Bibliothek verwendet wird, zum anderen in der Client
Schicht, in der die eigentliche Arbeitslogik, und somit unterschielichste Formate definiert
werden können.
12
3 Implementierung
Dieses Kapitel beschreibt wichtige Implementierungsdetails der XML Toolbox. Es wer-
den jene Abschnitte behandelt, die maßgeblich zur Performanz beitragen. Das wichtig-
ste Ziel bei diesen Bereichen war, dass so wenig Speicher wie möglich durch redundante
Datenkopien verschwendet wird, auch desshalb, weil mit dem Kopievorgang Laufzeitein-
bußen zusammenhängen.
3.1 Stringfunktionen
Wie bereits in Kapitel 2.3 erwähnt, werden in der Unicode Schicht Stringkonver-
tierungsfunktionen definiert. Diese sollen die Umwandlung von verschiedenen String-
typen erleichtern. Sie sind als Templateklasse implementiert, wobei die Parameter die
Ursprungs- und Zieldatentypen darstellen. Diese Datentypen sind z.B. char oder wchar t.
Für jedes Datentyppaar muss eine eigene, explizite Spezialisierung implementiert werden.
So können unterschiedliche Behandlungen von Stings bei der Konvertierung berücksich-
tigt werden.
Ein Beispiel, wie diese Klasse zur Performanz von Code beitragen kann, ist die Kon-
vertierung von unsigned short (kurz ushort) zu wchar t Strings. Beide Datentypen
stellen einen vorzeichenlosen, 2-Byte Buchstaben dar, und sind theoretisch austausch-
bar. Dennoch sind die Datentypen nicht dieselben1 . Somit ist in C++ ein Zeiger auf den
einen Typ nicht zuweisungskompatibel mit einem Zeiger auf den anderen. Es ist ein ex-
pliziter Typecast notwendig. Dabei wird keine Kopie erzeugt. Diese Implementierung ist
schneller und verbraucht keinen zusätzlichen Speicher, verglichen mit der Stringkonver-
tierung von char auf wchar t. Dort muss der Text kopiert und auch konvertiert werden,
da die interne Darstellung eine andere ist.
1
Hier wird wchar t als Buit-in Datentyp angenommen
13
3 Implementierung
Die Wartbarkeit von Code kann durch diese Stringfunktionen auch erhöht werden.
Angenommen ein Projekt kann sowohl mit Unicode als auch ohne kompiliert werden. Je
nachdem wird ein eigener Buchstabendatentyp anders definiert. Nun müssten je nach
Kompilierungsart unterschiedliche Konvertierungsfunktionen aufgerufen werden. Dies
kann automatisch durch die Stringfunktionsklasse gelöst werden.
Hierzu ein Beispiel:

// Prototyp d e r S t r i n g k o n v e r t i e r u n g s k l a s s e
template<typename SRC, typename DEST>
class StringFunctions {
// F u n k t i o n s d e k l a r a t i o n e n ohne Implementierung
};
// w c h a r t zu u s h o r t K o n v e r t i e r u n g
template<>
c l a s s S t r i n g F u n c t i o n s <wchar t , u s h o r t > {
// S p e z i f i s c h e Implementierung
};
// w c h a r t zu c h a r K o n v e r t i e r u n g
template<>
c l a s s S t r i n g F u n c t i o n s <wchar t , char> {
// S p e z i f i s c h e Implementierung
};
// Char−t y p d e f i n i t i o n
#i f d e f UNICODE SUPPORT
typedef u s h o r t m y c h ar t yp e ;
#e l s e
typedef char m y c h ar t yp e ;
#endif
// Der S t r i n g
const wchar t ∗ o r i g s t r i n g = L” O r i g i n a l Wide−S t r i n g ” ;
// K o n v e r t i e r u n g
m y c h a r t yp e ∗ conv = S t r i n g F u n c t i o n s <wchar t , my char type>
: : convert ( o r i g s t r i n g ) ;
14
3 Implementierung
Bei diesem Codeabschnitt wird je nach Definition von my char type die entsprechende
Spezialisierung bereits zur Compilezeit ausgewählt. Es erfolgt keine weitere Überprüfung
auf das Makro UNICODE SUPPORT, um den String umzuwandeln.
3.2 MemoryVector Klasse

Bei dem Import von Matlab Objekten müssen oft große Matrizen erstellt werden
(z.B. 100 x 100 x 100). Um diese Matrizen zu füllen, müssen alle Werte eingelesen
werden (im Beispiel 1.000.000 Zahlen). Je nach Format des XML Dokuments und der
Implementierung des verwendeten XML Parsers kann es vorkommen, dass diese Werte
nicht auf einmal eingelesen werden und somit zwischengespeichert werden müssen. Die
Klasse MatlabElement übernimmt diese Zwischenspeicherung (vgl. Kap. 2.5). Um jedoch
weitere Elemente anzuhängen, muss neuer Speicher allokiert werden. Außerdem werden
in den Hilfsfunktionen Vektoren (dynamische Arrays) verwendet, um Speicher je nach
Bedarf bereitzustellen. Die gängige Vorgehenswiese wäre, die Daten aus dem Matlab
Element in einen Vektor zu kopieren, darin weitere Elemente anzuhängen, und danach
die Daten wieder zurück zu kopieren. Dies bedeutet zusätzliches Kopieren und temporär
erhöhten Speicherbedarf.
Um dieses Problem zu umgehen wurde die Klasse MemoryVector implementiert. Sie

besitzt die wichtigsten Funktionen eines STL Vektors. Anders als dieser kann sie aber auf
einem vorher definierten Speicherbereich arbeiten. Nach Vollendigung der gewünschten
Operation kann dieser Speicherbereich wieder vom Vektor abgekoppelt und anderwei-
tig verwendet werden. Somit ist keine Kopie von Daten notwendig, es wird auch kein
zusätzlicher Speicher verwendet.
Beim Hinzufügen von Elementen zu einem Vektor muss eventuell zusätzlicher Speicher
allokiert werden. Theoretisch genügt es, Speicher für ein einziges Element hinzuzufügen.
Jedoch ist es wahrscheinlich, dass noch weitere Elemente folgen werden. Damit nicht bei
jedem Hinzufügen allokiert werden muss, macht es durchaus Sinn, mehr Speicher bereit-
zustellen, als momentan benötigt wird. Die Größe dieses überschüssigen Speichers ist
aber nicht unbedeutend. Einerseits sollte der Bereich nicht zu groß gewählt sein, um kei-
nen Speicher unnötig zu verschwenden, andererseits sollte die Anzahl von Allokierungen
spürbar vermindert werden. Angenommen der Speicher wird jeweils um 100 Elemen-
te vergrößert. Dieser Wert ist nicht zu groß, als dass er als Verschwendung betrachtet
15
3 Implementierung
werden kann, andererseits sind sehr viele Allokierungen notwendig, falls die endgültig
benötigte Größe z.B. 1.000.000 beträgt. Auch ist ein konstanter Wachstumsfaktor, mit
dem die aktuelle Größe multipliziert wird, nicht zufriedenstellend. Entweder ist dieser
hoch gewählt, für eine starke Erhöhung bei kleinen Werten, oder niedrig, für rationale
Vergrößerung bei hohen Werten. Der Faktor ist aber für den jeweils anderen Fall nicht
akzeptabel. Die beste Möglichkeit liegt in einem dynamischen Wachstumsfaktor.
Bei der Entwicklung wurden mehrere Berechnungsmöglichkeiten für diesen dynami-

schen Faktor getestet. Das Ziel war eine Methode, die bei sehr kleinen Ursprungsgrößen
(<10 Elemente) eine starke Erhöhung (∼ Faktor 20), bei mittleren Größen (um 3.000)
ungefähr eine Verdoppelung, und auch bei sehr großen Datensätzen (>1.000.000) noch
ein Wachstum von 10% gegeben ist. Am besten eignete sich die hier vorgestellte Varian-
te, die auch implementiert wurde. Die Idee ist, den Wachstumsfaktor abhängig von dem
dekadischen Logarithmus der Ausgangsgröße zu machen. Hier ist eine linear abnehmen-
de Funktion wiederum zu einfach, da der Wachstumsfaktor zunächst zu schnell, später
zu langsam abnimmt, und irgendwann zu klein wird, evtl. auch negativ.
Abbildung 3.1: Graph der kumulativen Weibull Verteilungsfunktion (Quelle: [Wik07])
16
3 Implementierung
Als Vorlage für den Berechnungsalgorithmus diente die kumulative Verteilungsfunkti-

on der Weibull Verteilung2 . Abbildung 3.1 zeigt den Graphen dieser Funktion.
Die Verteilungsfunktion ist definiert als
x k
f (x; k; λ) = 1 − e−( λ ) (3.1)
Hier ist k der Formfaktor, λ der Skalierungsfaktor.
Die Funktion wurde abgewandelt, um die Bedürfnisse der Wachstumsfaktorfunktion

zu erfüllen. Der Graph wurde umgekehrt (durch Streichung des Therms “1 - ”), und um
weitere Parameter ergänzt. Die Wachstumsfaktorfunktion ist definiert als
x k
f (x; k; λ; i; m; a) = m · e−i·( λ ) + a (3.2)
Hierbei ist x die Ordnung der Ursprungsgröße, angegeben als log10 (s), wobei s die
Größe ist, k und λ wie oben, i der interne Anpassungsfaktor, m ein Multiplikator und
a ein additiver Wert. Durch ein Testprogramm wurden die optimalen Werte ermittelt,
indem das Wachstumsverhalten mit drei vorgegebenen Wertepaaren verglichen wurde3 .
Die Werte, die die geringste Abweichung von den geforderten Daten aufweisen, sind
k = 1, 5; λ = 7, 5; i = 9, 2; m = 17; a = 0, 1 (3.3)
Mit diesen Werten erfüllt die Wachstumsverhaltenskurve die oben angegebenen Anfor-
derungen am besten. Sie wird in Zukunft dynamischer Weibull Faktor Funktion genannt.
Abb. 3.2 stellt den Graphen der Wachstumsfunktion dar. Abb. 3.3 stellt das Verhält-
nis des Größenzuwachs und des Wachstumsfaktors zur aktuellen Größe dar, bei einer
anfänglichen Elementzahl von 1. Einige ausgewählte Datenpuntke sind in Tabelle 3.1
dargestellt. Wie zu sehen ist, liegt der Wachstumsfaktor bei kleinen Datengrößen relativ
hoch (17,1). Der Zuwachs ist höher als die aktuelle Größe, bis zum Wert von 2.525. Der
genaue Grenzwert ist 3.199, da aus Formel 3.2 und 3.3 folgt:
2
siehe [Wei51]
3
siehe Appendix B, “weibull parameter test”
17
3 Implementierung
Abbildung 3.2: Wachstumsfaktor in Abhängigkeit von log10 (Größe)
v v
w−a 1−0,1
u u
u
k ln m
3
u
2
ln 17
log10 (s) = x = λ · − = 7, 5 · − ≈ 3, 505
t t
i 9, 2
⇒ s = 103,505 ≈ 3.199
(w ist hier der Wachstumsfaktor). Hier fällt der Wachstumsfaktor unter 1, und nähert
sich asymptotisch dem Wert 0,1 (10% Wachstum).
Das Verhalten und die Performanz dieser Wachstumsfunktion und anderen, weiter
oben erwähnten Ansätzen wurde getestet. Die konkreten Testfälle und -ergebnisse wer-
den in Kap. 5.3 dargelegt.
18
3 Implementierung
Abbildung 3.3: Größenzuwachs und Wachstumsfaktor im Vergleich zur aktuellen Größe
Nr. Größe Faktor Zuwachs

1 1 17,10 17
2 18 9,14 165
...
5 2.525 1,12 2.834
6 5.359 0,78 4.156
...
15 104.381 0,21 21.973
16 126.354 0,20 24.953
17 151.308 0,19 28.223
18 179.531 0,18 31.814
19 211.346 0,17 35.760
20 247.106 0,16 40.097
...
37 2.053.410 0,11 234.032
38 2.287.442 0,11 258.270
39 2.545.711 0,11 284.938
...
Tabelle 3.1: Ausgewählte Datenwerte aus dem Wachstumsverhalten
19
3 Implementierung
3.3 Memory Management

Das Ziel des Imports bei der XML Toolbox ist es, Matlab Objekte zu erzeugen, die in
der Matlab Umgebung weiterverwendet werden können. Die Matlab Umgebung verwen-
det intern eine eigene Speicherverwaltung, um nicht mehr benötigten Speicher wieder
freizugeben. Alle Matlab Objekte müssen in den Matlab Speichertabellen aufgelistet sein.
Es ist zwingend notwendig, dass alle dynamisch allokierten Daten, die an die Matlab
Umgebung übergeben werden, mit den Matlab Speicherfunktionen allokiert wurden. An-
dernfalls kann es zu schwerwiegenden Problemen in der Umgebung, bis hin zum Absturz
und Datenverlust kommen.
Die Daten, die an die Matlab Umgebung übergeben werden, werden in der XML Tool-
box jedoch oft in tiefer liegenden Schichten erzeugt. Wegen der Trennung der Schich-
ten ist es nicht ratsam, die Matlab spezifischen Allokationsmethoden bereits in diesen
Schichten zu verwenden. Eine mögliche Lösung wäre, alle Daten, die an Matlab über-
geben werden, direkt vor der Übergabe in einen neuen Speicherbereich zu kopieren,
der mittels Matlab Funktionen allokiert wurde. Dieser Ansatz erfordert jedoch wieder
unnötiges Kopieren, und somit Laufzeiteinbuße.
Die in der XML Toolbox gewählte Lösung ist die des MemoryHandler. Ein Memory
Handler ist ein Objekt, das für die Allokierung und Deallokierung von Speicher zuständig
ist und dabei jede Funktion verwenden kann. So verwendet z.B. der Standard-Memory
Handler die globalen Operatoren new und delete, und der Matlab-Memory Handler die
Matlab Funktionen mxMalloc und mxFree. Bei allen speichererzeugenden Funktionen4
in der XML Toolbox kann solch ein Memory Handler Objekt angegeben werden. Durch
die Angabe des Matlab-Memory Handlers werden alle an Matlab übergebenen Daten
von Anfang an mit den Matlab Funktionen allokiert. Das zusätzliche Kopieren dieser
Daten ist somit nicht mehr notwendig.
Das Memory Handler Prinzip kann auch auf Bereiche angewandt werden, die eigentlich
keinen Speicher allokieren, der an Matlab zurückgegeben werden wird. Dennoch kann
ein Handler angegeben werden. Dies kann evtl. für höhere Performanz genutzt werden,
indem z.B. Handler für Memory Pools verwendet werden.
4
Darunter fallen z.B. die Stringkonvertierungsfunktionen aus Kap. 3.1, oder der MemoryVector aus
Kap. 3.2
20
3 Implementierung
3.4 Verwendung der Unicode Schicht

Wie bereits früher erwähnt war die Unicode Schicht ursprünglich optional. Es sollte
eine Version ohne Unicode Unterstützung möglich sein. Es schien als wäre der Aufwand,
die unterschiedlichen Unicode Kodierungen zu interpretieren, zu hoch, sowohl gemessen
an der Implementierungszeit, als auch an der Laufzeit. Die ursprüngliche XML Toolbox
sollte nur die Latin-1 Kodierung unterstützen, obwohl Matlab selbst Unicode unterstützt.
Auch XML Parser verwenden Unicode Kodierungen, um Strings intern darzustellen. Dies
folgt aus der W3C Spezifikation.
Bei der Entwicklung der XML Toolbox zeigte sich schnell, dass eine intene String-
darstellung als 8-Bit Zeichenketten nicht praktisch ist. In der eigentlichen Implementie-
rungsschicht, der Client Schicht, wurde mit 8-Bit Strings gearbeitet. Die Schnittstellen
zu Matlab und XML jedoch arbeiteten mit 16-Bit Unicode Strings. Es musste bei jedem
Schreiben und Lesen von XML Fragmenten eine Stringkonvertierung vorgenommen wer-
den. Auch bei der Auswertung oder Erzeugung von Matlab Strings musste konvertiert
werden.
Durch die Einführung der Unicode Schicht wurde dieses Problem behoben. Die String-
typen sind mit dieser Schicht alle äquivalent und können ohne Konvertierung oder Ko-
pieren verwendet werden. Somit wird weniger Speicher verbraucht und die Applikation
läuft schneller. Die Stringkonvertierungsfunktionen (siehe Kap. 3.1) ermöglichen aber
dennoch eine Unicode freie Version, ohne Änderungen am Source Code vornehmen zu
müssen.
21
4 Anwendung
Dieses Kapitel beschreibt kurz die implementierten Handler der Client Schicht. Es
erläutert weiters die Matlab-Schnittstellen, über die die verschiedenen Funktionen der
XML Toolbox aufgerufen werden können, und wie die Ein- bzw. Ausgabeformate die-
ser Funktionen aussehen. Weiters wird erläutert, welche XML-Parser-Bibliotheken un-
terstützt werden. Detailierte Informationen zu den Formaten und Funktionen befinden
sich auf der beiliegenden CD im Benutzerhandbuch (siehe Appendix A). Am Ende wer-
den noch einige Probleme der XML Toolbox aufgezeigt.
4.1 Client Handler

In Kapitel 2.6 wurden die Handlerklassen der Clientschicht vorgestellt. In der aktu-
ellen Version sind jeweils zwei Import- und Exporthandler implementiert. Diese bilden
quasi Handlerpaare, die dasselbe XML Format schreiben bzw. lesen können. Die Handler
sind DefaultMatlabExportHandler / DefaultMatlabImportHandler für das Standard-
format, und XMLAttrExportHandler / XMLAttrImportHandler für das XML-Attribut-
Format.
Das Standardformat ist geeignet für den Datenaustausch zwischen Matlab-Applikationen.

Es werden zu jedem Element Typinformationen geliefert, die sowohl den Datentyp als
auch die Dimensionen des Elements festlegen. Auch können bestimmte Elemente wei-
tere Elemente beinhalten (z.B. Strukturen oder Cell-Arrays). Somit können beliebige
Matlab-Objekte ausgetauscht werden. Falls die Typinformationen nicht vorhanden sind,
werden alle Elemente zu Strings (falls keine Unterelemente vorhanden sind) oder zu
Strukturen.
Das XML-Attribut-Format ermöglicht das Importieren von beliebigen XML-Dokumenten.

Dabei wird die XML Dokumentstruktur auf eine Matlab-Struktur abgebildet. Spezielle
Felder (ATTRIBUTE Felder) speichern die XML Attribute der Elemente. Der Elementin-
22
4 Anwendung
halt wird in einem CONTENT Feld als String gespeichert. Da XML-Elemente desselben
Namens unterschiedliche Inhalte besitzen können (z.B. optionale Unterelemente), dies
jedoch nicht als Matlab Struktur abgebildet werden kann (da alle Strukturen einer Struk-
turmatrix dieselben Felder besitzen), werden Elemente mit demselben Namen in Cell-
Arrays gekapselt. Somit können diese auch in Matlab unterschiedliche Inhalte besitzen.
XML Elementnamen, die in Matlab ungültige Feldnamen darstellen, werden durch

gültige Namen ersetzt. Der Originalname bleibt aber erhalten, und wird als TAGNAME
Feld gespeichert. Ähnlich verhält es sich mit dem Namespace (der ’:’ ist in Feldnamen
nicht erlaubt). Er wird als NAMESPACE Feld gespeichert.
4.2 Aufruf aus Matlab

Die Funktionen der XML Toolbox werden über sogenannte MEX-Files aufgerufen. Ein
MEX-File ist im Grunde genommen eine dynamische Bibliothek, die eine Funktion mit
bestimmter Signatur exportiert. Diese wird von der Matlab-Umgebung aufgerufen. Der
Name des Matlab-Kommandos, um die Funktion aufzurufen, stimmt mit dem Datei-
namen des MEX-Files überein.
Die XML Toolbox stellt vier MEX-Files zur Verfügung. Diese dienen als Wrapper,
um die Eingabeparameter zu überprüfen, und rufen die entsprechende Client-Handler-
Implementierung auf, die das gewünschte Format importiert bzw. exportiert. Die bereit-
gestellten Kommandos sind:
• xml export: Exportiert den übergebenen Ausdruck in einen String
• xml fexport: Exportiert den übergebenen Ausdruck in eine Datei
• xml import: Importiert einen XML String
• xml fimport: Importiert eine XML Datei
Bei den Exportkommandos können folgende Attributtyp-Parameter angegeben wer-

den:
• type: Schreibt Typinformationen (Standard)
• none: Schreibt keine Typinformationen
23
4 Anwendung
• xml: Exportiert mit dem XML-Attribut-Export-Handler

Zusätzlich kann noch der gewünschte Name des Rootelements angegeben werden. Die
Datei-Variante benötigt auch den Namen der Datei, in die geschrieben werden soll. Es
kann auch eine Kodierung angegeben werden.
Bei den Importkommandos können folgende Attributtyp Parameter angegeben wer-

den:
• type: Typinformationen werden ausgewertet (Standard)
• none: Typinformationen werden ignoriert
• xml: Importiert mit dem XML-Attribut-Import-Handler
• xml parse: Importiert ebenfalls mit dem XML-Attribut-Import-Handler. Es wird

versucht, numerische Inhalte als Doublematrizen zu parsen.
Wenn keine Typinformationen vorhanden sind, oder explizit ignoriert werden, so wer-
den alle Elemente zu Strings.
Weitere Informationen zu den XML Formaten und den Kommandos befinden sich im
Benutzerhandbuch (siehe Appendix A).
4.3 XML Parser Bibliotheken

Wie in Kapitel 2.4.1 erwähnt, kann die XML-Parser-Bibliothek ausgetauscht werden,
die für das eigentliche Parsen von XML-Dokumenten verwendet wird. In der aktuellen
Version werden Apache Xerces-C 2.7.01 und Expat 2.0.12 unterstützt.
Zu Beginn der Entwicklung wurde hier auf die Xerces Bibliothek aufgebaut. Ich hatte
persönlich bereits Erfahrung mit dieser Bibliothek und Matlab verwendet intern ebenfalls
Xerces. Als die Impementierung weiter fortgeschritten war, und Tests mit Dokumenten
durchgeführt wurden, die große Elementinhalte besitzen (z.B. 1.000.000 Fließkommazah-
len), sind Probleme mit der Xerces Bibliothek aufgetreten. Durch Zeitmessungen wurde
festgestellt, dass Xerces sehr viel Zeit braucht, um den Textinhalt einzulesen. Somit dau-
erte der Import sehr lange (Test nach 10 Minuten abgebrochen, ohne dass Xerces den
Text vollständig eingelesen hatte).
1
Siehe http://xml.apache.org/xerces-c/
2
Siehe http://expat.sourceforge.net/
24
4 Anwendung
Später wurde mir die Expat Bibliothek empfohlen. Diese hat dieses Problem nicht.
Hier wird immer nur eine vorher definierte Anzahl an Bytes eingelesen und geparst. Somit
reagiert der Parser schneller, jedoch nur mit Fragmenten des Textinhalts. Dies stellte
jedoch kein Problem dar, da die darüberliegende Matlab Schicht bereits für diesen Fall
vorbereitet war. Tests ergaben, dass dieselben Testfälle wie mit der Xerces Bibliothek
mit Expat nach ∼ 7 Sekunden abgeschlossen waren.
Die Xerces Bibliothek wird noch unterstützt, es wird aber empfohlen, die Expat Bi-
bliothek zu benutzen.
25
4 Anwendung
4.4 Probleme der XML Toolbox

4.4.1 Mangelnde Fehlerinformationen
Wenn das Importieren von XML-Dokumenten fehlschlägt, werden Informationen über
die Ursache ausgegeben. Wenn ein Ein-/Ausgabefehler auftritt, oder das XML-Dokument
ungültig ist, kann der Fehler gut identifiziert werden. Wenn jedoch ein Fehler in der
Struktur des XML-Dokuments vorliegt (z.B. Dimensionsangabe stimmt nicht mit Ele-
mentzahl überein), wird nur eine Meldung ausgegeben, dass ein Fehler aufgetreten ist.
Hier könnten bessere Fehlerinformationen angegeben werden.
4.4.2 XML Attribut Stil

Wie in Kapitel 4.1 erwähnt, können beliebige XML-Dokumente mit dem XML-Attribut-
Handler importiert werden. Dabei können verschiedene Probleme auftreten. Zunächst
wird Textinhalt von Elementen ignoriert, die auch Unterelemente besitzen. Dies wird
jedoch kein großes Problem darstellen, da mit der XML Toolbox hauptsächlich XML-
Dokumente mit einem strukturähnlichen Format importiert werden. Dort tritt dieser
Fall selten auf.
Ein weiteres Problem stellen Zeilenumbrüche in Textelementen dar. Diese werden

meist von Leerzeichen gefolgt (wegen Einzug). Diese Leerzeichen sind sogenannter “igno-
rable whitespace”. Beim Import werden diese Leerzeichen nicht ignoriert und an den Text
angehängt. Bei einem Export der erzeugten Matlab-Struktur werden Textinhalte in ei-
ner einzelnen Zeile geschrieben, wodurch zusätzliche Leerzeichen in den Text geschrieben
werden.
Beim Import werden, wie bereits erwähnt, Unterelemente mit gleichem Namen in ein
Cell-Array gekapselt. Für diesen Zweck werden die Unterelemente beim Import alpha-
betisch sortiert. Bei einem Export der erzeugten Matlab-Struktur werden die Elemente
somit ebenfalls alphabetisch sortiert ausgegeben. Ein solches Dokument kann für einen
nachgestellten Prozess unlesbar sein, wenn dieser die Elemente in einer gewissen Reihen-
folge erwartet. Auch kann das ursprüngliche XML Dokument mit einem Schema validiert
worden sein, zu dem das neue Dokument nicht mehr valide ist.
26
5 Test
Dieses Kapitel beschreibt die durchgeführten Tests mit der XML Toolbox. Es werden
zunächst die Testmethodik und verwendete Ressourcen beschrieben, gefolgt von der In-
terpretation der Testergebnisse. Alle Codeteile für die Tests befinden sich in Appendix
B, die Testfälle selbst mit den jeweiligen Ergebnissen in Appendix C. Alle Tests wur-
den mit Matlab Version 7.3.0.267 (R2006b) auf einem PC mit Microsoft Windows XP,
Service Pack 2, 1024 MB RAM und Intel Pentium 4 Dual Core 3 GHz Prozessor durch-
geführt. Dabei wurde ausschließlich die Expat XML Parser Bibliothek verwendet. Die
XML Toolbox wurde mittels Microsoft Visual Studio .NET 2005 (VC8.0) kompiliert.
5.1 Testmethodik
Die XML Toolbox wurde hinsichtlich verschiedener Aspekte getestet. Zunächst wurde
die reine Funktionalität getestet. Mit diesen Tests wird überprüft, ob die Toolbox Matlab
Daten korrekt importiert und exportiert. Weiters wurden Performanztests durchgeführt,
sowohl die Laufzeit von Import und Export, als auch deren Speicherverbrauch betreffend.
Weitere Tests vergleichen die XML Toolbox mit der als Vorlage dienenden Geodise
Toolbox.
Funktionalitätstests
Bei diesen Tests wird eine Matlab Datenstruktur in eine Datei exportiert und wieder
importiert. Die importierte Struktur wird dann mit der Originalstruktur verglichen. Da
Fließkommazahlen nur bis zu einer gewissen Genauigkeit exportiert werden, können diese
geringfügig vom Original abweichen. Die maximal erlaubte Abweichung wird über einen
Grenzwert festgelegt. Der Vergleich der Strukturen erfolgt über die compare Funktion
von Nicholas Gigis1 , mit kleinen Änderungen2 .
1
siehe http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=3449 (Stand
31.7.2007)
2
siehe Appendix B, “compare”
27
5 Test
Laufzeittests
Die Laufzeittests führen eine beliebige Import- oder Exportoperation aus, wobei die Zeit
gemessen wird, die für diese Operation benötigt wurde. Es können mehrere Testläufe
durchgeführt werden, um mehr Daten zu erhalten. Die Zeitmessung erfolgt über die
Matlab Methoden tic und toc3 .
Speichertests
Beim Testen von Speicherverbrauch wird ebenfalls eine Import- oder Exportoperation
ausgeführt. Vor der Operation wird der aktuelle Speicherverbrauch des Matlab Prozes-
ses notiert. Dies wird ebenfalls nach der Operation gemacht. Die Differenz wird mit der
Größe der erzeugten Daten (z.B. beim Import von Datenstrukturen) verglichen. Diese
wird über das Matlab Kommando whos ermittelt, und sollte immer genau der Differenz
entsprechen. Hier könnten lediglich eventuelle Speicherlecks entdeckt werden. Diese sind
aber unwahrscheinlich, da Matlab nicht mehr benötigten Speicher nach der Ausführung
von MEX-Routinen automatisch wieder freigibt. Wichtiger ist der Speicherverbrauch
während der Ausführung der Operation. Die Daten über den Speicherverbrauch wer-
den über das Profilingprogramm “Process Explorer for Windows v10.21” von Mark
Russinovich4 ermittelt.
Vergleichtests mit der Geodise Toolbox

Hierbei wurde der Speicherverbrauch und die Zeit bestimmt, die beim Import bzw.
Export mit der Geodise Toolbox und bei der XML Toolbox benötigt wurden. In manchen
Fällen konnte der Export mit der Geodise Toolbox nicht fertiggestellt werden. Hierbei
wurde der Import mit dem von der XML Toolbox erstellten XML-Dokument getestet.
5.2 Testergebnisse
In diesem Abschnitt werden die Ergebnisse der druchgeführten Tests interpretiert. Die
duchgeführten Testfälle und die konkreten Ergebnisse sind in Appendix C beschrieben.
Aus den durchgeführten Funktionalitätstest folgt, dass beliebige Kombinationen von

Matlab-Strukturen exportiert und wieder importiert werden können. Fließkommazahlen
werden mit einer Genauigkeit von 14 signifikanten Stellen exportiert. Bei der Verwendung
3
siehe [Mat07b]
4
siehe http://www.microsoft.com/technet/sysinternals/utilities/ProcessExplorer.mspx (Stand
31.7.2007)
28
5 Test
des XML-Attribut-Import-Handlers treten jedoch Probleme auf. Diese sind in Kap. 4.4
genauer ausgeführt.
Die Zeittests zeigen, dass die Latin-1 Kodierung am effizientesten geschrieben und
gelesen werden kann. Auch sinkt damit die Dateigröße im Vergleich zu UTF-16. Jedoch
können damit nicht alle Zeichen dargestellt werden. UTF-8 ist beinahe gleich effizient
und hat diesen Nachteil nicht. Es sollte daher diese Kodierung verwendet werden.
Der Export ist offensichtlich performanter (Zeit und Speicher), wenn kleine Daten-
strukturen exportiert werden. Dies zeigen die Speichertestfälle, wenn als Referenzwert
die Datengröße in Matlab herangezogen wird. Bei den Testfällen 4a und 4b wird kaum
Speicher verbraucht. Bei Testfall 4c und 4d liegt der Speicherverbrauch mit ∼50 MiB5
etwa bei dem Doppelten der Strukturgröße. Man kann ebenfalls sehen, dass mehrere
große Strukturen exportiert werden wie einzelne (Speicher bei Testfall 4d gleich wie
bei 4c). In den Testfällen 4e und 4f können die Daten nicht unterteilt werden, und die
Speicherauslastung steigt rapide.
Der Import mit statischer und dynamischer Speicherermittlung sind annähernd gleich
schnell. Nur beim Import von vielen kleinen Objekten ist die dynamische Ermittlung
merklich langsamer (Testfall 4b). Die stark erhöhte Speicherauslastung bei großen Da-
tenmengen (Testfälle 4e und 4f) kann ich mir nicht erklären. Laut dynamischem Weibull-
faktor müsste bei Testfall 4f lediglich 3,14 MiB überschüssiger Speicher allokiert werden,
und nicht 534,0 MiB (siehe Kap. 5.3).
Im Vergleich zur Geodise Toolbox ist sowohl Export als auch Import immer schnel-
ler und verbraucht weniger Speicher. Besonders bei vielen kleinen (Testfall 4a und 4b)
und sehr großen Elementen (4e und 4f) ist Geodise merklich langsamer und verbraucht
mehr Speicher (Testfall 4f konnte wegen Speicherproblemen weder exportiert noch im-
portiert werden). Beim Export von großen Strukturen (Testfall 4c und 4d) ist Geodise
etwas langsamer. Der Speicherverbrauch ist dennoch um einiges höher. Der Import dieser
Testfälle dauert wiederum merklich länger, sodass die Tests hier abgebrochen wurden.
In dieser Zeit stieg der Speicherverbrauch so stark, dass das Betriebssystem 80% der
Auslagerungsdatei gefüllt hatte.
5
1 MiB (Mebi Byte) ≡ 220 = 1.0242 = 1.048.576 Bytes
29
5 Test
5.3 Test der Wachstumsfunktion

In Kapitel 3.2 wurde die Wachstumsfunktion der MemoryVector Klasse erklärt. Das
Ziel war eine Funktion, die Arbeitsspeicher entsprechend den Bedürfnissen allokiert. Es
wurden auch andere Ansätze, wie das Vergrößern des Speicherbereichs um einen fixen
Wert (100 Elemente), oder durch Multiplizieren der Größe mit einem konstanten Faktor
(2) erwähnt.
Das Verhalten der implementierten Wachstumsfunktion und der beiden oben erwähn-
ten Funktionen wurde getestet. Zum einen wurde ein theoretischer Test durchgeführt,
mit dem ermittelt wird, wie viele Reallokierungen nötig sind, bis eine gewünschte Größe
erreicht wird, und um wieviel die erbrachte Größe die gewünschte überschreitet. Weiters
wurde ein praktischer Test durchgeführt, mit dem das tatsächliche Verhalten der drei
Funktionen in der Matlab Umgebung unter Realbedingungen verglichen wurde.
5.3.1 Theoretische Tests

Tabelle 5.1 zeigt die Ergebnisse der theoretischen Tests6 . Es wird gezeigt, wie viele
Allokierungen bei den einzelnen Funktionen nötig waren, um eine bestimmte Größe zu
erreichen. Die tatsächliche Endgröße sowie die Differenz zur gewünschten Größe werden
ebenfalls dargestellt.
Es ist ersichtlich, dass der dynamische Weibull Faktor kleine Größen am schnellsten
erreicht. Dafür hat er in diesem Bereich die größte Differenz zum benötigten Wert. Bei
den höheren Werten braucht er etwas mehr Allokierungen als der fixe Faktor, hat dafür
aber eine merklich kleinere Differenz. Die Erhöhung um einen fixen Wert benötigt bereits
bei mittleren Größen viel mehr Allokierungen und ist deswegen nicht geignet.
5.3.2 Praktische Tests

Bei den praktischen Tests wurde ein vergleichbares Ergebnis erziehlt. Bei den Tests
wurde eine Struktur ohne Typinformationen exportiert. Das resultierende XML Doku-
ment wurde dann wieder importiert, wobei Dateninhalte geparst wurden (siehe Kap.
4.2). Dies erzwingt das dynamische Ermitteln und Allokieren von Speicher beim Import
der Daten.
6
siehe Appendix B, “growth algorithm test”
30
5 Test
Gewünschte Größe Nr. Allokierungen Endgröße Differenz

Fixer Wert (100)
100 2 110 10
1.000 11 1.010 10
100.000 1.001 100.010 10
1.000.000 10.001 1.000.010 10
3.000.000 30.001 3.000.010 10
Fixer Faktor (2)
100 5 160 60
1.000 8 1.280 280
100.000 15 163.840 63.840
1.000.000 18 1.310.720 310.720
3.000.000 20 5.242.880 2.242.880
Dynamischer Weibull Faktor
100 2 119 19
1.000 4 2.071 1.071
100.000 15 121.306 21.306
1.000.000 30 1.021.100 21.100
3.000.000 40 3.073.538 73.538
Tabelle 5.1: Theoretisches Wachtumsverhalten der Wachstumsalgorithmen
Es wurden drei Situationen getestet, bei denen jeweils große Datenmengen importiert
wurden. Beim ersten Test wurde eine Struktur verwendet, die mittels createDS(1)
erzeugt wurde7 . Diese enthält zwei mittelgroße und eine große Matrix. Beim zweiten
wurde eine Struktur durch createDS(3) erzeugt. Diese hat sechs mittelgroße und drei
große Matrizen. Im letzten Test wurde eine zufällige Matrix mittels rand(300, 100,
100) erzeugt. Diese enthält 3.000.000 Elemente.
Tabelle 5.2 zeigt das Verhalten der verschiedenen Algorithmen bei den Testfällen.
Es wird die Größe der importierten Daten, der Speicherverbrauch vor und nach dem
Import, der höchste Speicherverbrauch während des Imports, und die benötigte Zeit
angegeben. Auch wird der überschüssige Speicher angegeben, um den der Höchstwert
den Speicherverbrauch nach dem Import übersteigt. Es ist zu sehen, dass die Erhöhung
um einen fixen Wert um den Faktor 40 langsamer ist als die beiden anderen Methoden.
Diese benötigen ungefähr gleich lange, die Weibull Faktor Methode ist aber geringfügig
langsamer. Dafür hat diese weniger Speicher während des Imports verwendet. Die Frage,
warum bei der Erhöhung um einen fixen Wert am meisten Speicher verwendet ist, obwohl
7
Siehe Appendix B, “createDS”
31
5 Test
dort der Overhead maximal 100 Elemente betragen kann, konnte ich nicht klären.
Funktion Vorher (MiB) Nachher (MiB) Hoch (MiB) Überschuss (MiB) Zeit (s)
createDS(1) (7,86 MiB)
Fixer Wert 30,3 39,1 69,8 30,7 101,93
Fixer Faktor 30,4 39,3 45,1 5,8 2,46
Weibull Faktor 30,3 39,0 39,0 0,0 2,55
createDS(3) (23,6 MiB)
Fixer Wert 54,0 78,5 153,7 75,2 304,89
Fixer Faktor 54,0 78,7 128,5 49,8 7,23
Weibull Faktor 54,0 78,4 120,9 42,5 7,63
rand(300, 100, 100) (22,89 MiB)
Fixer Wert 30,4 — 192,2 161,81 —2
Fixer Faktor 31,1 54,1 170,8 116,7 7,29
Weibull Faktor 31,1 54,8 154,4 99,6 7,65
1
Verglichen mit Speicher vor dem Import
2
Nach 10 Minuten abgebrochen
Tabelle 5.2: Praktischer Test der Wachstumsalgorithmen
32
6 Zusammenfassung und Ausblick
Die XML Toolbox ermöglicht es, Datenstrukturen aus Matlab effizient zu exportie-
ren und wieder zu importieren. Es können somit Strukturen in einem XML Format
gespeichert und ausgetauscht werden, welches auch von Drittkomponenten gelesen bzw.
geschrieben werden kann, im Gegensatz zum proprietären Mat-Dateiformat von Matlab.
Weiters können beliebige XML Dokumente in Matlab Strukturen umgewandelt werden,
um sie dort zu verarbeitet. Dabei sind die Formate kompatibel zur bereits existierenden
Geodise XML Toolbox. Jene kann durch diese Toolbox ausgetauscht werden.
Der modulare Aufbau der XML Toolbox ermöglicht es, einfach neue Formate hinzu-
zufügen. Es müssen nur die entsprechenden Import- und Export-Handler geschrieben
und eine Schnittstelle für die Matlaboberfläche erstellt werden. Es können auch andere
XML-Parser Bibliotheken mit geringem Aufwand verwendet werden.
Die Tests zeigen, dass der Import- und Exportvorgang mit geringem Speicherver-
brauch und in kurzer Zeit erfolgen. Im Vergleich zur Geodise Toolbox zeigt sich, dass
die Vorgänge um ein vielfaches schneller ablaufen und dabei eine geringere Speicheraus-
lastung haben. Auch können größere Matrizen behandelt werden, ohne wegen Speicher-
mangel abgebrochen zu werden.
In Zukunft könnten noch weitere XML Formate bei Bedarf implementiert werden. Die
Portierung auf weitere Plattformen, wie unterschiedl. Linux Distributionen oder Solaris,
stehen noch aus. Durch die Abstraktion mittels der Plattformschicht wird dies jedoch
keine großen Auswirkungen haben und mit geringem Aufwand geschehen können.
Einige Probleme mit der XML Toolbox könnten auch behoben werden. Bei einem
fehlgeschlagenen Import von XML Daten sollten detailiertere Meldungen erfolgen. Mo-
mentan werden lediglich ungültige Zeichen und invalide XML Dokumente gemeldet. Bei
logischen Fehlern der Struktur des XML Dokuments (z.B. falsche Dimensionsangaben)
wird nur gemeldet, dass das Importieren fehlgeschlagen ist, jedoch nicht warum.
33
6 Zusammenfassung und Ausblick
Das Umsortieren der Strukturelemente bei einem XML-Attribut Import und Export
(siehe Kap. 4.4) kann Probleme bereiten, v.a. wenn die XML Dokumente mit einem
Schema validiert werden sollen. Dieses Problem kann umgangen werden, wenn die Sche-
mata entsprechend angepasst werden. Falls dies nicht möglich ist, und die Validierung
wichtig ist, könnte eine generelle Lösung für dieses Problem erarbeitet werden, indem die
Import- und Export-Handler und das XML Format umgeschrieben werden. In diesem
Zuge wäre es auch möglich, die Validierung der exportierten XML Dokumente mit der
XML Toolbox selbst durchzuführen.
Zusammenfassend lässt sich sagen, dass die XML Toolbox eine Alternative zur Geodise
Toolbox bietet. Dabei ist sie voll kompatibel zu dieser, jedoch performanter was Lauf-
zeit und Speicherverbrauch angeht. Sie hat aber dieselben Probleme was die Struktur
mancher XML Dokumente betrifft. Diese können aber durch Erweiterungen behoben
werden, falls sich dies als notwendig erweist.
34
Literaturverzeichnis
[Con06] The Unicode Consortium. The Unicode Standard, Version 5.0. Addison-
Wesley Professional, 5th edition, November 2006. ISBN: 0321480910.
[GEO07] GEODISE. XML Toolbox Homepage. Online, Juli 2007.

http://www.geodise.org/toolboxes/generic/xml toolbox.htm.
[Mat07a] Matworks. Matlab Homepage. Online, Juli 2007.

http://www.mathworks.com/products/matlab/.
[Mat07b] Matworks. Matlab technical documentation. Online, Juli 2007.

http://www.mathworks.com/access/helpdesk/help/techdoc/.
[W3C06] W3C. Extensible Markup Language (XML) 1.1 (Second Edition). Online,
September 2006. http://www.w3.org/TR/xml11/.
[Wei51] Waloddi Weibull. A statistical distribution function of wide applicability. J.

Appl. Mech.-Trans. ASME, 18(3):293–297, 1951.
[Wik07] Wikipedia. Weibull distribution. Online, Juli 2007.

http://en.wikipedia.org/wiki/Weibull distribution.
35
Abbildungsverzeichnis
2.1 Übersicht über die XML Toolbox Schichten . . . . . . . . . . . . . . . . . 5

2.2 Komponenten für das Schreiben von XML Dokumenten . . . . . . . . . . 7
2.3 Komponenten für das Lesen von XML Dokumenten . . . . . . . . . . . . 8
2.4 Beispiel: Arbeiten mit den MatlabBuilder Stacks . . . . . . . . . . . . . . 11
3.1 Graph der kumulativen Weibull Verteilungsfunktion . . . . . . . . . . . . 16

3.2 Wachstumsfaktor in Abhängigkeit von log10 (Größe) . . . . . . . . . . . . 18
3.3 Größenzuwachs und Wachstumsfaktor im Vergleich zur aktuellen Größe . 19
36
Appendix A – Inhalt der CD
Die beiliegende CD enthält neben der XML Toolbox weitere Dokumente. Die Ver-
zeichnisstruktur sieht wie folgt aus:
+ Root
|— CMake
|— Expat
|— Manual
|— Testtools
|–+Thesis
| |— src
|
|–+XML Toolbox
| |— bin
| |— src
CMake Dieses Verzeichnis enthält die bei der Erstellung der XML Toolbox verwendete
CMake Version 2.4.7, als Windows 32 Setup und als Sourcecode.
Expat Dieses Verzeichnis enthält die verwendete Expat Version 2.0.1 als Sourcecode,
sowie kompiliert für Windows 32 und MacOS X.
Manual Dieses Verzeichnis enthält die englische Bedienungs- und Installationsanlei-

tung für die XML Toolbox im HTML Format.
Testtools Hier sind alle bei den Test verwendeten C++ und Matlab Programme ent-
halten, die in Appendix B erwähnt werden. Weiters enthält das Verzeichnis alle Testdo-
kumente.
Thesis Dieses Verzeichnis enthält dieses Dokument.
37
Thesis\src Dieses Verzeichnis enthält den LATEX Source Code dieses Dokuments, so-
wie alle Originalbilder und Dokumente, die zur Erstellung dieses Dokuments verwendet
wurden.
XML Toolbox Dieses Verzeichnis enthält die eigentliche XML Toolbox.
XML Toolbox\bin Enthält kompilierte Versionen für diverse Plattformen.
XML Toolbox\src Enthält den Sourcecode der XML Toolbox.
Das Profilingprogramm “Process Explorer” ist nicht auf der CD enthalten. Kapitel 5.1
enthält die URL, unter der das Programm gratis vorzufinden ist. Bei allen anderen Kom-
ponenten von Drittanbietern ist ausdrücklich erlaubt, diese in Source- und Binärform zu
verteilen.
38
Appendix B – Programmteile
weibull parameter test

Dieses Testprogramm ermittelt die optimalen Parameter für die dynamische Weibull
Faktor Funktion (siehe 3.2). Es werden Grenzen für die Parameter k, λ, i, m und a
definiert und das beste 5er-Tupel in diesen Grenzen ermittelt. Die Grenzen für die ersten
dieser drei liegen bei 1 und 10, da die Kurve sonst ausartet und höhere bzw. niedrigere
Werte keine brauchbaren Ergebnisse liefern. Die Grenzen für m sind 17 und 23, um einen
maximalen Wachstumsfaktor von ∼20 zu erhalten. Die Grenzen für a liegen bei 0 und
1, da hiermit das minimale Wachstum angegeben wird.
Alle Kombinationen dieser Werte werden als Parameter für die Wachstumsfunktion
getestet. Die resultierenden Funktionen werden mit drei Referenzgleichungen überprüft.
Diese sind
f (6, 0) = 0, 1 (1)
f (3, 5) = 1, 0 (2)
f (2, 5) = 3 (3)
Der Parameter ist dabei jeweils der log10 (s), wobei s die aktuelle Größe darstellt.
Gleichung 1 legt fest, dass das Wachstum bei 1.000.000 (106 ) bei 10% liegen soll. Glei-
chung 2 gibt die Grenze für Speicherverdoppelungen an, die bei ∼ 3.162 (103,5 ) liegen
soll. Gleichung 3 legt eine Vervierfachung des Speichers bei ∼ 316 (102,5 ) fest, damit der
Funktionswert für kleine Werte nicht zu schnell abnimmt.
Nur jene Wertepaare, die alle Gleichungen mit einer maximalen Abweichung von 0,1
lösen, werden in Betracht gezogen. Die Ergebnisse werden aufsteigend nach durchschnitt-
licher Abweichung sortiert und die besten drei Ergebnisse ausgegeben.
39
growth algorithm test
Dieses Testprogramm misst die Anzahl von Allokierungen, die bei der Verwendung
von verschiedenen Wachstumsfunktionen nötig sind, um bestimmte Datenmengen zu
allokieren. Es wird kein Speicher allokiert und stellt lediglich eine Simulation dar. Es wird
die Anzahl der Allokierungen, die endgültig allokierte Datenmenge, und die Abweichung
von der gewünschten Datenmenge ausgegeben. Es werden die Datenmengen 100, 1.000,
100.000, 1.000.000 und 3.000.000 getestet.
Es werden drei Wachstumsfunktionen getestet. Die erste ist grow fv, für ein Wachstum
um einen konstanten Wert (100). Die zweite Funktion grow ff multipliziert die aktuelle
Größe mit einem konstanten Wert (2, für Verdoppelung). Die letzte ist grow wb, für den
dynamischen Weibull Faktor. Alle Funktionen erhalten die aktuelle Größe als Eingabe,
und geben den Wert 10 zurück, wenn diese 0 ist.
compare
t = compare(s1, s2, [file, tol])
Vergleicht die Matlab-Ausdrücke s1 und s2. Diese müssen in einfachen Anführungs-

strichen stehen. file ist eine optionale Angabe eines Dateinamens, in die die Ausgabe
geschrieben werden soll. tol ist die Toleranz für den Vergleich von Fließkommazahlen.
Dies ist notwendig, da diese durch Import und Export vom Original leicht abweichen
können. Die Implementierung basiert auf Nicholas Gigis’s compare Funktion, eingereicht
auf Matlab Central1 . Es wurden aber kleine Anpassungen vorgenommen. Ursprünglich
lieferte die Funktion false zurück, wenn Fließkommazahlenwerte unterschiedlich waren,
aber innerhalb der Toleranzgrenzen lagen. Dies wurde behoben. Alle Änderungen sind
mit Kommentaren identifiziert.
1
siehe http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=3449 (Stand
31.7.2007)
40
createCell
a = createCell(ct, dim1, dim2)
Erzeugt ein Cell-Array mit ct Zellen. Jede Zelle enthält eine Double-Matrix der Größe
dim1 x dim2, gefüllt mit zufälligen Werten. Diese Funktion wird in mehreren Testfällen
verwendet.
createDS
a = createDS(NUM)
Erzeugt NUM Strukturen mit Feldern aller unterstützter Datentypen. Die Strukturen
haben folgende Form:
a.string char [1x4]

a.int int [1x1]
a.double double [1x1]
a.cell cell{2,2} [1x1]
a.structure.a char [1x5]
a.structure.b char [1x5]
a.matrix double [10000x1]
a.matrix1 double [100x100]
a.matrix2 double [100x100x100]
a.matrix3 double [10x10x10x10]
a.complex complex [1x1]
a.complex mat complex [1x4]
a.sparse sparse [100x100]
a.char array cell{2,2} [1x1]
Diese Struktur enthält sehr große Felder (matrix[1-3]) und eignet sich daher auch
für Auslastungstests. Die Funktion wird in mehreren Testfällen verwendet. Sie wurde
von Thomas Ludescher und Thomas Geiger (FHV) zur Verfügung gestellt.
41
time measure
t = time measure(e, [count])
Misst die Zeit, um den Ausdruck e auszuwerten (muss in einfache Anführungsstriche

gesetzt werden). Wertet den Ausdruck count male aus, und gibt die Ausführungszeiten
zurück.
xml test
[c,texp,timp] = xml test(value, [tol], [count], [fname], [exp arg], [imp arg],
[encoding])
Führt einen Testlauf der XML Toolbox aus. Exportiert den Wert value in eine Da-
tei und Importiert diese wieder. Der importierte Wert wird mittels compare mit dem
Originalwert verglichen. Die Funktion hat folgende zusätzliche optionale Parameter:
• tol: Toleranz für den Vergleich. Siehe compare
• count: Anzahl der Testläufe, die durchgeführt werden sollen
• fname: Dateiname für die XML-Datei. Platzhalter %d wird durch die Laufnummer
ersetzt
• exp arg: Attributeparameter für Exportfunktion. Siehe Kapitel 4.2
• imp arg: Attributeparameter für Importfunktion. Siehe Kapitel 4.2
• encoding: Dateikodierung
Die Funktion gibt folgende Werte zurück:
• c: Ob alle Vergleiche ohne Fehler waren
• texp: Dauer der Exportoperationen
• timp: Dauer der Importoperationen
Wenn value in einfachen Anführungsstrichen steht, wird der Ausdruck vor jedem
Testlauf erneut ausgewertet.
42
Appendix C – Testfälle und -ergebnisse
1. Funktionalitätstests
Test 1a: Genauigkeit Fließkommazahlen (10−10 )
Testfall
xml test(’rand(10, 10);’, 1e-10, 10)
Beschreibung
Exportiert zehn mal eine zufällige 10x10 Fließkommazahlmatrix. Die Zufallswerte wer-
den bei jedem Export neu ermittelt. Die Zahlen werden mit einer Toleranz von 10−10
verglichen.
Ergebnis
Alle Zahlen wurden innerhalb der Toleranz korrekt exportiert und importiert.
Test 1b: Genauigkeit Fließkommazahlen (10−14 )

Testfall
xml test(’rand(10, 10);’, 1e-14, 10)
Beschreibung
verglichen.
Ergebnis
Alle Zahlen wurden innerhalb der Toleranz korrekt exportiert und importiert.
43
Test 1c: Genauigkeit Fließkommazahlen (10−15 )
Testfall
xml test(’rand(10, 10);’, 1e-15, 10)
Beschreibung
verglichen.
Ergebnis
Innerhalb der Toleranzgrenze weichen die meisten Zahlen von den Originalzahlen ab.
Test 1d: Dünnbesetzte komplexe Matrix

Testfall
m = magic(1000);
m(m > 50) = 0;
m = sparse(sqrt(-m));
xml test(m)
Beschreibung
Erzeugt eine 1.000x1.000 Matrix, die ein magisches Quadrat bildet1 . Alle Werte > 50
werden durch 0 ersetzt. m wird negiert und die Quadratwurzel wird gezogen. Dadurch
werden alle Elemente 6= 0 imaginäre Zahlen. m wird in eine dünnbesetzte Matrix (engl.
sparse matrix) umgewandelt.
Bei dieser Konstellation (dünnbesetzte komplexe Matrix) werden mehrere, verschach-

telte XML Elemente exportiert. Diese werden wieder importiert und mit der Standard-
toleranz verglichen.
Ergebnis
Alle Zahlen wurden innerhalb der Toleranz korrekt exportiert und importiert. Die ver-
schachtelten XML Elemente werden korrekt zu Elementen der komplexen Matrix und
der dünnbesetzten Matrix importiert.
1
siehe http://en.wikipedia.org/wiki/Magic square
44
Test 1e: Test aller Datentypen
Testfall
xml test(createDS(1))
Beschreibung
Erzeugt eine Struktur, die Objekte aller unterstützten Matlab-Datentypen enthält (siehe
Appendix B, “createDS”). Exportiert und importiert diese Struktur.
Ergebnis
Die Strukturen haben dieselbe Form (Felder, Feldtypen). Die Felder haben dieselben
Dimensionen und Inhalte, innerhalb der gegebenen Standardtoleranz (für Fließkomma-
zahlen).
2. XML Attribute Test

Bei diesen Tests wird eine XML-Datei mit xml fimport(Datei , ’xml’) importiert,
die importierte Struktur mit der Funktion xml test erneut exportiert und importiert
und danach verglichen. Zusätzlich wird die temporäre XML-Datei, die bei diesem Testauf-
ruf entsteht, mit der Originaldatei verglichen. Als Testfall ist hier jeweils der Dateiname
der XML-Datei angegeben (siehe Appendix A).
Test 2a: Namespaces und Tagname

Testfall
projects.xml
Beschreibung
Testet XML-Elemente mit Namespaces und mit Elementnamen, die in Matlab nicht
gültig sind (Attributefelder NAMESPACE und TAGNAME).
Ergebnis
Die importierten Strukturen sind identisch. Die erzeugte XML-Datei ist äquivalent zur
Originaldatei.
45
Test 2b: Realdaten mit Kommentaren
Testfall
slideSample05.xml
Beschreibung
Diese XML-Datei beinhaltet hauptsächlich Textdaten und Kommentare. Es handelt sich
dabei um kein konstruiertes Beispiel, sondern wurde aus dem Unterrichtsmaterial zum
Kurs “Datenmanagement” entnommen. Es wurden kleine Änderungen vorgenommen
(Streichung von CDATA und Processing Instructions).
Ergebnis
Die importierten Strukturen sind identisch. Die erzeugte XML-Datei unterscheidet sich
von der Originaldatei. Kommentare gehen verloren. Unterelemente werden alphabetisch
sortiert ausgegeben.
Test 2c: Elemente mit Unterelementen und Text

Testfall
article1.xml
Beschreibung
Dieses XML-Dokument enthält Elemente, die sowohl weitere Unterelemente, als auch
Textinhalt besitzen. Dieses Dokument wurde ebenfalls aus dem Unterrichtsmaterial zum
Kurs “Datenmanagement” entnommen.
Ergebnis
Die importierten Strukturen sind identisch. Die erzeugte XML-Datei unterscheidet sich
von der Originaldatei. Der Textinhalt bei Elementen mit Unterelementen wird nicht im-
portiert und somit nicht wieder ausgegeben. Unterelemente werden alphabetisch sortiert
ausgegeben.
46
Test 2d: Größeres XML Dokument mit Textblöcken
Testfall
recipes2.xml
Beschreibung
Dieses XML Dokument enthält Elemente mit längeren Textblöcken. Es wurde aus dem
Unterrichtsmaterial zum Kurs “Datenmanagement” entnommen.
Ergebnis
Die importierten Strukturen sind identisch. Ignorierbare Leerzeichen bleiben erhalten,
Zeilenumbrüche gehen verloren. Die erzeugte XML-Datei unterscheidet sich von der Ori-
ginaldatei. Der Textinhalt wird in einer Zeile mit zusätzlichen Leerzeichen ausgegeben.
Unterelemente werden alphabetisch sortiert ausgegeben.
3. Zeittests
Test 3a: Struktur mit großen Feldern
Testfall
xml test(createDS(1), 1e-5, 10)
Beschreibung
Hier wird wiederholt eine Struktur mit großen Feldern exportiert und importiert. Größe
der Struktur in Matlab ist 7,86 MiB2 .
Ergebnis
Alle importierten Strukturen waren identisch mit der Originalstruktur.
Dateigröße (MiB) ø Export (s) ø Import (s)

UTF-8 16,7 8,09 2,24
UTF-16 33,3 8,92 5,18
Latin-1 16,6 7,56 2,27
2
1 MiB (Mebi Byte) ≡ 220 = 1.0242 = 1.048.576 Bytes
47
Test 3b: Struktur mit mehreren großen Feldern
Testfall
xml test(createDS(3), 1e-5, 10)
Beschreibung
Hier werden drei Strukturen mit großen Feldern erzeugt und getestet. Größe der Struktur
in Matlab ist 23,58 MiB.
Ergebnis

UTF-8 50,0 24,30 6,71
UTF-16 100,0 26,56 11,37
Latin-1 50,0 22,50 6,73
Test 3c: 1.000 kleine Objekte

Testfall
xml test(createCell(1000, 10, 10), 1e-5, 10)
Beschreibung
Hier wird ein Cell-Array mit 1.000 Zellen erstellt, die jeweils eine zufällige 10x10 Double-
matrix darstellen. Größe der Struktur in Matlab ist 0,82 MiB.
Ergebnis

UTF-8 1,67 0,81 0,27
UTF-16 3,34 0,92 0,37
Latin-1 1,67 0,79 0,27
48
Test 3d: 100.000 kleine Objekte
Testfall
xml test(createCell(100000, 10, 10))
Beschreibung
Hier wird ein Cell-Array mit 1.000 Zellen erstellt, die jeweils eine zufällige 10x10 Double-
matrix darstellen.
Ergebnis
Out of Memory Exception bei der Erstellung des Cell-Arrays in Matlab.
Zusammenfassung
UTF-8 UTF-16 Latin-1

Export (s) Import (s) Export (s) Import (s) Export (s) Import (s)
Test 1d 8,09 2,24 8,92 5,18 7,56 2,27
Test 2d 24,30 6,71 26,56 11,37 22,50 6,73
Test 3d 0,81 0,27 0,92 0,37 0,79 0,27
Test 4d – – – – – –
4. Speichertests
Bei diesen Tests kann die xml test Funktion nicht verwendet werden, da die Import-
und Exportoperationen direkt aufeinander folgen. Somit ist eine Unterscheidung, wel-
che Operation wieviel Speicher verwendet, nur schwer möglich. Stattdessen wurden die
Operationen getrennt ausgeführt. Der Export schreibt eine XML-Datei, die beim Import
wieder eingelesen wird.
Diese Tests wurden auf zwei Arten durchgeführt. Zuerst wurden Typinformationen
mitexportiert. Der Importprozess weiß somit, wieviel Speicher für die einzelnen Objekte
bereitgestellt werden muss. Bei der zweiten wurden keine Informationen exportiert, und
der Importprozess soll numerische Inhalte zu Double Matrizen konvertieren. Bei dieser
Variante muss dynamisch ermittelt werden, wieviel Speicher benötigt wird. Es kommt
die Wachstumsfunktion der MemoryVector Klasse zum Einsatz (siehe Kap. 3.2).
49
Als Ergebnis wird der Speicherverlauf der jeweiligen Operation angegeben. Es wird
die Speicherbelegung des Matlab-Prozesses zu Beginn der Operation (Start), nach Be-
endigung der Operation (Ende), und der Höchstwert während der Operation (Hoch) an-
gegeben. Zusätzlich wird angegeben, um wieviel der Höchstwert den Speicherverbrauch
am Ende übersteigt. Dies ist die zusätzliche Speicherbelastung durch die Operation.
Angegeben wird auch die Durchführungszeit der Operation.
Normalerweise sollte die Speicherbelastung am Anfang und am Ende bei Exportopera-

tionen dieselbe sein. Sie kann sich aber unterscheiden aufgrund von internen Operationen
von Matlab oder des Betriebssystems. Auch sollte die Speicherauslastung nach Import-
prozessen um die Größe der importierten Daten erhöht sein. Dies kann aus den selben
Gründen wiederum abweichen.
Test 4a: 1.000 kleine Objekte

Testfall
createCell(1000, 10, 10)
Beschreibung
Hierbei wird ein Cell-Array mit 1.000 Zellen erzeugt, wobei jede Zelle eine zufällige 10x10
Doublematrix ist. Größe des Arrays in Matlab ist 0,82 MiB.
Ergebnis
Start (MiB) Ende (MiB) Hoch (MiB) Überschuss (MiB) Zeit (s)
Export 28,5 28,5 28,5 0,0 0,82
Import statisch 28,5 29,5 29,5 0,0 0,26
Import dynamisch 28,4 30,9 30,9 0,0 0,37
Test 4b: 10.000 kleine Objekte

Testfall
createCell(10000, 10, 10)
Beschreibung
Hierbei wird ein Cell-Array mit 10.000 Zellen erzeugt, wobei jede Zelle eine zufällige
10x10 Doublematrix ist. Größe des Arrays in Matlab ist 8,20 MiB.
50
Ergebnis
Export 45,3 45,2 45,8 0,6 8,20
Import statisch 38,9 49,9 49,9 0,0 4,08
Test 4c: Struktur mit großen Feldern

Testfall
createDS(1)
Beschreibung
Es wird mit einer Struktur getestet, die Felder aller unterstützten Datentypen bein-
haltet. Einige Felder sind sehr groß (≥ 100.000 Elemente) und werden die dynamische
Wachstumsfunktion in Anspruch nehmen. Die Größe der Struktur in Matlab ist 7,86
MiB.
Ergebnis
Export 36,9 37,9 85,4 47,5 8,17
Import statisch 37,9 45,8 45,8 0,0 2,27
Test 4d: Struktur mit mehreren großen Feldern

Testfall
createDS(3)
Beschreibung
Es wird mit drei Strukturen getestet, die Felder aller unterstützten Datentypen bein-
haltet. Einige Felder sind sehr groß (≥ 100.000 Elemente) und werden die dynamische
Wachstumsfunktion in Anspruch nehmen. Die Größe der Struktur in Matlab ist 23,58
MiB.
51
Ergebnis
Export 53,7 53,7 101,1 47,4 24,29
Import statisch 53,7 77,4 77,5 0,1 6,71
Es war eindeutig zu sehen, dass die Speicherauslastung während des Exports drei mal
von 53,7 auf 101,1 MiB stieg und wieder auf 53,7 MiB absank.
Test 4e: Matrix mit 3.000.000 Elementen

Testfall
rand(300, 100, 100)
Beschreibung
Hier wird eine zufällige Doublematrix mit 3.000.000 Elementen erzeugt. Die dynamische
Speicherermittlung wird verwendet. Die Größe der Matrix in Matlab ist 22,89 MiB.
Ergebnis
Export 53,0 53,0 159,7 106,7 23,44
Import statisch 53,0 75,9 76,5 0,6 6,50
Test 4f: Matrix mit 10.000.000 Elementen

Testfall
rand(100, 100, 1000)
Beschreibung
Hier wird eine zufällige Doublematrix mit 10.000.000 Elementen erzeugt. Die dynamische
Speicherermittlung wird verwendet. Die Größe der Matrix in Matlab ist 76,29 MiB.
52
Ergebnis
Export 102,3 103,1 703,6 600,5 105,24
Import statisch 103,1 179,5 179,5 0,0 25,61
Zusammenfassung
Dieselben Testfälle wurden ebenfalls mit der Geodise Toolbox durchgeführt. Die von
Geodise importierten XML-Dokumente enthielten alle Typinformationen. In der nach-
folgenden Tabelle können die Ergebnisse beider Toolboxen verglichen werden.
53
Export Export Geodise Import statisch Import dynamisch Import Geodise
Ü (MiB) t (s) Ü (MiB) t (s) Ü (MiB) t (s) Ü (MiB) t (s) Ü (MiB) t (s)
Test 4a 0,0 0,82 18,0 18,16 0,0 0,26 0,0 0,37 13,2 3,87
Test 4b 0,6 8,20 28,5 —1 0,0 4,08 0,0 7,86 149,6 31,33
Test 4c 47,5 8,17 217,3 10,30 0,0 2,27 27,2 2,62 1.285,2 —1
Test 4d 47,4 24,29 652,0 38,70 0,1 6,71 43,3 7,52 1.586,3 —2
54
Test 4e 106,7 23,44 633,1 171,71 0,6 6,50 99,6 7,67 579,9 333,66
Test 4f 600,5 105,24 384,4 —3 0,0 25,61 534,0 26,94 1.303,8 106,764
1
2
3
Nach ∼30 Sekunden abgestürtzt
4
Mit Out of Memory Exception abgebrochen

XML Toolbox

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

XML Toolbox

Hochgeladen von

Copyright:

Verfügbare Formate

Fachhochschule Vorarlberg GmbH.

Dornbirn, im August 2007

Betreuer Dipl.-Inform. Thomas Feilhauer

2 Aufbau der XML Toolbox 4

4.4.2 XML Attribut Stil . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6 Zusammenfassung und Ausblick 33

Appendix A – Inhalt der CD 37

Appendix C – Testfälle und -ergebnisse 43

1.1 Was macht die XML Toolbox?

Um die Möglichkeiten dieser Programmiersprache mit bestehenden Applikationen zu

1.2 Stand der Technik

Matlab bietet weiters eine Möglichkeit, beliebige Datenobjekte zu exportieren und

1.3 Motivation und Anforderungen

• Plattform Schicht, für die Abstraktion der unterliegenden Plattform

• Client Schicht, als eigentliche Implementierungsschicht für die Clientapplikation

Die folgenden Abschnitte erläutern nun die einzelnen Schichten im Detail.

Abbildung 2.1: Übersicht über die XML Toolbox Schichten

2.2 Plattform Schicht

Um den Umgang mit diesen Unterschieden zu vereinfachen, wurde die Plattform

2.3 Unicode Schicht

Ein weiterer wichtiger Bestandteil dieser Schicht sind Stringkonvertierungsfunktio-

2.4 XML Schicht

2.4.2 Schreiben von XML Dokumenten

Abbildung 2.2: Komponenten für das Schreiben von XML Dokumenten

2.4.3 Lesen von XML Dokumenten

Abbildung 2.3: Komponenten für das Lesen von XML Dokumenten

Das Factory-Pattern wird hier verwendet, um einfach die zugrundeliegende XML

2.5 Matlab Schicht

Build Simple Type

Build Simple Type

Abbildung 2.4: Beispiel: Arbeiten mit den MatlabBuilder Stacks

2.6 Client Schicht

Die weiteren Klassen (MatlabExporter und MatlabImporter) dienen als Hilfsklassen,

Hierzu ein Beispiel:

3.2 MemoryVector Klasse

Um dieses Problem zu umgehen wurde die Klasse MemoryVector implementiert. Sie

Bei der Entwicklung wurden mehrere Berechnungsmöglichkeiten für diesen dynami-

Abbildung 3.1: Graph der kumulativen Weibull Verteilungsfunktion (Quelle: [Wik07])

Als Vorlage für den Berechnungsalgorithmus diente die kumulative Verteilungsfunkti-

Die Verteilungsfunktion ist definiert als

Hier ist k der Formfaktor, λ der Skalierungsfaktor.

Die Funktion wurde abgewandelt, um die Bedürfnisse der Wachstumsfaktorfunktion

Abbildung 3.2: Wachstumsfaktor in Abhängigkeit von log10 (Größe)

Abbildung 3.3: Größenzuwachs und Wachstumsfaktor im Vergleich zur aktuellen Größe

Nr. Größe Faktor Zuwachs

Tabelle 3.1: Ausgewählte Datenwerte aus dem Wachstumsverhalten

3.3 Memory Management

3.4 Verwendung der Unicode Schicht

4.1 Client Handler

Das Standardformat ist geeignet für den Datenaustausch zwischen Matlab-Applikationen.

Das XML-Attribut-Format ermöglicht das Importieren von beliebigen XML-Dokumenten.

XML Elementnamen, die in Matlab ungültige Feldnamen darstellen, werden durch

4.2 Aufruf aus Matlab

• xml export: Exportiert den übergebenen Ausdruck in einen String

• xml fexport: Exportiert den übergebenen Ausdruck in eine Datei

• xml import: Importiert einen XML String

• xml fimport: Importiert eine XML Datei

Bei den Exportkommandos können folgende Attributtyp-Parameter angegeben wer-

• type: Schreibt Typinformationen (Standard)

• none: Schreibt keine Typinformationen

• xml: Exportiert mit dem XML-Attribut-Export-Handler

Bei den Importkommandos können folgende Attributtyp Parameter angegeben wer-

• none: Typinformationen werden ignoriert

• xml: Importiert mit dem XML-Attribut-Import-Handler