% Diplomarbeit von Andreas Boesch
%
% Universitaet Hamburg
% Fachbereich Informatik
% Arbeitsbereich DBIS
%
% Kapitel: Versionierung im WWW

\chapter{Versionierung}
\label{Kap. versionierung}

Versionskontrolle erlaubt die Koexistenz verschiedener Instanzen eines Dokumentes und erm"oglicht deren individuelle und vergleichende Visualisierung, so wie ihre automatische oder unterst"utzte Zusammenf"uhrung und Differenzierung \cite{VD95}. Systeme zur Versionskontrolle werden oft in verteilten DBMS, der Softwareentwicklung oder bei computergest"utzter kooperativer Arbeit (CSCW) eingesetzt. W"ahrend das WWW heute eher ein passives Publikationmedium ist, k"onnen Versionierungssysteme es zu einem aktiven Kooperationsmedium machen, indem Nutzer nicht nur lesenden sondern auch schreibenden Zugriff auf einzelne Dokumente haben.

Ein {\em Versionierungssystem} ist ein Softwaremodul, das Identit"atsbeziehungen zwischen verschiedenen Instanzen eines Datenobjektes aufrechterh"alt. Jede Instanz ist eine {\em Version} des Objektes und steht mit den anderen Versionen in einer m"oglicherweise komplexen Struktur aus "alteren, neueren oder parallel entstandenen Versionen in Beziehung. Dokumente setzen sich aus einer linearen Sequenz, einer verzweigten Baumstruktur oder einem gerichteten azyklischen Graph von Versionen zusammen. Der Inhalt einer spezifischen Version wird durch die Operationen bestimmt, die auf den Knoten ausgef"uhrt werden, die diese Version mit ihrer Initialversion - der sogenannten Wurzel -  verbinden.

Ein Versionierungssystem erm"oglicht das parallele asynchrone Editieren von Objekten einerseits durch {\em zeitbasierte Versionierung}, die die Unterschiede zwischen mehreren aufeinanderfolgenden Revisionen eines Dokumentes abbildet, und andereseits durch {\em Autor-basierte Versionierung}, die Modifikationen verschiedener Varianten der selben Version erlaubt. Durch das automatische Zusammenf"uhren (engl. {\em merging}) mehrerer parallel entstandener Versionen von Objekten kann ein einziger g"ultiger Zustand eines Dokumentes erreicht werden.

Im Zusammenhang mit Hypertextdokumenten, wie man sie im WWW findet, wird Versionierung durch Probleme wie z.B. der Integrit"at von Hyperlinks oder der Konsistenz einer Menge von Dokumenten sehr komplex. Aus diesem Grund werden hier die Versionierungsanforderungen von den Konfigurationsanforderungen getrennt.  Abschnitt~\ref{verWWW} behandelt die Handhabung mehrerer Versionen einer einzelnen Quelle, w"ahrend in Abschnitt~\ref{confWWW} die Probleme des Konfigurationsmanagement mehrerer Quellen betrachtet werden.
 


\section{Versionierung im WWW}
\label{verWWW}
Versionierung im Kontext des WWW hat folgende Ziele \cite{DV96}:

\begin {itemize}
\item Infrastruktur f"ur effizientes und kontrolliertes Management gro"ser Web-Sites,
\item paralleles asynchrones Editieren einzelner Resourcen,
\item Grundger"ust f"ur die Zugangskontrolle zu Resourcen,
\item Visualisierung von Historien bzw. alternativen Versionen von Resourcen,
\item stabile Referenzen zur Unterst"utzung extern gespeicherter Hyperlinks,
\item explizite semantische Repr"asentation einzelner Resourcen mit multiplen Zust"anden.
\end {itemize}


\subsection {Globale Anforderungen}
\label{glVerAnf}
Im folgenden werden die Anforderungen an Versionierungsunterst"utzung im WWW dargestellt, die n"otig sind um o.g. Ziele zu erreichen.

