DE10047338C2 - Verfahren zur Datenkompression von strukturierten Dokumenten und Anordnung zur Durchführung des Verfahrens - Google Patents

Description

Die Erfindung betrifft ein Datenkompressionsverfahren von XML-basierten Strukturierten Dokumenten, wie sie beispiels­ weise bei einem Entwurf für MPEG-7 vorgesehen sind. Die XML (Extensible Markup Language) ist ein Standard für die Defini­ tion von Dokumentenstrukturen und dient zur Darstellung strukturierter Daten in einem Textfile und bildet beispiels­ weise die Basis für die Sprache XHTML. MPEG-7 ist ein Entwurf zu einem ISO/IEC-Standard für eine Beschreibungssprache von multimedialen Inhalten. Diese XML-basierten strukturierten Dokumente basieren auf einer Menge von Strukturierten Elemen­ ten - im folgenden auch "Schema" genannt - wie sie zum Bei­ spiel mit Hilfe von Document Type Definition (DTD), XML Sche­ ma oder Multimedia Description Schemes (DS) spezifiziert wer­ den können.

Diese strukturierten Dokumente liegen typischerweise als Textdatei vor, was einen erhöhten Speicherbedarf und für eine Übermittlung einen erhöhten Bandbreitebedarf bedeutet. Eine Möglichkeit, dieses Speicherplatz- oder Bandbreitenproblem zu lösen, ist eine Kompression der Daten. Traditionelle Daten­ kompressionsverfahren erreichen gute Kompressionsraten bei großen Textfiles, sind aber weniger effektiv bei kleineren Files, wie sie beispielsweise bei E-Business-Anwendungen im Internet vorkommen. Darüber hinaus können diese Kompressions­ verfahren auf einen kontinuierlichen Datenstrom zurückgrei­ fen. Um wirklich effizient arbeiten zu können, benötigen sie jedoch beispielsweise das gesamte Datenfile. Dies kollidiert jedoch mit den Realzeitbedingungen eines Netzes und ermög­ licht keinen Wahlfreien Zugriff auf die codierten Daten.

In der Internetveröffentlichung http: / / www9.org / w9cdrom / 154 / 154.html vom 19.09.2000 ist auf den Seiten 1 bis 24 ein Codierungsformat für eine effiziente Repräsentation und einen Austausch von XML über das Netz un­ ter dem Namen "Millau" veröffentlicht. Das Millau-Format wur­ de dazu entwickelt, XML-Dokumente in einer kompakten Art und Weise zu repräsentieren. Dies geschieht dadurch, dass "tokens" anstelle von "tags" der XML-Sprache und Attribute anstelle von Strings der XML-Sprache verwendet werden.

Die der Erfindung zugrunde liegende Aufgabe besteht nun dar­ in, ein Verfahren zur Datenkompression von Strukturierten Do­ kumenten anzugeben, bei dem eine möglichst gute Kompression bei gleichzeitig hoher Flexibilität hinsichtlich der Daten­ struktur erreichbar ist.

Dieses Problem wird hinsichtlich des Verfahrens erfindungsge­ mäß durch die Merkmale des Patentanspruchs 1 sowie durch die Merkmale des Patentanspruchs 4 und hinsichtlich der Anordnung erfindungsgemäß durch die Ansprüche 13 und 14 gelöst.

Aus den weiteren Ansprüchen ergeben sich bevorzugte Ausges­ taltungen der Erfindung.

Im folgenden werden die hier verwendeten Ausdrücke "Struktu­ rierte Elemente" und "strukturiertes Dokument" bezüglich Ih­ rer Eigenschaft definiert:

• - Strukturierte Elemente können eine Menge an zulässigen Verknüpfungen mit weiteren Strukturierten Elemente spezi­ fizieren. Des Weiteren können Strukturierte Elemente wei­ tere zulässige Inhalte spezifizieren.
• - Ein strukturiertes Dokument enthält Instanziierungen der strukturierten Elemente bestehend aus einer Auswahl an Verknüpfungen weiteren Inhalten.

