Menu
▾
▴
[Xpg-xml-commits] CVS: doc Kap4ff.tex,NONE,1.1
|
From: G?nther B. <br...@us...> - 2002-06-05 14:00:18
|
Update of /cvsroot/xpg-xml/doc
In directory usw-pr-cvs1:/tmp/cvs-serv17625
Added Files:
Kap4ff.tex
Log Message:
Chapter 4 ff of report / corrected
--- NEW FILE: Kap4ff.tex ---
\documentclass[oneside,a4paper,10pt]{book}
\usepackage{german}
\usepackage{isolatin1}
\usepackage[dinodraft,german]{dino}
\usepackage{amssymb}
%\usepackage{acronym}
% ---------- change paragraph layout --------------------
\parskip1.2ex % Vertikaler Abstand zwischen Absaetzen
\parindent0cm % Nicht einrücken bei neuem Absatz
% ---------- change name of tables --------------------
\renewcommand{\tablename}{Tabelle}
\global\def\tableCaption{\tablename}
% ------------------- settings for pdf documents ----------------------------
\expandafter\ifx\csname pdfoutput\endcsname\relax
\else
\hypersetup{backref,
% pdfauthor={\ehaselwanter},
pdftitle={Seminarbericht XPG-XDML},
pdfsubject={},
% colorlinks=true,
%% linkcolor=webgreen, %defined below
%% filecolor=webbrown, %defined below
%% citecolor=webgreen, %defined below
% pdfpagemode=None,
a4paper=true,
% bookmarksopen=false
}
%
%Define some eye-pleasing colors for this document
%
% \definecolor{webgreen}{rgb}{0,.5,0}
% \definecolor{webbrown}{rgb}{.6,0,0}
\fi
\setcounter{page}{1}
\begin{document}
\chapter{Anwendungsbeispiele}
\label{sec:Anwendungsbeispiele}
\section{\LaTeX: flexible Handhabung ganzer Dokumentblöcke}
Während der Erstellung größerer Dokumente kann es immer wieder vorkommen,
dass es notwendig, ist Teile eines Dokuments umzustrukturieren und dabei
ganze Blöcke des Dokuments zu verschieben. Dabei kann es passieren, dass aus
einem ursprünglich eigenen Kapitel nunmehr ein Unterkapitel wird, oder
umgekehrt, aus einem anfangs nur als kleines Unterkapitel gedachten Block
nun ein eigenes, großes Kapitel wird. Das bedeutet aber, dass Änderungen in
der Dokumentenhierarchie vorgenommen werden. Nun ist es jedoch in
Textbeschreibungssprachen wie \LaTeX\ der Fall, dass diese Heirarchie eines
Dokuments eine sehr genau vorgegebene Form haben muß - bei \LaTeX\
sind dies der Reihe nach {\em part, chapter, section, subsection,
subsubsection, paragraph, subparagraph}. Dies bedeutet nun aber, wenn
bei solchen Umstrukturierungen aus Unterkapiteln eigene Kapitel werden
(und analog umgekehrt), dass diese Modifikationen der Dokumenthierarchie
händisch nachgebessert werden müssen: aus einem {\em section} wird ein
{\em chapter}, aus dem darin enthaltenen {\em subsection} wird ein
{\em section} und gleich weiter im ganzen verschobenen Block (respektive
umgekehrt wenn aus einem Kapitel ein Unterkapitel wird).
Dieses händische Nachbessern wird obsolet, wenn man in der
Dokumenthierarchie nur ein Element (z.B. {\em section }) kennt, unabhängig
von der jeweiligen Hierarchieebene - man dieses also beliebig ineinander
verschachteln kann. Aus der Tiefe dieser Verschachtelung erhält man dann
die Ebene der Hierarchie für die Übersetzung in ein Zielformat (wie
\LaTeX ) in dem man je Ebene einen unterschiedlichen Bezeichner hat.
Eine solche Dokumentenhierarchie kann nun zum Beispiel ein Aussehen
wie folgt haben:
\begin{verbatim}
<document>
<section>
<title>1. Kapitel</title>
<para> ... </para>
</section>
<section>
<title>2. Kapitel</title>
<para> ... </para>
<section>
<title>1. Abschnitt</title>
<para> ... </para>
</section>
<section>
<title>2. Abschnitt</title>
<para> ... </para>
</section>
</section>
</document>
\end{verbatim}
Der eigentliche Inhalt der einzelnen Abschnitte befindet sich hier in den
\texttt{<para>} Elementen, und wird entsprechend der weiters darin
enthaltenen Elemente ins Zielformat übersetzt. Die \texttt{<title>} Elemente
enthalten die Überschriften der einzelnen (Unter-)Kapitel. Für die
\texttt{<section>} Elemente wird die jeweilige Verschachtelungstiefe
akkumuliert (d.h. bei einen Starttag um eins erhöht und beim Endtag wieder um
eins erniedrigt) und entsprechend dieser dann der entsprechende Bezeichner in
der Zielsprache ausgewählt.
Zu obigem Beispiel kann nun die dazugehörige Dokumentenhierarchie in
\LaTeX\ folgendermaßen aussehen:
\begin{verbatim}
\begin{document}
\section{1. Kapitel}
...
\section{2. Kapitel}
...
\subsection{1. Abschnitt}
...
\subsection{2. Abschnitt}
...
\end{document}
\end{verbatim}
\section{Rechnen}
Häufig kommt es vor, dass man eine ganze Menge von Daten als Input hat,
sich jedoch nicht für diese gesamte Datenflut interessiert, sondern nur
ein paar davon abgeleitete Daten benötigt,womit sich dann meist besser die
gewünschten Aussagen belegen lassen. Das heißt, wenn als Input zum
Beispiel eine ganze Tabelle mit Meßwerten zu Verfügung steht, ist es möglich
daraus zusätzlich repräsentative Werte wie Maxima/Minima, Mittelwert, die
Summe oder sonstige beliebige generierbare Daten zu ermitteln und in das
Enddokument einfließen zu lassen. Das bedeutet aber gleichzeitig auch, dass
bei einem etwaigen Update der Inputdaten mit einem neuerlichen Übersetzen
des Dokuments diese generierten Daten im Output ebenfalls automatisch
upgedatet werden.
Implementiert ist dies mit dem Framework in folgender Weise, dass aufgrund
des Designs sämtliche Inputdaten der einzelnen \ac{ac:Xml}-Elemente im zur
Datenspeicherung vorgesehenen \texttt{DataObject} (siehe
\ref{sec:VerwaltungVonInputdaten},
S. \pageref{sec:VerwaltungVonInputdaten}) verwaltet werden können. Es
können somit also auch ganze Tabellen oder Listen von Inputdaten dort
gesammelt abgelegt werden und dann daraus die benötigten
Daten - wobei dies beginnend von Extremwerten, Mittelwerten oder Summen bis
hin zu ganzen statistischen Berechnungen oder Verteilungen oder beliebige
andere komplizierte Berechnungen sein können - akkumuliert und entsprechend
in den Output eingefügt werden.
Als einfaches Beispiel für diese Funktionalität wurde eine Liste
implementiert, aus deren Daten dann wahlweise der Mittelwert oder die Summe
berechnet werden und abschließend jeweils der Liste angefügt werden. Das
heißt, man hat wahlweise einen der folgenden Inputs:
\begin{tabular}{p{1cm} l|p{.2cm} l}
\\
& Beispiel A: & & Beispiel B: \\ \cline{2-4}
& & & \\
& \texttt{<para>} & & \texttt{<para>} \\
& \texttt{ Liste mit Summe:} & & \texttt{ Liste mit Durchschnitt:} \\
& \texttt{</para>} & & \texttt{</para>} \\
& \texttt{<list eval=\"{}sum\"{}>} { } &
& \texttt{<list eval=\"{}avg\"{}>} \\
& \texttt{ <item>3.7</item>} & & \texttt{ <item>3.7</item>} \\
& \texttt{ <item>2.8</item>} & & \texttt{ <item>2.8</item>} \\
& \texttt{ <item>13.2</item>} & & \texttt{ <item>13.2</item>} \\
& \texttt{</list>} & & \texttt{</list>} \\
\\
\end{tabular}
Und daraus wird dann alternativ der folgende Output generiert:
\begin{tabular}{p{1.3cm} c|p{.2cm} c}
\\
&
Liste mit Summe: { } & &
Liste mit Durchschnitt\\
& & & \\
& 3.7 & & 3.7 \\
& 2.8 & & 2.8 \\
& 13.2 & & 13.2 \\
& & & \\
& {\bf $\sum $ 19.7} & & {\bf $\varnothing $ 6.57}
\end{tabular}
\section{Lebenslauf - 2 verschiedene Zielformate}
Ziel dieses auf den ersten Blick relativ einfachen Anwendungsbeispiels ist es,
einen Lebenslauf zu erstellen und zu übersetzen. Dazu wurde auch ein eigenes
Schema entworfen, dass das Eingabeformat desselben beschreibt. Es besteht aus
einem ersten Teil, welcher die gesamten persönlichen Daten wie Name,
Geburtsdaten, Adresse, Telefon und dergleichen enthält und anschließend einer
Reihe von Listen zu den einzelnen Themen, wie zum Beispiel Schulbildung,
beruflicher Werdegang, weitere Qualifikationen und ähnlichem mehr. Außerdem
sind noch als Attribute eine Bezeichnung des Lebenslaufs und eine Sprachauswahl
vorgesehen.
Dieser Aufbau für das Eingabeformat des Lebenslaufs wurde dadurch gewonnen,
da als erstes Zielformat {\LaTeX } in Zusammenspiel mit einem
speziellen \ac{ac:Cv} Style gewählt wurde. Die Übersetzung des Lebenslaufes nach {\LaTeX }
wurde auch speziell auf die Verwendung dieses Styles abgestimmt.
Der Lebenslauf soll nun aber auch noch in andere Zielformate
(z.B. \ac{ac:Html}) übersetzt werden können. Dazu kann der Großteil der
Transitionen für die Übersetzung nach \LaTeX\ wiederverwendet werden und nur
jene wenige, die effektiv den Output formatieren,
entsprechend adaptiert werden. Es können also, wenn einmal die
Übersetzung in ein bestimmtes Format vorhanden ist, mit relativ geringem
Aufwand Übersetzungen in andere Formate hinzugefügt werden.
\section{Diagramme}
In Geschäftsberichten, Jahresberichten, Marktanalysen, Erhebungen und noch
vielen anderen Dokumenten ähnlicher Art ist es erforderlich, Diagramme
verschiedenster Art (wie z.B. Kurvendiagramme, Tortendiagramme,
Blockdiagramme, ...) ins gewünschte Enddokument einzufügen. Die Ausgangsbasis
Stellen hier eine bestimmte Menge an Daten dar, aus welchen dann ein Diagramm
beliebiger Art erstellt werden soll, um dieses anschließend in das Dokument
einzubinden.
Bei diesem Framework gibt es nun dahingehend eine wesentliche Erleichterung,
dass es nur notwendig ist, in das Sourcedokument die gesammelten Daten für das
Diagramm einzufügen, die gewünschte Art des Diagramms anzugeben und die dafür
außer den Daten noch notwendigen Angaben zu machen. Beim Übesetzen in das
gewünschte Zielformat wird dann automatisch das erforderliche Diagramm erstellt
und in das Enddokument eingebunden. Diese komfortable Vorgehensweise erhielt
man in diesem Beispiel durch das Einbinden des \texttt{Chart2D}-Packages,
\cite{chart2d} mit welchem auf einfache Weise aus einer Reihe von Daten
verschiedene Arten von Diagrammen erstellt werden können. Solche vom
\texttt{Chart2D}-Package erstellten Graphiken werden dann im
\ac{ac:Png}-Format in Files gespeichert und diese können dann recht
komfortabel in den Output eingebunden werden.
Der Dateninput kann beispielsweise so aussehen:
\begin{verbatim}
<chart>
<title>Quartalsumsätze 2001</title>
<list chart="pie">
<title>Quartalsumsätze</title>
<item caption="1. Quartal">127</item>
<item caption="2. Quartal">158</item>
<item caption="3. Quartal">113</item>
<item caption="4. Quartal">147</item>
</list>
</chart>
\end{verbatim}
Und dementsprechend wird dann eine Graphik wie in Abbildung \ref{fig:PieChart}
in das Enddokument eingebunden.
\image[0.9]{images/quartalsumsaetze}{Beispiel: generiertes Tortendiagramm}{}{fig:PieChart}
\chapter{Abschließende Betrachtungen}
Es sollen nun noch einmal die Möglichkeiten und Vorteile des implementierten
Frameworks zusammengefasst und aufgezeigt werden, welche
Erweiterungsmöglichkeiten es bietet und an welchen Punkte dazu angesetzt werden
kann.
\section{Zusammenfassung und Diskussion}
Die vorhandenen Technologien zur Verarbeitung von \ac{ac:Xml}-Dokumenten,
vorallem zur Erstellung neuer (druckbarer) Dokumente, bieten meist nicht den
Funktionsumfang der in der heutigen Zeit zur professionellen Verarbeitung
benötigt wird.
Es wurde versucht, ein Framework zu designen und zu implementieren, welches zur
allgemeinen Verarbeitung von XML-Dokumenten verwendet werden kann und leicht
erweiterbar ist.
Was sind nun im Einzelnen die Vorteile des implementierten Frameworks?
\begin{itemize}
\item {\em Die Verwendung von \ac{ac:Xml} als Format für die Inputdaten} -
Damit wird sichergestellt, dass in den Inputdaten ausschließlich Information
und keine Formatierung oder dergleichen enthalten ist. Trotzdem ist dies
eine für Menschen lesbare Repräsentation von Daten. Zudem wird mit der
geforderten Verwendung von XML-Schematas auch die Validierung der Inputdaten
sichergestellt.
\item {\em Strikte Trennung von Inhalt, Layout und Logik} -
Durch das Design des Framework werden diese drei Schichten strikt voneinander
getrennt. Dies ist einer der Hauptvorteile gegenüber Servlets, \ac{ac:Jsp}
und ähnlichem.
\item {\em Die Möglichkeit das selbe Dokument in verschiedene Formate zu
trans\-for\-mieren} -
Der Input ist vollkommen unabhängig davon, in welches Format man ihn
übersetzen will. Ist jedoch einmal die Transformation in ein bestimmtes
Zielformat vorhanden, so kann mit relativ geringem Aufwand auf
weitere Formate erweitert werden. Dies funktioniert deshalb, weil die gesamte
Ablaufsteuerung die selbe bleiben kann und nur jene Transitionen ausgetauscht
werden müssen, welche effektiv Output in der Zielsprache erzeugen.
\item {\em Beliebige Erweiterungsmöglichkeit mittels wiederverwendbarer Packages} -
Das vorhandene Framework kann sehr einfach um eine weitere Dokumentklasse oder
um ein weiteres Zielformat erweitert werden, indem man ein weiteres Package mit
den dafür notwendigen Transitionen entwickelt, welches danach immer wieder
verwendet werden kann.
\item {\em Ermittlung neuer Daten aus den Inputdaten} -
Es können nicht nur die Daten aus den Inputdateien einfach in den Output
übernommen werden, sondern es können daraus auch neue Daten generiert werden,
welche dann in den Output einfließen. Hierbei sind unter anderem mathematische Berechnungen,
umfangreiche Statistiken und dergleichen mehr möglich.
\item {\em Verwenden und Einbinden vorhandener Packages} -
Es können sämtliche für beliebige Zwecke vorhandenen Java-Packages in das
Framework (respektive in den Transitionen eines Erweiterungspackages zum
Framework) eingebunden werden. Damit werden Funktionalitäten wie zum Beispiel
das Erstellen von Diagrammen aus Rohdaten mit Hilfe des Chart2D-Packages und
beliebig anderes mehr möglich.
\item {\em Keine Beschränkung auf reine Dokumente als Output} -
Das Framework kann nicht nur die Transformation von \ac{ac:Xml}-Doku\-menten in
andere Dokumentenformate bewerkstelligen, sondern es ist noch weit mehr an
Funktionalität damit erzielbar. Ein konkretes Beispiel hierfür ist bereits im
Framework selbst inkludiert: das Aufsetzten einer neuen Statemachine.
\end{itemize}
\section{Ausblick}
Es gibt nun allerdings noch einige Punkte, an denen man ansetzen kann, um das
vorhandene Framework zu erweitern und zu verbessern.
\begin{itemize}
\item {\em Entwicklung eines graphischen Interfaces} -
Die derzeitige \texttt{main} Methode ersetzend, welche nur eine eingabe auf
der Kommandozeile zuläßt, kann ein \ac{ac:Gui} als Erweiterung
zum bestehenden Framework implementiert werden, um das Arbeiten mit demselben
komfortabler zu gestalten. Es ist zu diesem Zwecke allerdings nicht mehr
erforderlich, den vorhandenen Systemkern zu verändern.
\item {\em Automatisches Generieren der Konfigurationsdaten einer Statemachine
aus dem Schema der zu verarbeitenden Dokumentklasse} -
Derzeit müssen sowohl das Schema einer zu verarbeitenden Dokumentklasse als
auch das dazugehörige Konfigurationsfile zum Aufbauen der dafür notwendigen
Statemachine separat und von Hand geschrieben werden. Eine Technik wie aus dem
Schema automatisch die Konfiguration der Statemachine ermittelt werden kann
wurde noch nicht entwickelt.
\item {\em Anbindung von Datenbanken an Dokumente} -
Es sollte eine Möglichkeit geschaffen werden, dass beim Übersetzen
spezieller Sourcedokumente auch die Verbindung zu Datenbanken geschaffen wird,
aus welchen dann Daten für das gewünschte Enddokument extrahiert werden
können.
\item {\em Erstellen und Verwalten von Bibliographien und Literaturverzeichnissen} -
Zu großen wissenschaftlichen Arbeiten ist es üblich, Bibliographien und
Literaturverzeichnisse anzugeben. In \LaTeX\ existiert hierzu ein recht
komfortables Packages: {\em BibTeX}. Eine ähnliche Funktionalität könnte dem
Framework hinzugefügt werden. Aus einer separaten Quelle sollen Daten für
Literaturverzeichnis und Bibliographie zum Sourcedokument gewonnen werden
und ins Enddokument eingebunden werden können. Beim Übersetzen nach \LaTeX\ könnte
man dann wieder auf das {\em BibTeX }-Package zurückgreifen.
\item {\em Templates für Web-Formulare} -
Ein gängiges Problem in der Webseitengestaltung bzw. Programmierung
ist das Verarbeiten von Daten, die vom User eingegeben werden.
Für dieses Problem sollte ein genereller Ansatz geschaffen werden, da
die Abläufe immer dieselben sind und sich nur die Repräsentation und die
verwendeten Daten ändern. Das Framework sollte nun dahingehend verwendbar
sein, dass es für die jeweiligen Projekte bzw. Webseiten nur noch eine
Datenbeschreibung in einer geeigneten Form benötigt. Der Grafiker
kann dazu parallel Templates entwerfen, in die per Platzhalter die
Datenfelder eingefügt werden können. \\
Eine geeignete Lösung wäre dafür, die Datenfelder in einem geeigneten
Format (XML bzw. XML Schema bieten sich an) zu beschreiben und die Erzeugung
der eigentlichen Web Formulare passiert automatisiert. Es kann dies eine
Umwandlung von XML in PHP sein; Es wäre jedoch leicht möglich, auch
z. B. JSP oder ASP damit zu erzeugen.
\item {\em Erweiterung des Frameworks zu wiederverwendbarer Middleware} -
Es kann das vorhandene Framework soweit erweitert werden, dass es im
Zusammenhang mit verschiedenen Frontends und Backends Verwendung findet. Das
bedeutet, dass man es zu Middleware erweitert.
\item {\em Einsatz des Frameworks als Servlet} -
Es wäre möglich, das vorhandene Framework dahingehend zu erweitern, dass es als
Web-Applikation auf einem Servlet-Server (z.B. Apache) läuft und somit die
\ac{ac:Xml} Dokumente im Internet zu Verfügung stellt. Zusätzlich dazu, dass
diese Dokumente immer aktuell sind, da sie ja erst beim entsprechenden Request
generiert werden, wäre auch eine Auswahlmöglichkeit des gewünschten
Dokumentformats (z.B. \ac{ac:Html} oder \ac{ac:Pdf}) möglich.
\end{itemize}
Es besitzt das vorhandene System nun bereits eine vielseitige
Funktionalität, kann aber auch noch in viele Richtungen hin erweitert und
verbessert werden. Das Design dieses Framework bietet also eine Unmenge an
Möglichkeiten.
\appendix
\addcontentsline{toc}{chapter}{\bibname}
\setbookmark[section]{\bibname}
% \chapter{Literaturverzeichnis}
\bibliographystyle{abbrv}
\bibliography{Seminarbericht,bibliography_entries,script,rfc_wo_cite,std,fyi}
\chapter{Schema der Statemachine}
\label{sec:SchemaDerStatemaschine}
\footnotesize
\begin{verbatim}
<?xml version="1.0" standalone="no"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<!-- attention: all names must be adapted to the
following nameing convention
type names : AllWordsCapitalizedWithoutUnderscores
element names : alllowercasewithoutunderscores
-->
<xsd:element name="statemachine">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="path" type="xsd:string"
minOccurs="1" maxOccurs="unbounded"/>
<xsd:element name="states" type="States"
minOccurs="1" maxOccurs="1"/>
<xsd:element name="transitions" type="Transitions"
minOccurs="1" maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="States">
<xsd:sequence>
<xsd:element name="startstate" type="xsd:string"
minOccurs="1" maxOccurs="1"/>
<xsd:element name="state" type="xsd:string"
minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="Transitions">
<xsd:sequence>
<xsd:element name="transition" type="Transition"
minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="Transition">
<xsd:sequence>
<xsd:element name="beginstate" type="xsd:string"
minOccurs="1" maxOccurs="1"/>
<xsd:element name="nextstate" type="xsd:string"
minOccurs="1" maxOccurs="1"/>
<xsd:element name="element" minOccurs="0" maxOccurs="1">
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="type" type="ElementAttributes"
use="required"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="classname" type="xsd:string"
minOccurs="1" maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="ElementAttributes">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="start"/>
<xsd:enumeration value="end"/>
<xsd:enumeration value="enddoc"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
\end{verbatim}
\normalsize
\end{document}
|