\begin{description}
\item[Stabilt"at von Versionen:] Die Stabilt"at einzelner Versionen einer Dokumenten\-his\-to\-rie wird erreicht, indem diese unver"anderbar gemacht werden. Werden dann weitere "Anderungen an einer "`eingefrorenen"' Version vorgenommen, erzeugen diese neue Versionen und "andern nicht das Original.

\item[Unabh"angigkeit von unterschiedlichen Versionierungsverfahren:] Versionierungs\-ver\-fahren unterscheiden sich bez"uglich der Strategie zur Historienverwaltung, den Sperranforderungen eines Servers, etc.

\item[Abkopplung des Resourcenretrieval von der Nebenl"aufigkeitskontrolle:] Das Protokoll mu"s die Unterscheidung von Reservierung und Freigabe von versionierten Resourcen von deren Zugangsmethoden trennen. Es soll z.B. f"ur den Bearbeiter eines Dokumentes m"oglich sein, andere zu dem gerade bearbeiteten Dokument in Beziehung stehende Dokumente zu sperren, ohne sie vom Server anfordern zu m"ussen. So kann die Konsistenz dieser Teilmenge von Dokumenten gew"ahrleistet werden.

\item[Kompatiblit"at der Datenformate:] Das Versionierungssystem sollte mir existierenden Resourcen und URL's arbeiten k"onnen. Spezielle Versionierungsinformation sollten nicht obligatorisch in das Format von Dokumenten aufgenommen werden.

\item[Unterst"utzung von Altsystemen:] Resourcen mit Versionierungsinformation sollten auch f"ur nicht-versionierungsf"ahige Clients zug"anglich sein.
\end{description}

\subsection{Funktionale Anforderungen}
\label{fktVerAnf}

Nach \cite{DV96} sollte ein WWW Versionierungssystem unter anderem folgende Funktionalit"at bereitstellen:

\begin{description}
\item[Zugang zu spezifischen Versionen via URL:] Jede Version einer Resource auf einem Server sollte "uber eine URL adressierbar sein. Dies wird f"ur versionsspezifische Hyperlinks und Clients, die keine Versionierung unterst"utzen ben"otigt.
\item[Eine URL, die eine versionierte Resource selbst bezeichnet und nicht deren spezifische Versionen:] Diese URL wird von Operationen benutzt, die alle Versionen einer Resource betreffen (z.B. "Anderung von Attributen oder Sperrvermerken, oder Neuvergabe von URL's).
\item[Direkter Zugang zu einer auf dem Server definierten "`default"'-Version:] Dies ist der einfachste Weg Kompatibilit"at  zu Clients zu wahren, die keine Versionierung unterst"utzen.
\item[Zugang zu "`verwandten"' Versionen:] "`Verwandte"' Versionen sind z.B. die erste Version eines Dokumentes (Wurzelversion), die vorausgegangene und die nachfolgende Version eines Dokumentes, und die "`default"'-Version. 
\item[Eine M"oglichkeit auf die vollst"andige Versionstopologie einer Resource zuzugreifen.]
\item[Eine M"oglichkeit exklusiven Zugang zu einer Version einer Resource zu erlangen (Sperrung).]
\item[Eine M"oglichkeit den exklusiven Zugang zu einer Resource wieder aufzuheben (Aufhebung der Sperrung).]
\item[Eine M"oglichkeit f"ur einen Client seine Absicht eine Resource zu "andern zu erkl"aren (Reservierung).]
\item[Eine M"oglichkeit die Beendigung der Absicht eine Resource zu "andern anzuzeigen (Freigabe).] 
\item[Eine M"oglichkeit eine neue Version einer Resource zum Server zu "ubertragen.]
\end{description}

Wichtig ist es hier zu bemerken, da"s der Versionszugang von der Nebenl"aufigkeitskontrolle (Reservierung, Freigabe) und dem Update getrennt ist.
In traditionellen Versionskontrollsystemen besteht ein "checkout" aus einer Reservierungsoperation (RESERVE) gefolgt von einer Leseoperation (GET). Ein "checkin" setzt sich aus einer Schreiboperation (PUT) und einer Freigabeoperation (RELEASE) zusammen. Unabh"angigkeit von unterschiedlichen Versionierungsverfahren wird durch die Trennung von Nebenl"aufigkeitskontrolle (Sperrung und Aufhebung der Sperrung von Resourcen), "Anderung von Resourcen und Datentransferoperationen erreicht.


\section{Konfigurationsmanagement im WWW}
\label{confWWW}
Versionierung in Hypermediasystemen erfordert nicht nur die Verwaltung von Revisionen und Varianten einzelner Objekte beliebigen Typs, sondern auch das versionierte {\em Konfigurationsmanagement} von Strukturen und Beziehungen, die zwischen diesen bestehen \cite{HLS91}. Eine Konfiguration umfa"st eine Menge von Objekten innerhalb eines Systems und ihre Beziehungen untereinander. So ist z.B. eine Menge von Klassen, die ein Softwaresystem bilden, eine Konfiguration. Im WWW kann man z.B. die Struktur einer Software-Dokumentation, die sich aus HTML-Dokumenten und Bildern zusammensetzt, als Konfiguration auffassen. Solche Konfigurationen k"onnen im WWW auch andere Objekttypen enthalten, z.B. Audio- oder Video-Dateien, Java-Klassen, CGI-Skripte, etc. 

\subsection{Versionierung von Ankern}
\label{verAnker}
{\em Anker} sind die Endpunkte von Hyperlinks. Anker k"onnen einerseits einen ganzen Knoten in einem Netzwerk bezeichnen, wie z.B. eine HTML-Seite oder ein Bild. Zum anderen k"onnen Anker eine bestimmte Stelle in einem Knoten bezeichnen ({\em interner Anker}). In versionierten Hypermedia-Systemen mu"s es m"oglich sein, beide Arten von Ankern eindeutig mit der Angabe einer bestimmten Version zu spezifizieren. Auf der Ebene der nicht internen Anker kann dies mit Hilfe von Attributen geschehen, z.B. k"onnte ein Anker, der stets auf die aktuelle Version eines Objektes zeigen soll, ein Attribut {\tt version=head} haben, w"ahrend eine "altere Version mit der Angabe eines Datums oder einer Versionnummer zu referenzieren w"are.

Die Versionierung von internen Ankern birgt eine Reihe von Problemen. Referenzen k"onnen relativ sein oder auf ein spezifisches Objekt innerhalb eines Knotens zeigen. Ein interner Anker, der auf ein spezifisches Objekt zeigt, ger"at in einen undefinierten Zustand, wenn das Objekt aus dem Knoten gel"oscht wurde. Innerhalb von Textknoten kann diese Situation verhindert werden, indem interne Anker als Zeichenverschiebung implementiert werden, die in Relation zum Startpunkt des Knotens stehen. Allerdings kann die Semantik eines solchen internen Ankers verloren gehen, wenn der Text der urspr"unglichen Referenz editiert oder an eine andere Stelle verschoben wurde. 

\subsection{Versionierung von Hyperlinks}
\label{verHyperlinks}
Sobald Strukturen versioniert werden, entstehen eine gro"se Anzahl von Hyperlinks, die jeweils in mehreren Versionen vorliegen. F"ur deren Versionierung gibt es zwei einfache Ans"ate. Zum einen k"onnte automatisch eine Standardversion eines Links ausgew"ahlt werden, zum anderen k"onnte der Benutzer aufgefordert werden, die Version eines Links anzugeben. Da jedoch beide Ans"atze entweder aufgrund mangelnder Flexibilit"at oder der "Uberforderung des Benutzers nicht praktikabel sind, ist es n"otig Links in Kontexten zu gruppieren. Ein {\em Kontext} ist eine Menge von spezifischen Versionen von Links, die als eine Einheit betrachtet, benannt und referenziert werden k"onnen. Die Versionierung kann dabei auf der Ebene der individuellen Links erfolgen oder auf der Stufe der Kontexte oder einer Kombination aus beiden.

Erfolgt die Versionierung auf der Ebene der individuellen Links, wird die Historie jedes individuellen Links erhalten, so da"s der Zugang zu "alteren Versionen eines Links m"oglich ist. In Abbildung ~\ref{verlink1} sind individuelle Links aus der Gesamtmenge der Links zu einem Kontext mit dem Namen A gruppiert. Der Kontext A enth"alt eine spezifische Version jedes Links aus der Link Datenbank. 

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=7cm
\epsffile{/users/dbis1/stud/boesch/Diplomarbeit/Latex/Bilder/versionierung/verlink1.epsf}
\end{center}
\caption{Versionierung von Strukturen auf Link-Ebene 1}
\label{verlink1}
\end{figure}

Abbildung~\ref{verlink2} zeigt den Kontext A nach einer Editiersitzung. Es wurde eine neue Version des Links 1 erzeugt, die die "altere Version im Kontext A ersetzt. Der Link 4 wurde nicht ver"andert, aber der Kontext A enth"alt jetzt die Version 1.


\begin{figure}[h]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=7cm
\epsffile{/users/dbis1/stud/boesch/Diplomarbeit/Latex/Bilder/versionierung/verlink2.epsf}
\end{center}
\caption{Versionierung von Strukturen auf Link-Ebene 2}
\label{verlink2}
\end{figure}

Strukturen k"onnen auch auf der Ebene der Kontexte versioniert werden. Dies erm"oglicht den Zugang zu "alteren Versionen von Mengen von Links. In Abbildung~\ref{verKontext1} "uberlagert ein Kontext mit dem Namen XY, bestehend aus drei Hyperlinks, einen Hypertextknoten. 

\begin{figure}[h]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=7cm
\epsffile{/users/dbis1/stud/boesch/Diplomarbeit/Latex/Bilder/versionierung/verKontext1.epsf}
\end{center}
\caption{Versionierung von Strukturen auf Kontext-Ebene 1}
\label{verKontext1}
\end{figure}

In Abbildung~\ref{verKontext2} wurde ein neuer Hyperlink zum Knoten 20 in den Kontext XY eingef"ugt und das Ziel eines bereits bestehenden Links ge"andert. Diese "Anderungen f"uhrten zu der Erzeugung einer neuen Version des Kontextes XY.


\begin{figure}[h]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=7cm
\epsffile{/users/dbis1/stud/boesch/Diplomarbeit/Latex/Bilder/versionierung/verKontext2.epsf}
\end{center}
\caption{Versionierung von Strukturen auf Kontext-Ebene 2}
\label{verKontext2}
\end{figure}

Bei der Versionierung auf der Link-Ebene ist es nicht m"oglich auf "altere Versionen des Kontextes zuzugreifen. Bei der Versionierung auf Kontext-Ebene ist es nicht m"oglich auf andere als die aktuelle Link-Version zuzugreifen. Volle Versionierungsunterst"utzung f"ur Strukturen erh"alt man aus der Kombination beider Methoden ({\VAB}~\ref{verLinkUndKontext}). 

\begin{figure}[h]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=7cm
\epsffile{/users/dbis1/stud/boesch/Diplomarbeit/Latex/Bilder/versionierung/verLinkUndKontext.epsf}
\end{center}
\caption{Versionierung von Strukturen auf Link- und Kontext-Ebene}
\label{verLinkUndKontext}
\end{figure}


 










%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{L"osungen}
\label{verLoesungen}

Unter Versionierung versteht man die F"ahigkeit zur Erzeugung, Administration und Pflege verschiedener Versionen von individuellen Dateneintr"agen oder Objekten "uber einen l"angeren Zeitraum \cite{C*93}. 

Um die Problematik der Versionierung im {\www} zu illustrieren wird in Abschnitt ~\ref{szenarioVersion} ein Szenario entworfen und im folgenden verschiedene Ans"atze zur L"osung vorgestellt.

\subsection{Szenario}
\label{szenarioVersion}
Als Beispiel f"ur mehrere Probleme von Versionsverwaltung soll hier die Preisliste eines virtuellen Computerversandhauses dienen. Das Versandhaus bietet einzelne Komponenten eines Systems zu unterschiedlichen Konditionen und Preisen f"ur private und gewerbliche Kunden. Desweiteren sollen die Preislisten in mehreren Sprachen erscheinen und die M"oglichkeit zur direkten Bestellung bieten. Au"serdem sollen mehrer Mitarbeiter gleichzeitigen "andernden Zugriff auf die vorhandenen Dokumente haben. Da sich in der Computerbranche die Preise f"ur Komponenten sehr oft "andern, m"ussen einmal in der Woche neue Listen erstellt werden. Au"serdem werden von Zeit zu Zeit neue Produkte hinzugef"ugt und alte aus dem Angebot genommen. Die HTML-Dokumente sollen nur tats"achlich auf dem jeweiligen Client-Browser darstellbare Elemente enthalten, das bedeutet, da"s z.B. bei einem nicht Java-Script f"ahigen Client-Browser keine Scripte "ubertragen werden sollen, bzw. bei einem nicht {\em frame}-f"ahigen keine {\em frames}.

\subsection{HTML-L"osung}
\label{szhtml}
Bei einer puren HTML-l"osung f"ur die oben genannten Anforderungen w"urden sich bei zwei verschiedenen Sprachen vier verschiedene HTML-Seiten ergeben, die w"ochentlich aktualisiert werden m"u"sten. Dies erfordert einen hohen Zeitaufwand und produziert damit regelmaessig Kosten. 


\subsection{Versioned Text Markup Language}
\label{vtml}
VTML (Versioned Text Markup Language) ist eine Dokumentenbeschreibungssprache f"ur die Speicherung von Versionsinformationen \cite{VD95}. Das Hauptziel von VTML ist es, die asynchrone Zusammenarbeit mehrerer Autoren bei der Erzeugung und Editierung von Textdokumenten zu erm"oglichen. Hierbei m"ussen folgende Anforderungen erf"ullt werden:

\begin{description}
\item [Konsistenz:]
Wird ein Dokument editiert oder "uberarbeitet, ist es m"oglich, da"s ein extern gespeicherter Verweis auf das editierte Dokument ung"ultig wird, da sich evtl. der referenzierte Inhalt signifikant ge"andert hat, nicht mehr besteht oder an einer anderen Stelle gespeichert worden ist.
\item[Verantwortlichkeit:]
Die Frage der personellen Verantwortlichkeit f"ur ein Dokument ist insbesondere dort wichtig, wo mehrere Autoren dieses editieren. Ein Leser mu"s wissen, wer der Verfasser eines Dokumentes ist, ob es ge"andert wurde und wenn ja, von wem.
\end{description}

Die Konsistenz von Verweisen wird in einem versionierten Kontext dadurch gesichert, da"s "Anderungen an einem Dokument dieses nicht ersetzen, sondern in einer neuen Version des Dokumentes gespeichert werden. Dieser Mechanismus sorgt daf"ur, da"s Referenzen auf alte Versionen g"ultig bleiben. VTML stellt M"oglichkeiten zur Verf"ugung, die personelle Verantwortlichkeit f"ur jede "Anderung an einem Dokument  zu speichern und nachzuvollziehen. Die Erzeugung und Editierung von Dokumenten erfolgt

\begin{itemize}
\item lokal (auf dem Rechner des Benutzers), 
\item asynchron (ohne Benachrichtigung anderer von den Aktionen des Benutzers) und
\item parallel (mehrere Benutzer k"onnen unabh"angig voneinander ihre eigenen Versionen eines Dokumentes erzeugen).
\end{itemize}

Daten, die zwischen verschiedenen Versionen konstant bleiben, werden nicht dupliziert. Es werden nur die "Anderungen von Version zu Version gespeichert.


\subsubsection*{Beschreibung von VTML}
VTML-Daten werden in SGML-Kommentaren in einem HTML- oder SGML-Dokument untergebracht. So k"onnen sie von nicht VTML-f"ahigen Werkzeugen ignoriert werden. Jede Menge von Informationen ist das Ergebnis einer Modifikation einer spezifischen Version eines Dokumentes. Der VTML-Bezeichner {\em INS } kennzeichnet Einf"ugungen und der Bezeichner {\em DEL} L"oschungen. Vor der Visualisierung eines Dokumentes mu"s ein VTML-Parser dieses in Abh"angigkeit von der zu visualisierenden Version filtern.

VTML-Dokumente werden "ahnlich HTML-Dokumenten gekennzeichnet durch
\begin{flushleft}
\label{vtmldok}
$<$!$--$\{VTML {\em Attribute}\}$-->$ VTML Dokument $<$!$--$\{/VTML\}$-->$
\end{flushleft}

Die Attribute beschreiben allgemeine Charakteristika des Dokumentes und m"ussen zumindest den Namen des Dokumentes und die aktuelle Versionsnummer enthalten, die automatisch angezeigt wird, wenn der Benutzer keine Versionsnummer spezifiziert. Diese Versionsnummer mu"s automatisch gesetzt werden, wenn neue Versionen erzeugt werden.

Attributlisten bezeichnen die Attribute, die f"ur mehrere Operationen in einem Dokument G"ultigkeit besitzen. Hierbei sind zumindest der Name des Autors, die Version und das Datum der Modifikation anzugeben. W"ahrend der Editierung sollte die Version als CURRENT, und das Datum als NOW angegeben werden. Die tats"achlichen Werte werden dann w"ahrend des Festsetzens einer neuen Version, dem sogenannten "'check in "' automatisch eingesetzt.  Im Beispiel werden zwei Attributlisten benutzt, um nicht bei jeder INS bzw. DEL Operation die ansonsten n"otigen Angaben zu Autor, Versionsnummer und Datum wiederholen zu m"ussen.
 
\begin{flushleft}
$<$!$--$\{ATTR ID=1 vers=1 author="`fabio"' date="`Jul 16, 1996"'\}$-->$ \newline
$<$!$--$\{ATTR ID=2 vers=CURRENT author="`david"' date=NOW\}$-->$ \newline
$<$!$--$\{INS ATTR ID=1\}$-->$ Dies ist $<$!$--$\{DEL ATTR=2\}$-->$ dein $<$!$--$\{/DEL\}$-->$ $<$!$--$\{INS ATTR=2\}$-->$ mein $<$!$--$\{/INS\}$-->$ Dokument. $<$!$--$\{/INS\}$-->$
\end{flushleft}

INS und DEL Operationen k"onnen beliebig geschachtelt werden. Daten die mit DEL gekennzeichnet sind, werden w"ahrend der Anzeige ignoriert. Ein VTML-Dokument enth"alt also alle Informationen, um den Inhalt jeder Version zu berechnen.

Neben den Attributlisten und der Kennzeichnung der Einf"uge- und L"oschoperationen lassen sich auch mehrere parallel entstandene Varianten einer Version zu einer gemeinsamen neuen Version zusammenfassen. Desweiteren ist es m"oglich Operationen, die ein anderes Dokument betreffen zu speichern. Dies ist sinnvoll, wenn man keinen direkten Zugang zu dem Dokument hat, da"s man editieren m"ochte. Bei der jetzigen Implementation von VTML m"ussen die extern gespeicherten Modifikationen vor dem anzuzeigenden Dokument den Parser durchlaufen, dessen Algorithmus hier vereinfacht dargestellt wird:

\begin{xple}
\label{vtmlParser}
doPrint(content)
char *content
/* SIMPLIFIED */
\{
  if ((type == INS) $\mid \mid$ (type == MERGE))
     if (in\_chain (version, verstbd))
           printf("'\%s"', content) ;
  else
     if ((!in\_chain (version, verstbd)) \&\&
        (in\_chain (lastins, verstbd)))
           printf("'\%s"', content) ;
\}
\end{xple}
W"ahrend der grammatischen Analyse durch den Parser wird ein Stapel von Versionen erzeugt. Immer wenn ein neuer VTML-Bezeichner wie z.B. INS oder DEL gefunden wird, wird dieser auf den Stapel gelegt und der Textinhalt untersucht. Handelt es sich bei dem Typ des Bezeichners um INS oder MERGE, wird gepr"uft, ob die Version des Bezeichners (version) ein Vorfahre der anzuzeigenden Version (verstbd) ist. Ist dies der Fall, wird der Inhalt angezeigt. Handelt es sich um ein DEL, wird gepr"uft, ob die Version des Bezeichners kein Vorfahre ist (und daher in der anzuzeigenden Version zu l"oschen ist) und ob die Version des Textes in die das DEL eingef"ugt wurde ein Vorfahre des anzuzeigenden Textes ist. Ist dies der Fall, wird der Inhalt angezeigt. Die Vereinfachung des obigen Verfahrens besteht in der Ausklammerung der rekursiven Aufrufe, die n"otig sind um verschachtelte Operationen, die in {\em content} vorhanden sein k"onnten zu behandeln.

\subsubsection*{Bewertung}
Anhand der in Abschnitt~\ref{glVerAnf} definierten Anforderungen wird hier VTML als Versionierungssystem f"ur das WWW bewertet.

\begin{description}
\item [Stabilit"at von Versionen:] Die Stabilit"at von Versionen wird in VTML durch die Vergabe von eindeutigen Versionsnummer erreicht. "Anderungen an einer Version eines Dokumentes erzeugen eine neue Version des Dokumentes.
\item [Unabh"angigkeit von unterschiedlichen Versionierungsverfahren:] Aufgrund der \newline Ausrichtung von VTML auf die Unterst"utzung des gemeinsamen Editierens von Dokumenten bietet VTML keine Sperrkonzepte an.
\item [Abkopplung des Resourcenretrieval von der Nebenl"aufigkeitskontrolle:] VTML\newline f"uhrt keine Nebenl"aufigkeitskontrolle durch.
\item[Kompatibilit"at der Datenformate:] Ein auf einem Server arbeitendes VTML-Ver\-sio\-nier\-ungs\-system erwartet die spezielle VTML-Syntax.
\item[Unterst"utzung von Altsystemen:] Beim Abruf eines VTML-Dokumentes von einem Server, wird dieses mittels eines Pr"aprozessors ausgewertet und der Client erh"alt ein HTML-Dokument.
\end{description}

In dem letzten Punkt liegt auch das Hauptdefizit von VTML. VTML ist nur f"ur die Versionierung von Texten geeignet, nicht z.B. f"ur die Versionierung von Bildern und Zeichnungen (z.B. CAD), Audiodateien im Musikbereich (z.B. MIDI) oder Videodateien im Ferseh- und Filmbereich.  


\subsection{RDBMS-L"osung}
\label{szdbrel}

\subsection{OODBMS-L"osung}
\label{szdboo}

\subsection{ORBIX-L"osung}
\label{szorbix}






%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%