Die Erfindung basiert im Wesentlichen darauf, dass Struktu­ rierte Elemente als Zustandsmuster (Knoten) eines Zustandsau­ tomaten interpretiert werden können. Die Verknüpfungen einer Menge an Strukturierten Elementen können als Zustandsübergänge des Zustandsautomaten aufgefasst werden. Demnach kann die Struktur eines strukturierten Dokumentes als Liste von Zu­ standsübergängen interpretiert werden. Die Struktur eines MPEG-7 oder eines anderen XML-basierten Dokuments kann dem­ entsprechend als Liste von Zustandsübergängen repräsentiert und binär effizient codiert werden. Der Vorteil dieses Mo­ dells ist, dass implizite Syntaxbeschränkungen sehr effizient ausgenutzt werden können, da in jedem Knoten nur die mögli­ chen Folgezustände codiert werden und dadurch nur sehr kurze Codes für die Baumstruktur des Dokuments erforderlich sind. Des weiteren ist der Codierprozess des Modells sehr flexibel und erweiterbar, da neue Eigenschaften und Anforderungen ein­ fach durch die Definition neuer Zustands-Prototypen oder Be­ fehle für einen Befehlsknoten integriert werden können. Zudem basieren Definitionen von Mengen von Strukturierten Elementen ebenfalls auf strukturierten Dokumenten, so dass mit der hier vorgestellten Codierung diese ebenfalls binär codiert werden können, zum Beispiel stellt ein XML Schema Dokument ebenfalls ein XML Dokument dar.

Durch die Erfindung werden beispielsweise folgende Vorteile erreicht:

• 1. Eine effiziente binäre Darstellung von strukturierten Do­ kumenten und/oder Strukturierten Elementen.
• 2. Eine kompakte Codierung der Struktur eines Dokuments.
• 3. Eine Unterstützung der dynamischen Veränderung des struk­ turierten Dokuments und/oder Strukturierten Elements.
• 4. Eine Unterstützung für den wahlfreien Zugriff auf ein co­ diertes Dokument.
• 5. Eine Unterstützung für die progressive Übertragung, d. h. die Reihenfolge der Elemente eines Dokuments im Datenstrom ist variabel.
• 6. Eine Unterstützung einer skalierbaren Binärrepräsentierung eines Dokumentes, d. h. es wird Basisinformation übertra­ gen, die die grundlegenderen Elemente beinhaltet und eine oder mehrere Datenströme mit zusätzlichen Details.
• 7. Eine Trennung der Struktur des Dokuments vom Inhalt wird ebenso unterstützt, wodurch der Inhalt mit einer separaten darauf spezialisierten Methode komprimiert werden kann.

Nachfolgend wird anhand der Zeichnung ein Ausführungsbeispiel der Erfindung näher erläutert. Dabei zeigt:

Fig. 1 einen Baumstrukturknoten eines Zustandsautomaten,

Fig. 2 einen Instruktionsknoten eines Zustandsautomaten

Fig. 3 einen Attributknoten eines Zustandsautomaten

Fig. 4 ein XML-Schema für ein Beispiel einer Menge von Strukturierten Elementen,

Fig. 5 ein zum Beispiel von Fig. 4 gehöriges binäres Format der Struktur,

Fig. 6 Anweisungen in Form eines Bitcodes zum Aufbau der Struktur von Fig. 4 bzw. 5 mit entsprechenden Kommentaren,

Fig. 7 ein Beispiel eines Strukturierten Dokuments in Form eines XML-Dokuments,

Fig. 8 Anweisungen in Form eines Bitcodes zur Erzeugung des in Fig. 7 beschriebenen Strukturierten Dokuments,

Fig. 9 eine binäre Darstellung des Strukturierten Dokuments von Fig. 7 und

Fig. 10 Anweisungen in Form eines kommentierten Bitcodes zur Änderung eines Strukturierten Dokuments.

In den Fig. 1 bis 3 sind Strukturierte Elemente (Knoten) zum Aufbau einer hier baumartigen Struktur für ein struktu­ riertes Dokument gezeigt. Die Struktur ist in den meisten Fällen aus mehreren dieser Strukturierten Elementen gebildet, kann aber auch aus nur einem dieser Strukturierten Elemente gebildet sein.

In Fig. 1 ist ein Baumstrukturknoten TSN dargestellt, aufge­ baut aus einer lokalen Identifikationsnummer NODE-ID, einen Speicherplatz für die Anzahl NC von Kindknoten, eine Zelle mit der Adresse 000 für einen Zeiger auf einen Vaterknoten und Zellen mit den Adressen 001 bis 110 für Zeiger auf Kind­ knoten sowie eine Zelle mit der Adresse 111 mit einem Zeiger auf einen Befehlsknoten PIN. Die Knotenbezeichnung NODE-ID definiert den Knotentyp in eindeutiger Weise. Der Knotentyp kann entweder ein vordefinierter Knotentyp sein, der bei­ spielsweise aus Standardelementen eines standardisierten MPEG-7-Beschreibungsschemas definiert wurde oder aber ein ab­ geleiteter oder erweiterter Knoten mit einer lokalen Identi­ fikationsnummer. Aus der Anzahl der Kindknoten wird die Länge des Bitfeldes berechnet, das zur Adressierung der Kindknoten benutzt wird. In diesem Beispiel sind mit einer 3-Bitadresse bis zu 6 Kindknoten möglich. Mit der Adresse alle Bits gleich Null, hier 000, erfolgt ein Übergang in eine höhere Ebene ei­ ner Dokumentenhierarchie. Das letzte Codewort mit allen Bits gleich Eins, hier 111, hat die spezielle Bedeutung, die den Zustandsautomat in den Befehlsknoten zu bringen. Das Wesent­ liche ist dabei, dass bei der Übermittlung bzw. der Speiche­ rung des Dokuments nicht die Knotenidentifizierungen der Kindknoten übertragen werden, sondern nur Anweisungen in Form eines Baumverzweigungs-Codes TBC, wodurch die Codeworte sehr kurz und ihre Länge unabhängig von der Tiefe des Knotens in­ nerhalb des Baumes ist.

In Fig. 2 ist ein Befehlsknoten IN dargestellt, der hier ab­ hängig von einer 4-Bitadresse eine Escape-Funktion, eine Ini­ tialisierung eines neuen Dokuments und beispielsweise weitere Befehle zum Hinzufügen und Löschen von Knoten und Gruppen so­ wie weitere Funktionen enthält. In einem Instruction Set wer­ den verschiedene Verfahren definiert, mit denen ein Strukturiertes Dokument durch Erweiterung oder Beschränkung verän­ dert werden kann. Um diese Funktionalität zu unterstützen, wird der Typ eines Befehlsknotens initiiert. Wenn ein Knoten in einem Strukturierten Dokument verändert werden soll, wer­ den die entsprechenden Codeworte gesendet, um in dem instan­ ziierten Dokumentbaum an den betreffenden, zu ändernden Kno­ ten zu gelangen. Dies kann entweder ausgehend von der Doku­ mentwurzel erfolgen, also durch einen absoluten Pfad, oder mit Hilfe eines Verweises in einer Zeigertabelle oder mit ei­ nem relativen Pfad ausgehend von der aktuellen Position im Baum. Dann wird das Codewort für den Befehlsknoten IN gesen­ det, d. h. der letzte Eintrag im Baumverzweigungsknoten, in diesem Beispiel also 111. Das folgende Codewort definiert die erste auszuführende Instruktion sowie gegebenenfalls die zu­ gehörigen Parameter. Auch weitere Instruktionen können fol­ gen. Wenn die Escape-Instruktion, hier also 000, gesendet wird, schaltet der zugrundegelegte Zustandsautomat zurück in den Vaterknoten, von dem aus der Befehl aufgerufen wurde. Der Befehls- oder Instruktionstyp legt fest, wie viele Parameter, hier P1 und P2, gelesen werden sowie deren Format und Seman­ tik. Die Parameter definieren z. B. die Position, an der ein Knoten eingefügt oder gelöscht werden soll sowie die Knoten­ identifizierung bei neu hinzugefügten Knoten. Neben den in Fig. 2 dargestellten Basisinstruktionen sind beispielsweise noch folgende Instruktionen denkbar:

• 1. Setze einen lokalen Pfad,
• 2. ändere die Codetabelle,
• 3. lese Knotenidentifizierungen oder
• 4. lese einen Satz von Knoten usw.

In Fig. 3 ist ein Attributknoten AN dargestellt. Für diese Art Knoten sind spezielle Knotenidentifizierungen NODE-ID re­ serviert. Es gibt zwei verschiedene Klassen von Attributen:

• 1. Solche, die vom Benutzer im Schema definiert sind und bei der Instanziierung mit einem Wert belegt werden können, und
• 2. Standardattribute, die ebenfalls im Schema definiert wer­ den, aber Einschränkungen an die Syntax des Strukturierten Dokuments zur Folge haben, z. B. wie oft ein Element mindes­ tens oder höchstens auftreten darf usw. Die Knotenidentifi­ zierung NODE-ID legt dabei fest, um welche Klasse und um wel­ chen Typ es sich handelt Attribute sind Blätter im Dokument- Baum, d. h. sie dürfen keine weiteren Kindknoten haben, son­ dern nur einen Wert. Der Typ des Attributs legt dabei den Typ des Wertes fest, der bei der Übertragung erwartet wird. Es könnte beispielsweise eine Zeichenkette oder eine Zahl sein. Diese Information wird ausgenutzt, um festzustellen, wie vie­ le Bits für das Attribut gelesen werden müssen. Ist der Typ z. B. eine vorzeichenlose ganze Zahl mit acht Bits, dann wer­ den acht Bits für dieses Attribut gelesen, bei einem String wird bis zum ersten Null-Oktett gelesen.

Inhaltsknoten sind ebenso wie Attributknoten Blätter der Baumstruktur eines Strukturierten Dokuments. In XML gibt es viele vordefinierte Datentypen, die als Attribute oder Inhal­ te genutzt werden können.

In Fig. 4 ist ein XML-Schema XMLS für ein Beispiel einer Menge von Strukturierten Elementen dargestellt. Hierbei wer­ den u. a. Strukturierte Elemente wie "purchase order type", "address", "items" und entsprechende Variable von diesem Typ definiert.

In Fig. 5 ist ein zum Beispiel von Fig. 4 gehöriges binäres Format SBF der Struktur dargestellt. Die Struktur wird im Zu­ standsautomatenmodell in die in Fig. 5 dargestellte Struktur übertragen, wobei die Namen der Knotenbezeichnungen NODE-ID ID: 1, . . . 9 nur zur Referenz in der Textversion von Fig. 4 dienen und hier nur beliebige gewählte Zahlen darstellen. Hieraus wird deutlich, dass die gesamte Menge bis auf die Blätter nur Strukturierten Elementen enthält, deren Anzahl von Kindknoten sich im allgemeinen unterscheiden. Ein Decoder muss dies Struktur kennen, um den Bitstrom zur Instanziierung richtig interpretieren zu können. Deshalb muss das Schema beispielsweise vom Server an den Client übertragen werden. Dies kann beispielsweise in Textform oder aber als Anweisung für ein Modell eines Zustandsautomaten erfolgen. Im ersteren Fall muss der Client selbst aus dem Beschreibungsschema in der Textform ein entsprechendes Binärformat des Schemas er­ zeugen.

In Fig. 6 sind Anweisungen an ein Modell für einen Zustands­ automaten in Form eines Bitcodes BC dargestellt, wobei diese Anweisungen zum Aufbau der Struktur von Fig. 4 bzw. 5 füh­ ren. Hieraus wird deutlich, dass in einem Befehlsknoten des Zustandsautomaten ein neuer Baumverzweigungsknoten erzeugt wird und zur Erzeugung der Baumstruktur die Zeiger auf die jeweiligen Kindknoten festgelegt werden.

In Fig. 7 ist ein Beispiel eines Strukturierten Dokuments in Form eines XML-Dokuments XML1 dargestellt. Das hier darge­ stellte Beispieldokument wurde mit dem eingangs definierten Schema aufgebaut. Aus dem hier dargestellten Dokument wird u. a. deutlich, dass den eingangs definierten Strukturelementen hierbei konkrete Inhalte I1, I2, . . . zugeordnet werden.

In Fig. 8 sind Anweisungen BC1 für das durch die baumartige Struktur definierte Modell eines Zustandsautomaten in Form eines Bitcodes zur Erzeugung des in Fig. 7 beschriebenen Strukturierten Dokuments dargestellt. Hierbei wird deutlich, dass zur Belegung der Inhaltsknoten nur eine sehr geringe Ad­ ressbreite AB benötigt wird, da der Rest der Adressierung quasi durch den jeweiligen Zustand des Zustandsautomaten ge­ liefert wird. Dies hat eine starke Kompression zur Folge, da pro Inhalt nicht immer die volle absolute Adresse für den je­ weiligen Inhalt übertragen bzw. gespeichert werden muss. Die­ sem Beispiel wird der Inhalt zusammen mit dem Baumverzwei­ gungscode übertragen. Der Inhalt könnte aber auch von der Be­ schreibung abgetrennt in einem eigenen Datenstrom übertragen werden.

In Fig. 9 ist eine binäre Darstellung DBF des Strukturierten Dokuments von Fig. 7 dargestellt, wie es durch die Anweisun­ gen von Fig. 8 durch den Zustandsautomat, der seinerseits durch die vorher beschriebene Struktur bestimmt ist, erzeugt wird. Das Wurzelelement des Dokuments ist hier in diesem Bei­ spiel "purchase order", seine Knotenidentifizierung NODE-ID ist 20, die hier zufällig für das Beispiel gewählt wurde. Das erste Feld enthält die Zahl der Kindknoten, wobei die Knoten­ zahl hier 1 ist, da der Vaterknoten und der Befehlsknoten im­ mer vorhanden sind und implizit mitzählen. Die Referenz zum Vaterknoten dieses Knotens ist der Initialisierungsknoten, der alle Dokumente des Terminals verwaltet. Der erste Kind­ knoten hat den Baumverzweigungscode TBC 01 und die Referenz zeigt auf "purchase order type". Es gibt keinen zweiten Kind­ knoten, deshalb ist die Referenz 10 NULL. Der letzte Baumver­ zweigungscode TBC zeigt auf den Befehlsknoten, der aufgerufen werden könnte, wenn dieser Knoten geändert werden soll. Der zweite Knoten "purchase order type" enthält alle Unterelemen­ te, die die detaillierten Informationen zu "purchase order" enthalten, nämlich "ship to", "built to", "comment", "items", "date". Der erste Kindknoten zeigt auf den Vaterknoten, näm­ lich auf den Knoten mit der Identifizierung NODE-ID 20, also auf "purchase order". Auf diese Weise wird der Dokumentenbaum aufgebaut. Die Inhalts- und Attributsknoten haben keine Baum­ verzweigungsknoten, sondern nur eine Referenz auf den Vater­ knoten. Selbst die Referenz auf den Vaterknoten könnte ent­ fallen, da sie definitionsgemäß die Blätter des Baumes sind und ihrerseits keine Kinder haben können, sondern nur Attri­ butdaten oder Inhalt darstellen. Der Inhalt könnte codiert werden als "inline-Daten", die z. B. durch eine mit Null ab­ geschlossene Zeichenkette gebildet werden, oder als Zeiger auf einen anderen Datenstrom repräsentiert werden, der sepa­ rat komprimiert wird. In entsprechender Weise können auch dy­ namische Veränderungen des Dokuments vorgenommen werden. Im folgenden wird in einem Beispiel gezeigt, wie die Instanz des bestehenden Dokuments dynamisch vom Server mit Hilfe von Anweisungen an ein Modell eines Zustandsautomaten auf der Emp­ fängerseite, also beim Client durchgeführt wird. Angenommen, es soll folgender zusätzlicher Knoten zur Liste der Waren hinzugefügt werden:
<item partNum="724-CN"<
<productName<Mountain Bike</productName<
<quantity<1</quantity<
<price<3800.00<//price<
<comment<I want it in colour blackR/comment<
</item<

Ausgehend von einem in Fig. 9 dargestellten Dokumentenbaum beim Client werden vom Server Anweisungen in Form eines Bit­ codes BC3 wie er in Fig. 10 dargestellt ist, übertragen. Der hier beschriebene Code bewirkt beim Zustandsautomaten des Client im wesentlichen folgendes:

• 1. Durchführen einer Setup-Sequenz, wobei sich das System während der Initialisierung in einem Befehlsknoten befindet.
• 2. Gehe zu der Position im Baum, die verändert werden soll. Hierbei ist auch ein vordefinierter Pfad in einer Baumzeiger­ tabelle anwendbar, für den Fall tief verschachtelter Struktu­ ren, auf die oft zugegriffen wird.
• 3. Gehe zum Befehlsknoten, wobei auch ein rekursiver Aufruf möglich ist.
• 4. Erweiterung des Baumverzweigungscodes von 2 auf 3 Bits und die Erhöhung der Knotenanzahl von 2 auf 3, wobei sich im Kno­ ten mit der NODE-ID 25 der Inhalt von 11 auf 111 ändert.
• 5. Danach folgen ähnliche Schritte wie bereits weiter oben erwähnt. Danach ist das System in dem Befehlsknoten und an­ schließend ist der Zustandsautomat im veränderten Knoten <i­ tems<.
• 6. Um vom Vaterknoten von <items< zurückzukehren, müssen 3 Bits übertragen werden, da die Zahl der Kinder sich von 2 auf 3 erhöht hat.
• 7. Zum Schluss erfolgt eine Rückkehr zur Wurzel, das wieder eine Instanz des Befehlsknotens darstellt. Das System ist be­ reit für weitere Befehle.

Auf dieser Basis ist eine Datenkompression von einer Menge von Strukturierten Elementen bzw. eines Beschreibungsschema, von Strukturierten Dokumenten mit instanziierten Strukturier­ ten Elementen und von entsprechenden Änderungen einer Menge von Strukturierten Elementen oder eines Strukturierten Doku­ ments möglich, wobei jeweils ein Strom von Anweisungen an ei­ nen Zustandsautomat erzeugt wird, der dann entweder gespei­ chert oder übertragen wird.

In entsprechend umgekehrter Weise ist natürlich auch eine De­ kompression in Strukturen, oder Strukturierte Dokumenten oder deren Änderungen aus den entsprechenden Anweisungen für den zugehörigen Zustandsautomaten möglich.

Auf dieser Basis sind Anordnungen zur Durchführung des Ver­ fahrens in Form von Encodern oder Decodern realisierbar.

Claims (13)

1. Verfahren zur Datenkompression eines Strukturierten Doku­ ments,
bei dem das Strukturierte Dokument in Textform (XML1) vor­ liegt,
bei dem zu Beginn eine aus mindestens einem Strukturierten Element (TSN, . .) bestehende Struktur (SBF) eines Schemas aufgebaut wird,
bei dem auf der Basis der zu Grunde liegenden Struktur des Schemas Anweisungen (BC1) mit relativen Adressen (ID: 20. .53) derart ermittelt werden, dass eine durch das Strukturierte Dokument beschriebene Datenstruktur (DBF) entsteht, wobei relative Adressen von einem jeweiligen ak­ tuellen Knoten der zu Grunde liegenden Struktur ausgehende Zeiger zu einem Vaterknoten, mindestens einem Kindknoten oder einem Befehlsknoten darstellen und
bei dem die Anweisungen (BC1) mit den relativen Adressen das Strukturierte Dokument in komprimierter Form darstel­ len.

2. Verfahren nach Anspruch 1, bei dem die Anweisungen (BC1) binär mit wahlweise variabler oder fester Länge repräsentiert oder codiert werden, und bei dem diese variable oder feste Länge von der Anzahl der möglichen Verknüpfungen (NC) eines Strukturierten Elementes abhängt.

3. Verfahren nach Anspruch 1 oder 2, bei dem die Strukturen mindestens Baumstrukturknoten (TSN) und zusätzlich Befehlsknoten (IN) und/oder Inhaltsknoten und/oder Attributknoten (AN) aufweisen.

4. Verfahren zur Datenkompression eines strukturierten Doku­ ments in Form eines Schemas,
bei dem ein Schema (XMLS) für Strukturierte Dokumente in Textform vorliegt,
bei dem auf der Basis mindestens eines bekannten Struktu­ rierten Elements (TSN, . .) Anweisungen (BC) mit relativen Adressen (ID: 1 . . 9, 102 . .) derart ermittelt werden, dass ei­ ne durch das Schema für Strukturierte Dokumente beschriebe­ ne Datenstruktur (SBF) entsteht, wobei relative Adressen von einem jeweiligen aktuellen Knoten der zu Grunde liegen­ den Struktur ausgehende Zeiger zu einem Vaterknoten, min­ destens einem Kindknoten oder einem Befehlsknoten darstel­ len und
bei dem die Anweisungen mit den relativen Adressen das Schema für Strukturierte Dokumente in komprimierter Form darstellen.

5. Verfahren nach Anspruch 1 oder 4, bei dem eine wahlweise variable oder feste Länge der relativen Adressen von der An­ zahl der möglichen Verknüpfungen eines Strukturierten Elemen­ tes abhängt.

6. Verfahren zur Datenkompression eines Strukturierten Doku­ ments,
bei dem das Strukturierte Dokument in Textform vorliegt,
bei dem zu Beginn auf der Basis mindestens eines Struktu­ rierten Elements und einem Schema für das Strukturierte Dokument in komprimierter Form eine Datenstruktur aufge­ baut wird, die durch das Schema des Strukturierten Doku­ ments in komprimierter Form beschrieben ist, wobei das Schema für das Strukturierte Dokument in komprimierter Form gemäß dem Verfahren nach Anspruch 4 gebildet wurde,
bei dem auf der Basis der zu Grunde liegenden Struktur für das Schema Anweisungen (BC3) relativen Adressen derart er­ mittelt werden, dass eine durch das Strukturierte Dokument beschriebene Datenstruktur entsteht, wobei relative Adres­ sen von einem jeweiligen aktuellen Knoten der zu Grunde liegenden Struktur ausgehende Zeiger zu einem Vaterknoten, mindestens einem Kindknoten oder einem Befehlsknoten dar­ stellen, und
bei dem die Anweisungen mit den relativen Adressen das Strukturierte Dokument in komprimierter Form darstellen.

7. Verfahren nach Anspruch 1, bei dem das strukturierte Doku­ ment verändert wird und die Veränderung durch die relative Adresse des Operanden im instanziierten strukturiertem Doku­ ment und durch die Adresse einer Operation innerhalb eines Befehlsknotens spezifiziert wird.

8. Verfahren nach Anspruch 4, bei dem das Schema verändert wird und die Veränderung durch die relative Adresse des Ope­ randen im Schema, und die Operation durch die Adresse inner­ halb eines Befehlsknoten spezifiziert wird.

9. Verfahrens nach einem der vorhergehenden Ansprüche zur Datenkomprimierung eines XML-Dokuments, eines in einer von XML abgeleiteten Sprache verfassten Dokuments oder eines MPEG7-Dokuments.

10. Verfahren nach einem der vorhergehenden Ansprüche, bei dem aus der komprimierten Darstellung die Struktur des Doku­ ments oder die Struktur des Schemas ganz oder teilweise re­ konstruiert wird.

11. Verfahren nach Anspruch 10, bei dem das strukturierte Do­ kument oder das Schema ganz oder teilweise in eine textuelle Darstellung decodiert wird.

12. Anordnung zur Durchführung des Verfahrens nach Anspruch 1,
bei der Speicher einer Datenverarbeitungseinrichtung zum Speichern des Strukturierten Dokuments vorhanden sind,
bei der Bestandteile einer Datenverarbeitungseinrichtung vorhanden sind, die auf Basis einer aus mindestens einem Strukturierten Element bestehenden Struktur für ein Schema aufbauen, und
bei der Bestandteile der Datenverarbeitungseinrichtung vor­ handen sind, die auf der Basis der zu Grunde liegenden Struktur für das Schema Anweisungen (101) mit relativen Ad­ ressen (101) derart ermitteln, dass eine durch das Struktu­ rierte Dokument beschriebene baumartige Datenstruktur ent­ steht, wobei relative Adressen von einem jeweiligen aktuel­ len Knoten der zu Grunde liegenden Struktur ausgehende Zei­ ger zu einem Vaterknoten, mindestens einem Kindknoten oder einem Befehlsknoten darstellen und wobei die Anweisungen mit den relativen Adressen das Strukturierte Dokument in komprimierter Form darstellen.

13. Anordnung zur Durchführung des Verfahrens nach Anspruch 4,
bei der Speicher einer Datenverarbeitungseinrichtung zum Speichern eines Schemas für Strukturierte Dokumente vorhan­ den ist und
bei der Bestandteile der Datenverarbeitungseinrichtung vor­ handen sind, die auf der Basis mindestens eines bekannten Strukturierten Elements Anweisungen mit relativen Adressen derart ermitteln, dass eine durch das Schema für Struktu­ rierte Dokumente beschriebene Datenstruktur entsteht, wobei relative Adressen von einem jeweiligen aktuellen Knoten der zu Grunde liegenden Struktur ausgehende Zeiger zu einem Va­ terknoten, mindestens einem Kindknoten oder einem Befehls­ knoten darstellen und wobei die Anweisungen mit relativen Adressen das Schema für Strukturierte Dokumente in kompri­ mierter Form darstellen.