DE60129232T2

DE60129232T2 - Xml-kodierungsverfahren

Info

Publication number: DE60129232T2
Application number: DE60129232T
Authority: DE
Inventors: Ernest Yiu Carlingford WAN
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2000-10-06
Filing date: 2001-10-05
Publication date: 2008-03-06
Anticipated expiration: 2021-10-06
Also published as: CN1244062C; US20040028049A1; EP1323064A1; EP1323064A4; WO2002029602A1; KR100566019B1; AUPR063400A0; KR20030061819A; US7647552B2; ATE366441T1; DE60129232D1; JP2004510279A; EP1323064B1; CN1455901A; JP4574114B2

Description

Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich auf das Enkodieren von XML (Extensible Markup Language) Dokumenten und insbesondere auf zumindest eines aus der Komprimierung, dem Streaming, dem Suchen und dem dynamischen Aufbau von XML-Dokumenten.
Hintergrund
Um ein Streaming, Herunterladen und Speichern von MPEG-7-Beschreibungen effizienter zu gestalten, kann die Beschreibung enkodiert und komprimiert werden. Eine Analyse von einer Anzahl von Aufgaben bezüglich der Zuführung von MPEG-7-Beschreibungen hat eine Betrachtung des Formats einbezogen, welches zur binären Enkodierung zu verwenden ist. Bestehende Enkodierungs-Schemata für XML, welche den WBXML-Vorschlag von WAP (das Drahtlos-Applikationsprotokoll-Forum), den Millau-Algorithmus und den Xmill-Algorithmus enthalten, wurden jeweils in Betracht gezogen.
Durch WBXML werden häufig verwendete XML-Kennzeichen, Attribute und Werte einem festgelegten Satz von Kodes von einem globalen Koderaum zugewiesen. Anwendungsspezifische Kennzeichennamen, Attributnamen und einige Attributwerte, welche über Dokumenten-Fälle hinweg wiederholt werden, werden Kodes von einigen lokalen Koderäumen zugewiesen. WBXML bewahrt den Aufbau von XML-Dokumenten. Der Inhalt als auch Attribut-Werte, welche in der Dokumenttyp-Definition (DTD) nicht bestimmt sind, können in Reihe oder in einer Zeichenfolge-Tabelle gespeichert werden. Es wird erwartet, dass Tabellen der Dokument-Koderäume der bestimmten Klasse von Anwendungen bekannt sind oder mit dem Dokument übertragen werden.
Obwohl WBXML die Kennzeichen und Attribute anzeigt, gibt es keine Komprimierung des Textinhaltes. Während dies möglicherweise für die Wireless Markup Language (WML) Dokumente, welche zur Verwendung unter dem WAP vorgeschlagen sind, und für welche WBXML entworfen ist, ausreicht, da solche Dokumente für gewöhnlich einen begrenzten Textinhalt haben, wird WBXML als ein nicht sehr wirksames Enkodierungsformat für die typischerweise textbeladenen XML-Dokumente betrachtet. Die Millau-Annäherung erweitert das WBXML-Enkodierungsformat, indem ein Text unter Verwendung eines herkömmlichen Textkomprimierungsalgorithmus komprimiert wird. Millau zieht ebenfalls ein Vorteil des Schemas und der Datentypen, um eine bessere Komprimierung von Attributwerten zu ermöglichen, welche von einfachen Datentypen sind.
Die Millau-Annäherung ist in dem Dokument „Efficient Representation and Streaming of XML Content over the Internet Medium", Girardot, M; et al., IEEE International Conference an Multimedia and Expo, vol. 1, 30. Juli 2000, Seiten 67 bis 70, diskutiert.
Die Autoren des Xmill-Algorithmus haben ein sogar komplexeres Enkodierungsschema dargelegt, obwohl dieses nicht auf WBXML basiert. Abgesehen von einer Trennung von Aufbau und Textenkodierung und unter Verwendung einer Typinformation in DTD und dem Schema zum Enkodieren von Werten von eingebauten Datentypen, erlaubt dieses Schema ebenfalls:

(i) ein Gruppieren eines Elements des gleichen oder bezüglichen Typs in einen Container (um eine Redundanz zu erhöhen);
(ii) ein separates Komprimieren jedes Containers unter Verwendung eines unterschiedlichen Komprimierers;
(iii) ein Erlauben, dass einzelne Komprimierer zu Komplexeren zusammengefasst werden, und
(iv) ein Erlauben der Verwendung von neu spezialisierten Komprimierern für hoch spezialisierte Datentypen.

Die Xmill-Annäherung ist diskutiert in „Xmill: An efficient Compressor for XML Data", Sigmod Record, Associate for Computing Machinery, New York, US, vol. 29, no. 2, Juni 2000, Seiten 153–164.
Die WO 99/37072 diskutiert ein digitales Verarbeitungssystem, welches mit einer zeitbezogenen Sequenz von Mediendaten bereitgestellt ist, welches ein Verfahren zum Übertragen der zeitbezogenen Sequenz von Mediendaten gemäß einem Übertragungsprotokoll anzeigt.
Nichtsdestotrotz sind bestehende Enkodierungsschemata lediglich zur Komprimierung entworfen. Sie unterstützen nicht das Streaming von XML-Dokumenten. Zusätzlich können Elemente immer noch nicht wirksam unter Verwendung des XPath/XPointer-Adressierungsschemas lokalisiert werden, und ein Dokument kann nicht stufenförmig enkodiert werden, wenn es aufgebaut wird.
Die JP 10-143403 offenbart die Division der Strukturinformation von der Paragrafeninformation, welche mit der hierarchischen Struktur von einer Datei bereitgestellt ist; sie offenbart ebenfalls die Ausarbeitung von Verbindungen zu dieser Paragrafeninformation. Jedoch wird diese Trennung der Struktur und des Paragrafen auf dem Datei-Pegel, nicht auf dem Paket-Pegel, durchgeführt.
Gemäß einem Aspekt stellt die vorliegende Erfindung ein Verfahren zum Kommunizieren von zumindest einem Teil eines strukturierten Dokuments, wie in Anspruch 1 dargelegt, bereit.
Gemäß einem weiteren Aspekt stellt die vorliegende Erfindung ein Verfahren zum Dekodieren eines enkodierten XML-Dokuments, wie in Anspruch 14 dargelegt, bereit.
Gemäß einem weiteren Aspekt stellt die vorliegende Erfindung eine Einrichtung zum Kommunizieren von zumindest einem Teil eines strukturierten Dokuments, wie in Anspruch 22 dargelegt, bereit.
Gemäß einem weiteren Aspekt stellt die vorliegende Erfindung eine Einrichtung zum Dekodieren eines enkodierten XML-Dokuments, wie in Anspruch 35 dargelegt, bereit.
Die hier offenbarten Enkodierungs- und Dekodierungs-Schemata trennen eine Struktur- und Text-Enkodierung und verwenden das Schema und die Datentypen zum Enkodieren von Werten von eingebauten Datentypen. Zusätzlich stellt die Offenbarung eine Unterstützung für das Streaming bereit, und erlaubt ein wirksames Suchen unter Verwendung von XPath/XPointer-ähnlichen Adressierungsmechanismen. Dieses erlaubt ebenfalls, dass ein XML-Dokument enkodiert und gestreamt wird, während es aufgebaut wird. Diese Merkmale sind zur Ausstrahlung und für Mobilanwendungen wichtig. Das hier offenbarte Enkodierungsschema unterstützt ebenfalls mehrere Namensräume und stellt EBNF-Definitionen des Bitstroms und einen Satz von Schnittstellen zum Aufbauen eines erweiterbaren Enkoders bereit.
Kurze Beschreibung der Zeichnungen
Es werden nun ein oder mehrere Ausführungsformen der vorliegenden Erfindung mit Bezug auf die Zeichnungen und den Anhang beschrieben, in denen:
1 schematisch ein enkodiertes XML-Dokument anzeigt;
2 die Organisation des Struktursegments anzeigt;
3 schematisch das Enkodermodell anzeigt;
4 schematisch das Dekodermodell anzeigt;
5 schematisch den Enkoder darstellt, welcher ein XML-Dokument stufenförmig in mehrere Pakete enkodiert;
6A und 6B anzeigen, wie Knoten-Lokatoren dazu verwendet werden, um einen Knoten an seine Unter-Bäume in weiteren Strukturpaketen zu verbinden, und wie jeder Knoten-Lokator die Paketnummer von einem Unter-Baum-Paket enthält;
7 schematisch anzeigt, wie eine lange Zeichenfolge als Zeichenfolgen-Fragmente in mehreren Textpaketen gespeichert wird, wobei jedes Paket zu dem Textpaket zeigt, welches die nächsten Fragmente enthält;
8 eine schematische Blockdiagramm-Darstellung eines Computersystems ist, mit welchem die beschriebenen Anordnungen implementiert werden können;
9 ein Flussdiagramm eines XML-Dokument-Enkodierungsbetriebes ist;
10 ein Flussdiagramm ist, welches darstellt, wie unterschiedliche Datentypen in den Enkodierungsbetrieben behandelt werden können; und der Anhang eine Definition bereitstellt, welche für den enkodierten Bitstrom und die Parameter dessen hilfreich ist.
Genaue Beschreibung
Die Verfahren zum Enkodieren und Dekodieren von XML-Dokumenten, welche mit Bezug auf 1 bis 7 und 9 und 10 beschrieben werden, werden vorzugsweise unter Verwendung eines Mehrfachzweck-Computersystems 800, wie beispielsweise jenes, welches in 8 gezeigt ist, praktiziert, wobei die Prozesse von 1 bis 7 als Software implementiert sein können, wie beispielsweise ein Anwendungsprogramm, welches innerhalb des Computersystems 800 ausgeführt wird. Insbesondere können die Schritte der Verfahren durch Anweisungen der Software erfolgen, welche durch den Computer ausgeführt werden. Die Software kann in zwei getrennte Teile aufgeteilt werden; ein Teil zum Durchführen der Enkodierungs/Dekodierungs-Verfahren; ein weiterer Teil zum Verwalten der Benutzerschnittstelle zwischen dem Enkodierungs/Dekodierungs-Verfahren und dem Benutzer. Die Software kann in einem computerlesbaren Medium gespeichert sein, welches beispielsweise die im Folgenden beschriebenen Speichervorrichtungen enthält. Die Software wird vom computerlesbaren Medium in den Computer geladen und dann durch den Computer ausgeführt. Ein computerlesbares Medium, welches eine solche Software oder ein auf ihn gespeichertes Computerprogramm hat, ist ein Computerprogrammprodukt. Die Verwendung des Computerprogrammproduktes im Computer bewirkt vorzugsweise eine vorteilhafte Einrichtung zum Enkodieren/Dekodieren von XML-Dokumenten.
Das Computersystem 800 enthält ein Computermodul 801, Eingabevorrichtungen, wie beispielsweise eine Tastatur 802 und eine Maus 803, Ausgabevorrichtungen, welche einen Drucker 815 enthalten, und eine Anzeigevorrichtung 814. Eine Modulator/Demodulator (Modem) Transceiver-Vorrichtung 816 wird durch das Computermodul 801 zur Kommunikation zu und von einem Kommunikationsnetzwerk 820, beispielsweise verbindbar über eine Telefonleitung 821 oder ein weiteres funktionales Medium, verwendet. Das Modem 816 kann dazu verwendet werden, um einen Zugriff auf das Internet und weitere Netzwerksysteme zu erlangen, wie beispielsweise ein Lokalbereichs-Netzwerk (LAN) oder ein Weitbereichs-Netzwerk (WAN). Wie zu erkennen, verbindet ein Server-Computersystem 850 mit dem Netzwerk 820, welches Kommunikationen mit dem Computersystem 800 ermöglicht. Der Server-Computer 850 hat typischerweise einen ähnlichen Aufbau und/oder ist auf eine ähnliche oder komplementäre Weise zum Computersystem 800 betriebsbereit. Beispielsweise, während das Computersystem 800 eine XML-Enkodierungsfunktion durchführen kann, kann der Server-Computer 850 eine komplementäre XML-Dekodierungsfunktion durchführen, und umgekehrt.
Das Computermodul 801 enthält typischerweise zumindest eine Prozessoreinheit 805, eine Speichereinheit 806, welche beispielsweise aus einem Halbleiter Arbeitsspeicher (RAM) und einem Festspeicher (ROM) ausgebildet ist, Eingabe/Ausgabe (I/O) Schnittstellen, welche eine Video-Schnittstelle 807 enthalten, und eine I/O-Schnittstelle 813 für die Tastatur 802 und die Maus 803 und optional einen Joystick (nicht dargestellt), und eine Schnittstelle 808 für das Modem 816. Eine Speichervorrichtung 809 ist bereitgestellt und enthält typischerweise ein Festplatten-Laufwerk 810 und ein Floppy Disk-Laufwerk 811. Es kann ebenfalls ein Magnetband-Laufwerk (nicht dargestellt) verwendet werden. Ein CD-ROM-Laufwerk 812 ist typischerweise als eine nicht-flüchtige Datenquelle bereitgestellt. Die Bauteile 805 bis 813 des Computermoduls 801 kommunizieren typischerweise über einen zwischenverbundenen Bus 804 und auf eine Art und Weise, welche zu einem herkömmlichen Betriebsmodus des Computersystems 800 führt, welcher dem Fachmann bekannt ist. Beispiele von Computern, auf welchen die beschriebenen Anordnungen praktiziert werden können, enthalten IBM-PCs und Kompatible, Sun Sparcstations oder ähnliche Computersysteme, welche daraus entwickelt sind.
Typischerweise liegt das Anwendungsprogramm auf dem Festplatten-Laufwerk 810 vor und wird durch den Prozessor 805 ausgelesen und in seiner Ausführung gesteuert. Ein Zwischenspeichern des Programms und jeglicher Daten, welche aus dem Netzwerk 820 abgerufen sind, kann unter Verwendung des Halbleiterspeichers 806, möglicherweise in Zusammenarbeit mit dem Festplatten-Laufwerk 810, erreicht werden. In einigen Fällen kann das Anwendungsprogramm enkodiert auf einer CD-ROM oder Floppy Disk dem Benutzer zugeführt werden und über das entsprechende Laufwerk 812 oder 811 ausgelesen werden, oder kann alternativ durch den Benutzer aus dem Netzwerk 820 über die Modemvorrichtung 816 ausgelesen werden. Ferner kann die Software ebenfalls in das Computersystem 800 von einem weiteren computerlesbaren Medium geladen werden, welches ein Magnetband, eine ROM oder integrierte Schaltung, eine optomagnetische Disk, einen Funk- oder Infrarot-Übertragungskanal zwischen dem Computermodul 801 und einer weiteren Vorrichtung, eine computerlesbare Karte, wie beispielsweise eine PCMCIA-Karte, und das Internet und Intranet, welche E-Mail-Übertragungen und eine Information enthalten, welche auf Websites gespeichert sind, und dergleichen, enthält. Das Vorhergehende ist lediglich beispielhaft für relevante computerlesbare Medien. Es können alternativ weitere computerlesbare Medien verwendet werden.
Im Betrieb werden die XML-Dokument-Enkodierungs/Dekodierungs-Funktionen auf einem aus dem Server-Computer 850 oder dem Computersystem 800 durchgeführt, und der somit ausgebildete paketierte Bitstrom wird über das Kommunikationsnetzwerk 820 jeweils zum Empfang und Dekodieren durch das Computersystem 800 oder den Server-Computer 850 übertragen, wenn dies notwendig ist. Auf diese Weise kann ein XML-Dokument einfach zwischen zwei Orten auf eine wirksame Weise kommuniziert werden, während eine optimale Zeit am Empfänger ermöglicht wird, um das Dokument fliegend zu dekodieren, wenn es empfangen wird, ohne eine Notwendigkeit dazu, das gesamte Dokument zuerst zu empfangen.
Die Verfahren zum Enkodieren und Dekodieren können abwechselnd zum Teil oder insgesamt durch eine zugehörige Hardware implementiert werden, wie beispielsweise eine oder mehrere integrierte Schaltungen, welche die Funktionen oder Sub-Funktionen einer Enkodierung und/oder Dekodierung durchführen. Eine solche zugehörige Hardware kann Grafikprozessoren, digitale Signalprozessoren und einen oder mehrere Mikroprozessoren und zugehörige Speicher enthalten.
Enkodierung und Komprimierung von XML
Trennung von Struktur und Text
Herkömmlicherweise werden XML-Dokumente hauptsächlich in ihrem Rohtextformat gespeichert und übertragen. Bei einigen Anwendungen werden XML-Dokumente unter Verwendung bestimmter herkömmlicher Textkomprimierungsalgorithmen zur Speicherung oder Übertragung komprimiert und in XML zurück dekomprimiert, bevor sie analysiert und verarbeitet werden.
Gemäß der vorliegenden Offenbarung liegt ein weiterer Weg zum Enkodieren eines XML-Dokuments in der Enkodierung der Baum-Hierarchie des Dokuments (wie beispielsweise die DOM-Darstellung des Dokuments). Die Enkodierung kann auf eine Erst-Breite (engl. breadth-first) oder Erst-Tiefe Weise (depth-first) Weise durchgeführt werden. Um die Komprimierung und Dekodierung wirksamer zu gestalten, kann die XML-Struktur, welche durch Kennzeichen innerhalb des XML-Dokuments gekennzeichnet ist, vom Text des XML-Dokuments getrennt und enkodiert werden. Wenn das enkodierte Dokument übertragen wird, können die Struktur und der Text in separate Ströme oder zu einem einzelnen Strom verknüpft gesendet werden.
Wie in 1 zu erkennen, und gemäß der vorliegenden Ausführungsform, enthält eine Baumdarstellung 102 eines XML-Dokuments 104, welches typischerweise vom Speicher erhältlich ist, eine Anzahl von Knoten 116 und wird auf eine Erst-Tiefe Weise enkodiert. Der Aufbau des Dokuments 104 und des Textes, welcher darin enthalten ist, kann, wie gezeigt, jeweils als zwei getrennte Ströme 106 und 108 enkodiert werden oder zu einem einzelnen Strom verknüpft werden. Der Strukturstrom 106 wird durch die Kodetabellen 110 und 114 angeführt. Die enkodierten Knoten 118 des Baums 102 haben jeweils ein Größenfeld (nicht dargestellt), welches die Größe des Knotens anzeigt und die Gesamtgröße ihrer nachkommenden Knoten enthält. Einige der enkodierten Blattknoten 118 enthalten Verbindungen 112, welche jene Blattknoten mit ihrem entsprechenden enkodierten Inhalt im Textstrom 108 verbinden. Jede enkodierte Zeichenfolge im Textstrom 108 wird durch ein Größenfeld (nicht dargestellt) vorangeführt, welches die Größe der Zeichenfolge anzeigt. Wenn zu einem einzelnen Strom verknüpft, sollten Pakete, welche die Wurzel der Verbindungen 112 enthalten, jenen Paketen vorangehen, welche den Text enthalten, auf welchem durch die Verbindungen 112 gezeigt wird, wobei sichergestellt wird, dass die Struktur-Komponente des Dokuments 104 durch den Dekoder vor der entsprechenden Text (Inhalt)-Komponente empfangen wird.
Diese in 1 angezeigte Annäherung ist ebenfalls in 9 als ein Flussdiagramm eines Enkodierungsverfahrens 900 angezeigt, welches als ein Softwareprogramm implementiert werden kann, welches auf dem Computersystem 800 läuft. Das Verfahren 900 kommuniziert zumindest einen Teil von einer Struktur eines Dokuments, welches durch eine hierarchische Darstellung beschrieben wird, und hat einen Eingangsschritt 902. Anfangs identifiziert das Verfahren 900 bei Schritt 904 die hierarchische Darstellung (beispielsweise die Baumstruktur) des Dokuments 104. Die Identifikation wird vorzugsweise durch die XML-Kennzeichen durchgeführt, wie oben erwähnt. Dadurch wird die Darstellung bei Schritt 906 in eine Mehrzahl von Datenpaketen paketiert. Bei Schritt 908 wird zumindest eine Verbindung zwischen einem Paar der Pakete erzeugt. Die Verbindung wirkt zur Darstellung einer Zwischenverbindung zwischen entsprechenden Komponenten (beispielsweise Struktur und Inhalt) von der Darstellung. In Schritt 910 werden die Pakete zu einem Strom zur Kommunikation ausgebildet. Die Verbindungen behalten die hierarchische Darstellung innerhalb der Pakete bei. Das Verfahren 900 endet bei Schritt 912.
Im Allgemeinen ist das Volumen einer Strukturinformation viel kleiner als jenes des Textinhaltes. Strukturen werden für gewöhnlich innerhalb eines Dokumentenfalles verschachtelt und wiederholt. Ein Trennen der Struktur vom Text erlaubt, dass jegliche wiederholende Muster leichter durch den Komprimierungsalgorithmus identifiziert werden, welcher typischerweise den Eingangsstrom durch ein Fenster mit festgelegter Größe untersucht. Zusätzlich haben der Struktur- und der Text-Strom ziemlich unterschiedliche Charakteristiken. Somit können unterschiedliche und wirksamere Enkodierungsverfahren auf sowohl die Struktur als auch den Text angewendet werden.
Die Struktur ist entscheidend beim Bereitstellen des Kontextes zum Interpretieren des Textes. Ein Trennen einer Struktur und eines Textes in einem Enkoder erlaubt es dem entsprechenden Dekoder, die Struktur des Dokuments schneller zu analysieren, wodurch lediglich die relevanten Elemente verarbeitet werden, während Elemente (und Nachfolgende) ignoriert werden, welche er nicht kennt oder erfordert. Der Dekoder kann es sogar auswählen, nicht den Text zu Puffern, welcher mit irgendwelchen irrelevanten Elementen in Zusammenhang steht. Ob der Dekoder das enkodierte Dokument zurück in XML konvertiert oder nicht, hängt von der bestimmten durchzuführenden Anwendung ab (siehe die Diskussion im Folgenden über Anwendungsprogramm-Schnittstellen – APIs).
Kodetabellen
Die Elemente einer Dokumentenbeschreibung und ihre Attribute sind in DTDs oder Schemata bestimmt. Typischerweise wird ein Satz von Elementen und ihren zugehörigen Attributen in einem Dokumentenfall wiederholt verwendet. Es können Elementennamen als auch Attributnamen und Werten Kodes zugewiesen werden, um die Anzahl von Bytes zu reduzieren, welche erforderlich sind, um sie zu enkodieren.
Typischerweise verwendet jede Anwendungsdomäne einen unterschiedlichen Satz von Elementen und Typen, welche in einer Nummer oder in Schemata und/oder DTDs bestimmt sind. Zusätzlich kann jedes Schema oder DTD Definitionen für einen unterschiedlichen Namensraum enthalten. Sogar wenn einige der Elemente und Typen auf mehrere Klassen von Anwendungen üblich sind, werden sie für gewöhnlich in einem unterschiedlichen Muster verwendet. Das heißt, dass ein Element X, welches in beiden Domänen A und B üblich ist, häufig in Domäne A, jedoch spärlich in Domäne B verwendet werden kann. Zusätzlich werden bestehende Schemata aktualisiert und es werden neue Schemata ständig erzeugt. Somit ist es am besten, die Kodezuweisung jenen Gesellschaften zu überlassen, welche eine Interoperabilität in ihren Domains überblicken.
Beispielsweise sind MPEG-7-Beschreibungen XML-Dokumente. MPEG kann die Koderäume für seine eigenen Deskriptoren und Beschreibungs-Schemata, als auch externe Elemente und Typen, welche durch sie verwendet werden, bestimmen. MPEG kann ebenfalls ein Verfahren zum Erzeugen von Koderäumen bestimmen. Idealerweise sollte das Verfahren auf Entropie basieren – das heißt auf der Anzahl von Auftritten der Deskriptoren und Beschreibungs-Schemata in einer Beschreibung oder einer Klasse von Beschreibung basieren (siehe die Sektion über die Erzeugung von Koderäumen).
Trennen von einem Element und Attributen
Ein XML-Kennzeichen enthält typischerweise einen Elementnamen und einen Satz von Attributnamen/Werten-Paaren. Möglicherweise kann ein großer Satz von Attributen mit einem Elementfall spezifiziert werden. Somit wird es ein Trennen eines Elementnamens von den Attributen dem Dokumentenbaum erlauben, analysiert zu werden, und dass Elemente schneller lokalisiert werden. Zusätzlich neigen einige Attribute oder Attribut Name/Wert-Paare dazu, viel häufiger als die anderen verwendet zu werden. Ein Gruppieren eines Attributnamens, des Wertes und von Name/Wert-Paaren in unterschiedliche Sektionen führt für gewöhnlich zu einer besseren Komprimierung.
Enkodieren von Werten von eingebauten Datentypen und speziellen Typen
Der Enkoder arbeitet zum Enkodieren der Werte von Attributen und Elementen von eingebauten (oder vorgegebenen) Datentypen in wirksamere Darstellungen gemäß ihrer Typen. Wenn das Schema, welches die Typeninformation enthält, nicht verfügbar ist, werden die Werte als Zeichenfolgen behandelt.
Zusätzlich, wenn ein Wert (beispielsweise ein Einzel-Digit Integer) wirksamer als eine Zeichenfolge dargestellt wird, kann es der Enkoder ebenfalls wählen, ihn als eine Zeichenfolge zu behandeln und ihn nicht zu enkodieren. Durch eine Vorgabe werden Zeichenfolgen als eine Universal Text Format (UTF-8) Zeichenfolge enkodiert, welches einen standardisierten und wirksamen Weg zum Enkodieren einer Zeichenfolge von Mehrfach-Byte-Zeichen bereitstellt.
Zusätzlich enthält die UTF-Zeichenfolge eine Längeninformation, welches das Problem vermeidet, einen geeigneten Begrenzer zu finden, und es ermöglicht, einfach zum Ende der Zeichenfolge zu überspringen.
Es können spezielle Typ-Enkoder für spezielle Datentypen verwendet werden. Diese speziellen Typ-Enkoder können unter Verwendung der setTypeEnkoder () Schnittstelle der Enkoder API (wie im Folgenden diskutiert) spezifiziert werden. Eine Information über die speziellen Typ-Enkoder wird vorzugsweise im Header des Struktursegments, vorzugsweise als eine Tabelle vom Typ von Enkoder-Kennungen gespeichert. Ferner können die Vorgabe-Typ-Enkoder (für die eingebauten Datentypen) unter Verwendung dergleichen Mechanismen überwunden werden. Somit, wenn ein bestimmter eingebauter Datentyp für gewöhnlich unter Verwendung eines Vorgabe-Enkoders enkodiert wird, kann ein spezieller Enkoder alternativ verwendet werden, so dass eine Identifikation innerhalb des Bitstroms benötigt wird, dass ein alternativer Dekodierungsprozess für eine korrekte Reproduktion des XML-Dokuments erforderlich sein wird. Jeder enkodierte Wert wird durch die Kennung des Typ-Enkoders vorangegangen, welcher zum Enkodieren des Wertes verwendet wurde.
Auf diese Weise kann ein XML-Dokument-Enkoder, welcher gemäß der vorliegenden Offenbarung implementiert ist, eine Anzahl von Enkodierungsformaten für unterschiedliche Typen einer Struktur und eines Textes innerhalb des XML-Dokumentes enthalten. Es können bestimmte Enkodierungsformate eingebaut oder vorgegeben sein, oder für bekannte oder für gewöhnlich widergespiegelte Datentypen verwendet werden. Spezielle Typ-Enkoder können für jegliche spezielle Datentypen verwendet werden. In solchen Fällen kann eine Identifikation des bestimmten Typ-Enkoders/der Typ-Enkoder, welcher/welche beim Enkodierungsprozess verwendet wird/werden, im Header eines Pakets enthalten sein, wodurch es dem Dekoder ermöglicht wird, jene Dekodierungsprozesse zu identifizieren, welche zur Verwendung für die enkodierten Typen im enkodierten Dokument erforderlich sind. Wenn geeignet, können die bestimmen Typ-Enkoder von einem Computernetzwerk über einen Uniform Resource Indicator (URI) zugreifbar sein. Wenn der Dekoder nicht dazu in der Lage ist, einen Dekodierungsprozess entsprechend einem enkodierten Typ, welcher innerhalb eines Paketes im enkodierten Dokument widergespiegelt wird, zuzugreifen oder zu implementieren, kann eine Vorgabe-Antwort dergestalt sein, diese enkodierten Daten zu ignorieren, welches möglicherweise zu der Reproduktion von Null-Daten (beispielsweise eine leere Anzeige) führt. Eine Alternative liegt darin, dass der Dekoder dazu arbeiten kann, den speziellen Typ-Dekoder von einem verbundenen Netzwerk zu ergreifen, beispielsweise unter Verwendung einer URI, welche die enkodierten Daten begleiten kann. Die URI eines Enkoder/Dekoder-Formats kann in der oben erwähnten Tabelle enthalten sein, und dadurch im Bitstrom enthalten sein (siehe Anhang).
In einer weiteren Erweiterung dieser Annäherung können mehrere Enkodierungs-Formate für einen einzelnen Datentyp verwendet werden. Beispielsweise können Text-Zeichenfolgen unterschiedlich basierend auf der Länge der Zeichenfolge enkodiert werden, wobei dieses einen Kompromiss zwischen der Zeit, welche zur Durchführung eines Dekodierungsprozesses genommen wird, und dem Komprimierungspegel, welcher erlangt werden soll, darstellt. Beispielsweise können Text-Zeichenfolgen mit 0–9 Zeichen enkodiert werden, wohingegen Zeichenfolgen mit 10–99 und 100–999 Zeichen mit jeweiligen (unterschiedlichen) Enkodierungsformaten enkodiert werden können. Ferner kann ein oder können mehrere jener Enkodierungsformate für einen speziellen Datentyp sein. Somit kann der Enkoder, wenn Text-Zeichenfolgen in diesem Beispiel enkodiert werden, in der Praxis keine Enkodierung für 0–9 Zeichen-Zeichenfolgen, der Vorgabe-Enkoder keine für 10–99 Zeichen-Zeichenfolgen, und der spezielle Enkoder keine für eine Zeichenfolge verwenden, welche mehr als 100 Text-Zeichen hat.
10 zeigt ein Beispiel eines Verfahrens 1000 zum Enkodieren eines XML-Dokuments, welches einen Eingangspunkt eines Schrittes 1102 hat. Anfangs untersucht das Verfahren 1000 bei Schritt 1004 das XML-Dokument 104, um jeden Datentyp zu identifizieren, welcher ein Teil des XML-Dokuments 104 ausbildet. Bei Schritt 1006 arbeitet das Verfahren 1000 zur Identifikation eines ersten Satzes der Datentypen, für welche ein entsprechend spezielles Enkodierungsformat verfügbar ist. Nachdem die speziellen Datentypen identifiziert sind, enkodiert Schritt 1008 jedes Teil des XML-Dokuments, welches einen Datentyp im ersten Satz hat, mit dem entsprechenden speziellen Enkodierungsformat. Als Nächstes enkodiert das Verfahren 1000 in Schritt 1010 jeden verbleibenden Teil des XML-Dokuments mit einem vorgegebenen Enkodierungsformat, welches dem Datentyp des verbleibenden Teils entspricht. In Schritt 1012 wird eine Darstellung von der Information ausgebildet, welche zumindest auf jeden der Datentypen in dem ersten Satz mit dem entsprechenden speziellen Enkodierungsformat Bezug nimmt. In Schritt 1014 steht die Darstellung mit den enkodierten Teilen als eine enkodierte Form des XML-Dokuments 104 in Zusammenhang. Das Verfahren 1000 endet dann bei Schritt 1016.
Das Struktur-Segment (oder Struktur-Strom)
2 zeigt die verschiedenen Sektionen des Struktursegments (oder -stroms) 106. Das Struktursegment beginnt mit einem Header 202, und sein Hauptbereich wird in eine Anzahl von Sektionen 204 aufgeteilt. Der Header 202 identifiziert die Version des XML und jene des Enkodierungsformats.
Jede Sektion 204 in dem Hauptbereich beginnt mit einer eindeutigen Signatur, welche den Sektionstyp anzeigt. Somit ist es nicht notwendig, dass die verschiedenen Sektionen in einer bestimmten Reihenfolge angeordnet werden.
Nichtsdestotrotz wird in der folgenden Beschreibung angenommen, dass die Sektionen in der in 2 gezeigten Reihenfolge angeordnet sind. Die Sektion-Signatur wird durch ein Größenfeld gefolgt, welches die Größe der Sektion anzeigt.
Eine ID-Tabelle-Sektion 6 erlaubt es, dass Elemente mit IDs in einer Dokumenthierarchiesektion 208 schnell lokalisiert werden. Die ID-Tabelle 206 kann einem enkodierten Dokument abwesend sein, sogar wenn das Dokument Elemente mit IDs hat. Dies liegt daran, weil die DTDs oder das Schema, welches die ID-Definition enthält, zum Zeitpunkt des Enkodierens nicht verfügbar sein können.
Es wird vorzugsweise eine Sektion 210 für die Dokumenttypdeklaration und die interne (DTD) Teilmenge reserviert. Für XML-Schemata basierte Dokumente, beispielsweise MPEG-7-Beschreibungen, wird diese Sektion 210 nicht vorliegen.
Es gibt Sektionen für die Kodetabellen für Namensräume 212, Elementnamen 214, Attributnamen 216 und Attributwerte 218. Im Folgenden werden diese Kodetabellen als lokale Kodetabellen bezeichnet, um sie von jeglichen Kodetabellen zu unterscheiden, welche für sowohl den Enkoder als auch den Dekoder vorbestimmt sind, und nicht im Bitstrom befördert werden. Beispielsweise kann es vorbestimmte Kodetabellen für MPEG-7 oder ein XML-Schema geben.
Den lokalen Kodetabellen folgt für gewöhnlich eine Sektion, welche eine Tabelle von Attribut Name/Wert-Paaren 220 enthält, welche eine Verwendung der Kodes macht, welche in den lokalen Kodetabellen als auch in irgendwelchen vorbestimmten Kodetabellen bestimmt sind.
Die Dokumenthierarchiesektion 208 ist die enkodierte Baumstruktur des XML-Dokuments, welches Kode von den lokalen und vorbestimmten Kodetabellen verwendet.
Abgesehen von der Verwendung von Kodetabellen und Typ-Enkodern zum Enkodieren, komprimiert der Enkoder ebenfalls jede Sektion unter Verwendung eines Komprimierers. Anstelle der unabhängigen Komprimierung von jeder Sektion des Hauptbereichs des Struktursegments 106, kann der Hauptbereich des Struktursegments zusammen komprimiert werden. Dies kann tatsächlich zu einem besseren Komprimierungsverhältnis aufgrund eines geringeren Overheads und der hohen Anzahl von Daten führen. Jedoch erfordert eine solche Komprimierung etwas zur Dekomprimierung des gesamten Struktur-Hauptkörpers, um herauszufinden, ob ein Dokument ein bestimmtes Element enthält. Beide Annäherungen können getestet werden, um zu bestimmen, welche in der Praxis besser arbeitet. Nichtsdestotrotz, wenn eine Sektion klein ist, kann eine Komprimierung nicht wirksam sein, und der Enkoder kann es wählen, die Sektion nicht zu komprimieren. Jede Sektion hat ein komprimiertes Kennzeichen, um zu signalisieren, ob die Komprimierung angewendet wurde. Wenn die Komprimierung angewendet wurde, zeigt das Größenfeld zu Beginn von jeder Sektion die komprimierte (anstelle die unkomprimierte) Größe der Sektion in Bytes an.
Möglicherweise kann ein unterschiedlicher Komprimierer für jede Sektion verwendet werden, wobei die Charakteristiken der Daten in jeder Sektion in Betracht gezogen werden. Eine Information über die verwendeten Komprimierer wird im Header bereitgestellt. Die Vorgabe ist es, ZLIB zur Komprimierung aller Sektionen im Struktursegment als auch im Textsegment zu verwenden. Der ZLIB-Algorithmus erzeugt einen Header und eine Prüfsumme, welche es erlauben, dass die Intaktheit der komprimierten Daten am Dekoderende verifiziert wird.
Textsegment (oder Textstrom)
Das Textsegment 108 beginnt mit einer Textsegment-Signatur, gefolgt durch ein Größenfeld, welches die Größe des enkodierten Textes anzeigt. Das Textsegment enthält eine Sequenz aus UTF-8-Zeichenfolgen, welche der Text der Elemente sind.
Die Enkoder- und Dekoder-Modelle
Das Enkoder-Modell
3 zeigt ein XML-Enkoder-Modell 300, welches einen Enkoder 302 zum Enkodieren des XML-Dokuments 104 in einen Bitstrom 306 zur Speicherung oder Übertragung enthält. Das Enkoder-Modell 300 kann als ein Softwareprogramm oder als Teilprogramme, welche mit dem Computermodul 801 arbeiten, implementiert sein, wobei das Programm typischerweise in dem HDD 810 gesteuert wird und durch den Prozessor 805 ausgelesen und in seiner Ausführung gesteuert wird. Der Bitstrom 306 kann nach einer Erzeugung über die I/O-Schnittstelle 808 und das Netzwerk 820 zur komplementären Dekodierung und Reproduktion durch den Server-Computer 850 übertragen werden. Alternativ kann der Bitstrom 306 in dem HDD 810 oder als eine CD-ROM in dem Laufwerk 812 zur nachfolgenden Reproduktion gespeichert sein. Der Enkoder 302 kann eine Applikationsprogramm-Schnittstelle (API) 308 (beispielsweise die DOM API) unterstützen, so dass der Dokumentbaum 102 als ein Baum 102, welcher erzeugt wird, enkodiert werden kann. Eine Standard-Bibliothek 310 (für XML) wird dazu verwendet, um Kodetabellen 312, Enkoder 314 für eingebaute Datentypen, und Vorgabe-Komprimierer 316, welche in dem Enkodierungsprozess verwendet werden können, bereitzustellen.
Domainspezifische Bibliotheken 318 können ebenfalls für verschiedene Domänen bestimmt werden. Jede domänenspezifische Bibliothek 318 kann Kodetabellen 320 für die bestimmte Domäne und Enkoder 322 für bestimmte Datentypen enthalten. Eine Applikation kann ebenfalls spezifische Module 324 bereitstellen, welche applikationsspezifische Enkoder 326 für spezielle Datentypen, wie oben diskutiert, und entsprechende Komprimierer 328 enthalten. Jedoch müssen diese Typ-Enkoder 326 und Komprimierer 328 entweder herunterladbar und plattformunabhängig oder zuvor am Dekoderende installiert sein. Eine Anwendung kann dem Enkoder 326 ebenfalls anweisen, seine zuvor bestimmten Kodetabellen 330 zu verwenden. Die Kodetabellen 330 können im Bitstrom 306 enthalten oder zuvor am Dekoderende installiert sein. Jeder der einzelnen Enkoder und Komprimierer, wie in 3 gezeigt, können durch Software (Teil-) Programme oder in einigen Fällen durch Spezialzweck-Hardware (beispielsweise zur schnellen Enkodierung) implementiert sein.
Das Dekoder-Modell
4 zeigt ein komplementäres XML-Dekoder-Modell 400, welches einen Dekoder 402 zur Dekodierung des XML-Bitstroms 306 zur Ausgabe eines XML-Dokuments 104 enthält. Alternativ kann der Dekoder eine API 408 (beispielsweise das SAX („einfache API für XML") oder DOM API) unterstützen, welche es erlaubt, dass eine Anwendung ihr eigenes internes Modell des Dokumentenbaums 102 aufbaut. Dies bewahrt den Dekoder 402 vor der Ausgabe des XML-Dokuments 104, und die Anwendung vor einer Voranalyse des rekonstruierten XML-Dokuments 104. In beiden Fällen verwendet der Dekoder 402 die Standard-Bibliothek 410, irgendwelche domainspezifische Bibliotheken 418, als auch irgendwelche zuvor installierte oder heruntergeladene applikationsspezifische Module 424 (welche durch den Enkoder verwendet werden), wenn der XML-Bitstrom 306 dekodiert wird. In 4 sind Elemente des Dekoder- Modells 400 auf eine ähnliche Weise zu der von 3 nummeriert, so dass, wenn eine Differenz von 100 in der Nummerierung vorliegt, die Elemente entsprechend ähnliche Funktionen haben. Das Dekoder-Modell 400 kann beispielsweise innerhalb des Computer-Moduls 801 implementiert sein, um den Bitstrom 306 zu dekodieren, welcher über das Netzwerk 820 vom Server-Computer 850 empfangen wird. Alternativ kann das Dekoder-Modell 400 dazu arbeiten, einen Bitstrom zu dekodieren, welcher beispielsweise von der CD-ROM erlangt wird. Wie beim Enkoder 302 können Software- und Hardware-Dekodierungsprozesse innerhalb des Dekoders 402 verwendet werden.
In den meisten Fällen braucht der Dekoder 402 am Clientende nicht das dekodierte XML-Dokument 104 von 4 gegen seine DTDs oder Schemata zu validieren. Eine Validierung an der Clientseite ist teuer, unwirksam und höchstwahrscheinlich redundant. Der Dekoder 104 kann annehmen, dass die XML-Dokumente gegen ihre DTDs oder Schemata am Serverende validiert wurden. Ähnlich sollte der unterliegende Transport, als auch jeglicher Fehlererfassungsmechanismus, wie beispielsweise die Prüfsummen, welcher in das binäre Format gebaut ist, dazu in der Lage sein, jeglichen Übertragungsfehler zu ergreifen.
Lokalisation von Elementen
XML-Elemente können unter Verwendung von IDs oder XPath/XPointer-Fragmenten referenziert und lokalisiert werden. Wie zuvor erwähnt, erlaubt es die ID-Tabelle 206 des Struktursegments 106 den Elementen mit IDs, in der Dokumenthierarchiesektion 208 schnell lokalisiert zu werden. Jeglicher Text und Attribute, welche mit einem Element in Zusammenhang stehen, können dann unter Verwendung des Lokators in den enkodierten Elementen wirksam lokalisiert werden.
Im Folgenden sind einige Beispiele von XPath-Fragmenten angegeben, welche einem Uniform Resource Indicator (URI) angehängt werden können:
/doc/chapter[2]/section[3]
wählt die dritte Sektion des zweiten Kapitels des Dokuments aus
chapter[contains(string(title), "overview")]
wählt das Kapitel-Kind des Kontextknotens aus, welches ein oder mehrere Titelkinder hat, welche den Text „overview" enthalten.
child::*[self::appendix or self::index]
wählt den Anhang und das Index-Kind des Kontextknotens aus.
child::*[save::chapter or save::apendics] [position()=last()]
wählt das letzte Kapitel oder das Anhang-Kind des Kontextknotens aus.
para[@type="warning"]
wählt alle Para-Kinder des Kontextknotens aus, welcher einen Typ-Attribut mit dem Wert „warning" hat.
para[@id]
wählt alle Para-Kinder des Kontextknotens aus, welcher ein id-Attribut hat.
Ein XPath/XPointer-Fragment enthält eine Liste von Ortsschritten, welche den absoluten oder relativen Ort des erforderlichen Elements/der erforderlichen Elemente innerhalb eines XML-Dokuments darstellen. Typischerweise enthält das Fragment eine Liste von Elementnamen. Es können Prädikate und Funktionen verwendet werden, wie in dem Beispiel oben, um zusätzliche Auswahlkriterien zu spezifizieren, wie beispielsweise der Index eines Elements innerhalb eines Feldes, das Vorliegen von einem Attribut, der Abgleich eines Attributwertes und der Abgleich eines Textinhaltes.
Die Kompaktheit der enkodierten Dokumenthierarchie erlaubt es, dass es analysiert (und realisiert) wird, ohne in eine Vollobjekt-Baum-Darstellung expandiert zu werden. Die Fragmentadresse wird zunächst in eine enkodierte Form übersetzt. Eine der Konsequenzen eines solchen Übersetzungsprozesses liegt darin, dass er es jemandem erlaubt, unmittelbar zu bestimmen, ob das erforderliche Element/die erforderlichen Elemente tatsächlich im Dokument auftreten. Ein Abgleich der Komponenten der enkodierten Fragmentadresse ist ebenfalls viel effizienter als ein Abgleichen von Teil-Zeichenfolgen. Der Entwurf erlaubt es, dass einfache XPath/XPointer-Fragmente (welche am Häufigsten verwendet werden) schnell bewertet werden. Ein Durchsuchen der Dokumenthierarchie verengt zunächst ebenfalls größtenteils den Umfang von nachfolgenden Untersuchungsschritten im Falle einer komplexeren Fragmentadresse.
Paketieren des Bitstroms zum Streaming
Streaming XML
Herkömmlicherweise werden XML-Dokumente hauptsächlich in ihrem ursprünglichen Textformat gespeichert und übertragen. Bei einigen Anwendungen werden XML-Dokumente unter Verwendung einiger herkömmlicher Textkomprimierungsalgorithmen zur Speicherung oder Übertragung komprimiert, und in XML zurück dekomprimiert, bevor sie analysiert und verarbeitet werden. Obwohl eine Komprimierung größtenteils die Größe eines XML-Dokuments reduzieren kann, muss unter solchen Umständen eine Anwendung stets das gesamte XML-Dokument empfangen, bevor eine Analyse und Verarbeitung durchgeführt werden können.
Ein Streaming eines XML-Dokuments legt auf, dass ein Analysieren und Verarbeiten sobald beginnen können, wenn ein ausreichender Abschnitt des XML-Dokuments empfangen wird. Eine solche Fähigkeit wird zumeist im Falle einer Kommunikationsverbindung mit niedriger Bandbreite und/oder bei einer Vorrichtung mit sehr begrenzten Ressourcen hilfreich sein.
Weil ein herkömmlicher XML-Analysator erwartet, dass ein XML-Dokument gut ausgebildet ist (das heißt eine Übereinstimmung und nicht überlappende Start-Kennzeichen- und Ende-Kennzeichen-Paare hat), kann der Analysator lediglich den XML-Dokument-Baum auf eine Erst-Tiefe Weise analysieren und kann Teile des Dokuments nicht überspringen, bis der Inhalt des XML-Dokuments neu organisiert ist, um es zu unterstützen.
Paketierung des Bitstroms
Ein Enkodieren eines XML-Dokuments in ein vollständiges Struktursegment 106 und ein vollständiges Textsegment 108, wie zuvor beschrieben, wird größtenteils die Größe der Daten reduzieren, und gleichzeitig erlauben, dass ein bestimmter Übertragungsfehler erfasst wird. Nichtsdestotrotz hat der Dekoder 402 stets eine hohe Menge der enkodierten Daten zu empfangen, bevor er sie verarbeiten kann. Beispielsweise hat der Dekoder 402 die Kodetabellen 110 in ihrer Gesamtheit zu empfangen, bevor eine Analyse der Dokumenthierarchie eingeleitet werden kann. Zum gleichen Zeitpunkt hat der Dekoder 402 die Ankunft eines bestimmten Segments des Textsegments 108 abzuwarten, um den Text zu erlangen, welcher mit einem Knoten in Zusammenhang steht. Um es zu ermöglichen, dass eine Verarbeitung am Dekoderende sobald wie möglich beginnt, muss das XML-Dokument 104, wie in 5 zu sehen, stufenförmig enkodiert werden, welches es erlaubt, dass kleine Pakete 502 von enkodierten Daten 500 an den Dekoder 402 gesendet werden, wenn sie verfügbar werden. In 5 zeigen kreuzschraffierte Pakete 504 Strukturpakete an, und die Pakete 506 mit diagonalen Linien zeigen Textpakete an. Diesen Paketen geht ein Header-Paket 508 voraus, und sie werden durch ein Ausläufer-Paket 510 gefolgt. In der bevorzugten Anordnung hat jedes Datenpaket 502 die gleiche Struktur wie ein vollständiges Struktursegment 106 oder ein vollständiges Textsegment 108. Zur gleichen Zeit kann jedes Paket 502 von jenen Paketen 502 abhängig sein, welche vor ihm gesendet werden, oder, in einigen Anwendungen, von einer vorbestimmten Anzahl von Paketen, welche nach ihm gesendet werden. Eine solche vorbestimmte Anzahl kann dynamisch bestimmt werden.
Abgesehen von der Notwendigkeit zur Verarbeitung eines Dokuments während es geliefert wird, hat ein Enkoder/Dekoder typischerweise einen Ausgabe/Eingabe-Puffer einer festgelegten Größe. Demgemäß, abgesehen von sehr kurzen Dokumenten, hat der Enkoder 302 ein XML-Dokument stufenförmig in mehrere Pakete zu enkodieren. Jedes der Pakete 502 (welche 504, 506, 508 und 510 enthalten) wird durch einen Paket-Header angeführt. Der Paket-Header enthält eine Paketnummer, welche als eine Paket-ID verwendet wird, als auch zum Ordnen der Pakete und zum Erfassen irgendwelcher fehlenden Pakete. Der Paket-Header enthält ebenfalls ein Größenfeld, welches die Größe des Pakets 502 in Bytes anzeigt, und ein Typfeld, welches anzeigt, ob das Paket ein Strukturpaket 504, ein Textpaket 506, ein Header-Paket 508, ein Ausläufer-Paket 510 oder ein weiterer Typ von Paket 502, welches ein Befehlspaket genannt wird, welches in 5 nicht dargestellt ist, jedoch in diesem Dokument später beschrieben wird, ist.
Bei jedem Strukturpaket 504 enthält die darin enthaltene ID-Tabelle lediglich die IDs von jenen Elementen, welche im Paket enthalten sind. Seine Kodetabellen enthalten lediglich neue Kodes, welche nicht übertragen wurden. Kodes, welche übertragen wurden, werden nicht neu zugewiesen oder neu abgebildet. Die Vorgabe-Implementierung hängt lediglich einen neuen Wert an die Tabelle an und verwendet den Index (erweitert durch den Basisindex von der Tabelle) von den Einträgen als ihre Kodes. Ein leicht komplizierteres (jedoch kodewirksameres) Verfahren liegt im Zählen der Anzahl von Auftritten der Werte und bildet die Kodes neu ab, so dass Werte, welche häufiger vorkommen, auf kürzere Kodes, gerade bevor die Pakete ausgegeben werden, neu abgebildet werden. Wenn eine vorbestimmte Kodetabelle verwendet wird oder wenn die Neuabbildung nicht auf der Anzahl von Auftritten basiert, kann ein Sortieren der Werte vor einem Komprimieren zu einer besseren Komprimierungsrate führen. Es kann ein unterschiedlicher Algorithmus zum Zuweisen eines Kodes implementiert werden. Nichtsdestotrotz werden die Kodes, sobald ausgegeben, fixiert und können nicht auf andere Werte neu zugewiesen oder in nachfolgende Pakete neu abgebildet werden. Vorbestimmte Kodetabellen können ebenfalls unter Verwendung des UseCodeTable () Verfahrens der Enkoder-Schnittstelle spezifiziert werden, wie in dieser Beschreibung später beschrieben. Das Verfahren erlaubt es ebenfalls, zu spezifizieren, ob die vorbestimmte Kodetabelle mit den Daten in den Bitstrom zu enkodieren ist. Bei Kodetabellen von einer Anzahl von Namensräumen, welche auf XML (oder eine Anwendungsdomäne, wie beispielsweise MPEG-7) grundlegend sind, wird erwartet, dass sie auf alle XML (MPEG-7) Enkoder und Dekoder fest verdrahtet sind und nicht in den Bitstrom enkodiert werden müssen.
Wenn eine ID, ein Elementname, ein Attributname oder ein Attributwert länger als eine vorbestimmte Länge ist, wird er in ein Textpaket und einen Zeichenketten-Lokator enkodiert, anstelle dass die aktuelle Zeichenfolge in den Tabellen erscheinen wird.
Die Dokumenthierarchiesektion von einem Strukturpaket enthält eine Sequenz von Knoten. Jeder Knoten hat ein Größenfeld, welches seine (enkodierte) Größe in Bytes anzeigt, inklusive der Gesamtgröße seiner nachkommenden Knoten, welches im Paket enkodiert ist. Der Knoten kann ein Elementknoten, ein Bemerkungsknoten, ein Textknoten oder ein Knotenlokator sein. Jeder Knoten hat ein Knotentypfeld, welches seinen Typ anzeigt.
Die Dokumenthierarchie kann enthalten:

(i) einen kompletten Dokumentenbaum: Dies ist lediglich für ein sehr kurzes Dokument möglich;
(ii) einen vollständigen Unterbaum: Der Unterbaum ist das Kind von einem weiteren Knoten, welcher in einem früheren Paket enkodiert ist; und
(iii) einen unvollständigen Unterbaum: Der Unterbaum ist unvollständig, weil der gesamte Unterbaum nicht in ein Paket aufgrund von Zeit und/oder Größenbeschränkungen enkodiert werden kann.

Es werden Knoten-Lokatoren auf die in 6A gezeigte Weise für eine Baumstruktur 622 verwendet, welche unvollständige Unterbäume 602 und 604 hat, um die fehlenden Knoten und die Nachkommen der unvollständigen Unterbäume zu lokalisieren. In dieser Hinsicht und mit Bezug auf das frühere Beispiel, obwohl die hierarchische Baumdarstellung 102 des Dokuments 104 bekannt ist, wenn eine Enkodierung stattfindet, werden beim Dekodieren der kommunizierten Pakete lediglich Abschnitte der Baumdarstellung 102 typischerweise verfügbar gemacht. Wenn mehrere Pakete empfangen werden, kann der Baum neu aufgebaut werden. Beispielsweise in dem in 6B gezeigten Datenstrom, enthält ein Paket 620 (welches das #2 Paket in dem Datenstrom in diesem Beispiel ist) einen Teil der Baumstruktur 622 von einem Dokument, wobei diese Struktur die Knoten A, B1, B2 und B3 enthält. Jedoch ist in diesem Beispiel die Größe des Pakets 620 unzureichend, um die gesamte Baumstruktur 622 zu beschreiben und weitere Knoten, wie beispielsweise B4 und D1 unterzubringen. Die Knoten-Lokatoren 608 und 606 sind somit jeweils in den Beschreibungen der entsprechenden Eltern-Knoten (jeweils B3 und B2) enthalten und enthalten die jeweiligen Paketnummern 610 und 612 von einem Strukturpaket, welches eine Sequenz von fehlenden Knoten und ihren Unterbäumen enthält. Somit, beim Empfang der Sequenz von in 6B dargestellten Paketen, kann ein Teil des Baumes 622 beim Empfang des Pakets (#2) 620 neu aufgebaut werden, und der Zweig, welcher Knoten D1 enthält, kann beim Empfang von Paket (#7) 610 neu aufgebaut werden, und die Balance des Baumes kann beim Empfang von Paket (#20) 612 neu aufgebaut werden.
Jeder Elementknoten enthält vorzugsweise einen Namensraum-Kode, einen Element (Namen) Kode, und, wenn das Element Attribute hat, den Byte-Versatz des ersten Attributs in der Attribut Name/Wert-Paar Tabelle und die Anzahl von Attributen.
Jeder Textknoten oder Bemerkungs-Knoten enthält typischerweise einen Text-Lokator anstelle des aktuellen Textes. Der Text-Lokator spezifiziert die Paketnummer von einem Textpaket und einen Byte-Versatz im Textpaket.
In einigen Fällen kann eine Zeichenfolge die maximale Größe eines Paketes überschreiten. Wenn dies auftritt, wird die Zeichenfolge als Fragmente über mehrere Textpakete gespeichert, wie in 7 gezeigt. Jedes Textpaket 702 hat ein Kennzeichen 704, welches anzeigt, ob es eine Liste von UTF-8 enkodierten Zeichenfolgen und Zeichenfolgen-Lokatoren oder ein Zeichenfolgen-Fragment enthält. Im Falle eines Zeichenfolgen-Fragmentes ist die Paketnummer des nächsten Fragmentes ebenfalls enthalten. Wenn ein Textpaket das letzte (oder das einzige) Fragment von einer Zeichenfolge enthält, wird die Paketnummer für das nächste Fragment auf Null eingestellt, wie gezeigt.
Befehle zum Aufbauen eines Dokumentenbaums
Ein XML-Dokument kann zum Streaming an den Empfänger paketiert werden, wenn es enkodiert oder sogar erzeugt wird (gemäß eines vorbestimmten DTD oder Schemas). In diesem Fall ist das XML-Dokument typischerweise in Echtzeit unter Verwendung einer API, wie beispielsweise eine DOM API, aufgebaut. Anstelle einer Analyse von einer XML-Datei arbeitet der Enkoder 302 zum Aufbau des Bitstroms 306, direkt von der Speicherdarstellung. Es werden Knoten und Unterbäume, welche unter Verwendung der API eingesetzt und angehängt werden, als (binäre) Befehlspakete enkodiert, um die Speicherdarstellung am Dekoderende zu modifizieren. Die Paketnummer stellt sicher, dass die Befehlspakete in der richtigen Sequenz ausgeführt werden.
Da die übertragenen Knoten Teile des gleichen Dokuments (welches einem vorbestimmten DTD oder Schema entspricht) sind, und das Dokument online und in Synchronisation über die gesamte Zeit zwischen dem Enkoder 302 und Dekoder 402 ist, sollte keinerlei Konsistenz-Anliegen in Relation zum Inhalt der Knoten vorliegen. In einigen Darstellungen hat eine bestimmte Information lediglich eine temporäre Relevanz. Das heißt, dass eine bestimmte Information lediglich innerhalb einer bestimmten Zeitperiode während der Darstellung relevant ist. Informationseinheiten (beispielsweise der Spielstand eines Fußballspiels), welche auf zwei unterschiedliche Zeitinstanzen der Darstellung relevant sind, können selber inkonsistent sein. Ein Darstellung-Beschreibung Schema ist wünschenswert, um das Zeit- und Synchronisations-Modell von einer Darstellung aufzubauen. Die Zeitsteuerung von irgendeinem Medienobjekt, welches XML-Daten enthält, kann durch eine Startzeit und eine Dauer angezeigt werden. Ein solches Darstellung Enkoder/Dekoder-Paar wird typischerweise einen XML Enkoder/Dekoder, wie oben beschrieben, enthalten, welcher intern angeordnet ist. Der Darstellungs-Dekoder, anstelle des XML-Dekoders, arbeitet zur Interpretation der Startzeit- und Dauer-Attribute. Der Darstellungs-Enkoder entscheidet ebenfalls, ob ein XML-Unterbaum, welcher nicht länger relevant ist, vom Speicher zu entfernen ist oder nicht. Solange der XML Enkoder/Dekoder betrachtet wird, gibt es kein Konsistenz-Anliegen. Wenn der Generator stets erforderlich ist, um ein gültiges Dokument (Fragmente) zu erzeugen, dann gibt es keine Notwendigkeit für einen Befehl, um Knoten oder Unterbäume zu entfernen (möglicherweise inkonsistent oder ungültig). Das heißt, dass lediglich Einsetz- und Anhang-Befehle benötigt werden.
Ein Befehlspaket enthält den Pfad des (die Wurzel des) Unterbaums, welcher anzuhängen oder einzusetzen ist, und die Paketnummer des Strukturpakets, welches den Unterbaum enthält. Beispielsweise, zurückkehrend auf 6B, wenn der Lokator 608 für Knoten B4 nicht dazu in der Lage ist, in das Paket 620 untergebracht zu werden, dann ist ein Befehlspaket zwischen Pakete #2 und #20 einzusetzen, welches Knoten B4 wirksam an Knoten A anhängt. Dieses Befehlspaket wird dann einen Lokator enthalten, welcher auf das Paket 612 zeigt, welches die durch Knoten B4 definierte Struktur enthält.
Die Definition des Bitstroms
Der Bitstrom 306 ist vorzugsweise in der Extended Backus-Naur Form (ENBF) auf die im Anhang definierte Weise definiert. Zeichen sind durch ein einfaches Anführungszeichen eingeschlossen, und Zeichenfolgen sind durch doppelte Anführungszeichen eingeschlossen. Wenn nicht anders angegeben, werden UCS-Zeichen in UTF-8 Enkodierung und UTF-Zeichenfolgen (welche eine Längeninformation enthalten) angenommen.
API
API für Dokumente und Schemata
Es ist für den Dekoder 402 nicht immer notwendig, ein enkodiertes Dokument zurück in XML zu konvertieren. Wie oben angegeben, kann der Dekoder 402 eine API, wie beispielsweise die SAX API, die DOM API oder eine weitere proprietäre API, unterstützen, um es einer Anwendung zu ermöglichen, direkt auf den dekodierten Inhalt zuzugreifen. Dies bewahrt den Dekoder 402 davor, das XML-Dokument neu aufzubauen und auszugeben, und die Anwendung davor, das neu aufgebaute XML-Dokument neu zu analysieren.
Eine Anwendung kann ebenfalls auf eine in Schemata gespeicherte Information zugreifen, da Schemata ebenfalls XML-Dokumente sind, können sie auf die gleiche Weise enkodiert werden. Ein Verwenden einer bestehende SAX oder DOM API zum Zugreifen und Interpretieren von Schema-Definitionen ist extrem langwierig. Ein Analysator, welcher eine Schema API unterstützt, wie beispielsweise die Schema API, welche in Wan W., Andersen M., Lennon A., Description Object Model (DesOM). DOC. ISO/IEC JTC1/SC29/WG11 MPEG00/M5817, Noordwijkerhout, März 2000, definiert ist, wird ein Zugreifen auf die Definitionen von Schemata viel einfacher gestalten.
Um es zu ermöglichen, dass die Werte von eingebauten Datentypen und speziellen Typen wirksam enkodiert werden, muss ein Enkoder dazu in der Lage sein, eine Typinformation von den Schemata zu erlangen. Somit ist die Schema API ebenfalls für den Enkoder 302 sehr wichtig.
API für Enkoder
Das im Folgenden vorgeschlagene Binärformat erlaubt die Implementierung von Enkodern von verschiedenen Fähigkeiten und Komplexität. Die in diesem Abschnitt beschriebenen Schnittstellen erlauben es, einen Basis-Enkoder aufzubauen, welcher erweitert werden kann, um die komplizierteren Merkmale bereitzustellen, welche durch das Enkodierungsschema unterstützt werden.
Enkoder-Schnittstelle

void SetMaxPacketSize (in unsignierter langer maxPacketSize) stellt die maximale Paketgröße in Bytes ein.
void SetMaxPrivateDataSize (in unsignierter langer maxPrivateDataSize) stellt die maximale Größe der privaten Daten in Byte ein. Es ist zu erwähnen, dass die Menge von privaten Daten, welche in einem Paket enthalten sein können, durch die maximale Größe des Pakets beschränkt ist. Eine hohe Anzahl von privaten Daten wird nicht erwartet, da dies gegen die Aufgabe einer Reduzierung der Größe des Bitstroms arbeitet.
void SetHeaderUserData (in ByteArray HeaderData) schreibt die Benutzerdaten zum Headerpaket. Jegliche bestehenden Daten werden überschrieben.
void UseCodeTable (in CodeTable codeTable, in Boolean encodeIt) informiert den Enkoder über eine vorbestimmte Kodetabelle und ob die Kodetabelle mit den Daten enkodiert werden soll.
void SetCompressor (in Section section, in Inflator compressor) weist den Enkoder dazu an, den spezifizierten Kompressor für die spezifizierte Sektion zu verwenden. Eine Sektion ist eine Aufzählung mit den folgenden Werten: STRUCT_BODY = 1, TEXT_BODY = 2, ID_TABLE = 3, NS_SECT = 4, ELEMENT_SECT = 5, ATTR_NAME_SECT = 6, ATTR_VALUE_SECT = 7, ATTR_PAIR_SECT = 8, DOC_HIERARCHY_SECT = 9.

Der Inflator hat die gleiche Schnittstelle wie der Inflator der java.util.zip package.
void Flush ()
entleert die Pakete im Puffer zum Ausgabestrom.
void OnOutput ()
empfängt eine Meldung, bevor der Satz von Paketen im Puffer ausgegeben wird, um es der Anwendung zu erlauben, applikationsspezifische Daten in die Pakete einzusetzen.
void SetPacketUserData (in ByteArray userData)
schreibt die Benutzerdaten an jedes der Pakete, mit Ausnahme irgendeines Headerpakets im Puffer. Jegliche bestehende Benutzerdaten werden überschrieben.
Kodetabelle-Schnittstelle

unsigned short GetSize () erlange die Anzahl von Einträgen in der Kodetabelle.
wstring GetNamespace (in unsigned short i) erlangt den Namensraum des Wertes in Zusammenhang mit dem iten Eintrag der Kodetabelle.
wstring GetValue (in unsigned short i) erlangt den Wert in Zusammenhang mit dem iten Eintrag der Kodetabelle.
wstring GetType (in unsigned short i) erlangt den Werttyp in Zusammenhang mit dem iten Eintrag der Kodetabelle.
ByteArray GetCode (in unsigned short i) erlangt den Kode in Zusammenhang mit dem iten Eintrag der Kodetabelle.
unsigned short GetIndexByCode (in ByteArray code) erlangt den Wert in Zusammenhang mit einem Kode.
unsigned short GetIndexByValue (in wstring value) erlangt den Wert im Zusammenhang mit einem Kode.
unsigned short GetMaxCodeValue () erlangt den maximalen Kodewert, welcher durch die Kodetabelle reserviert ist. Der Enkoder ist frei dazu, um einen Kodewert oberhalb des maximalen Kodewertes zu verwenden. In Abhängigkeit von einer Anwendung kann ein Enkoder ebenfalls dazu implementiert sein, Löcher zu verwenden, welche durch eine vorbestimmte Kodetabelle übrig belassen werden.

Typ-Enkoder-Schnittstelle

ByteArray Encode (in wstring text) enkodiert den Wert in ein Byte-Array, welches dessen Textdarstellung ergibt.
wstring Decode (in ByteArray encodedText) dekodiert einen enkodierten Wert in die Textdarstellung des Wertes.

Enkodierung der XML-Daten, insbesondere MPEG-7-Beschreibungen von einer Darstellung
Wenn (Fragmente von) XML-Daten, welche MPEG-7-Beschreibungen (welche XML-Daten sind, welche zur Beschreibung eines audio visuellen (AV) Inhaltes verwendet werden) enthalten, zu streamen sind und mit AV-Inhalt dargestellt sind, sind die Zeitsteuerung und die Synchronisation zwischen den Medienobjekten (welche die XML-Daten enthalten) zu spezifizieren. Genauso wie bei XML bestimmt das DDL (die Beschreibungs-Definitionssprache von XML) nicht ein Zeitsteuerungs- und Synchronisations-Modell zum Darlegen von Medienobjekten. Wie oben erwähnt, ist es bei einem SMIL-ähnlichen MPEG-7-Beschreibungs-Schema, welches hier Präsentationsbeschreibungs-Schema genannt wird, gewünscht, das Zeitsteuerungs- und Synchronisations-Modell zur Entwicklung von Multimedia-Präsentationen bereitzustellen.
Es wurde vorgeschlagen, dass MPEG-7-Beschreibungen auf die gleiche Weise wie AV-Objekte behandelt werden. Dies bedeutet, dass jedes MPEG-7-Beschreibungsfragment, wie beispielsweise AV-Objekte, welche in einer Präsentation verwendet werden, mit einer Startzeit und einer Dauer gekennzeichnet werden, welche seinen Zeitraum bestimmen. Dies erlaubt, dass sowohl MPEG-7-Fragmente als auch AV-Objekte auf eine Klasse von Medienobjektelementen des Präsentationsbeschreibungs-Schemas abgebildet werden und dem gleichen Zeitsteuerungs- und Synchronisations-Modell unterworfen werden. Genauer gesagt, im Falle eines SMIL-basierenden Präsentationsbeschreibungs-Schemas, kann ein neues Medienobjektelement, wie beispielsweise eine <mpeg7> Kennzeichnung, bestimmt werden. Alternativ können MPEG-7-Beschreibungen ebenfalls als ein spezifischer Typ von Text behandelt werden.
Es ist möglich, unterschiedliche Typen von MPEG-7-Beschreibungen in einem einzelnen Strom oder in getrennten Strömen zu senden. Es ist ebenfalls möglich, ein MPEG-7-Beschreibungsfragment zu senden, welches Teilfragmente von unterschiedlichen Zeiträumen in einem einzelnen Datenstrom oder in getrennten Strömen hat. Dies spielt eine Rolle für den Präsentations-Enkoder, im Gegensatz zum XML-Enkoder 300, welcher zuvor beschrieben wurde.
Der Präsentations-Enkoder hüllt ein XML-Paket mit einer Startzeit und einer Dauer ein, welche signalisieren, wann und für wie lang der Inhalt des Paketes erforderlich oder relevant ist. Das Paket kann enthalten:

(i) mehrere kurze Beschreibungsfragmente (jedes mit seinem eigenen Zeitraum), miteinander verknüpft, um eine hohe Komprimierungsrate zu erzielen und einen Overhead zu minimieren;
(ii) ein einzelnes Beschreibungsfragment; und
(iii) ein Teil eines großen Beschreibungsfragmentes.

In dem Falle, bei welchem das Paket mehrere Beschreibungsfragmente enthält, ist die Startzeit des Pakets die früheste der Startzeiten der Fragmente, obwohl die Dauer des Paketes die Differenz zwischen der spätesten der Endzeit der Fragmente (berechnet durch ein Hinzufügen der Dauer des Fragments zu seiner Startzeit) und der Startzeit des Paketes ist.
Bei Ausstrahlungs-Anwendungen, um es Benutzern zu ermöglichen, zu jedem Zeitpunkt die Präsentation einzustellen, sind relevante Materialien bei einem regulären Intervall zu wiederholen. Obwohl lediglich einige der XML-Pakete neu zu senden sind, da einige der XML-Pakete, welche früher gesendet wurden, nicht länger relevant sein können, muss das Headerpaket wiederholt werden. Dies bedeutet, dass im Falle von Ausstrahlungs-Anwendungen, das Headerpaket zwischen Struktur, Text und Befehlspaketen eingestreut werden kann, um die Übertragung auf einen bekannten Zustand zurück einzustellen.
Industrielle Anwendbarkeit
Anhand des Obigen ist deutlich, dass die beschriebenen Anordnungen auf die Computer- und Datenverarbeitungs-Industrie und auf die wirksame Verwendung von Kommunikationsressourcen, welche damit in Zusammenhang stehen, anwendbar sind, während sie die Möglichkeit erlauben, mit einer teilweise empfangenen Information zu arbeiten.
Das Vorhergehende beschreibt lediglich ein oder mehrere Ausführungsformen der vorliegenden Erfindung, und es können Modifikationen und/oder Änderungen darauf vorgenommen werden, ohne vom Umfang der Erfindung, wie durch die anliegenden Ansprüche bestimmt, abzuweichen, wobei die Ausführungsform bzw. Ausführungsformen darstellhaft und nicht beschränkend sind. Beispielsweise, obwohl mit Bezug auf XML-Dokumente beschrieben, sind die hier offenbarten Prozeduren auf jegliche hierarchische Darstellung anwendbar, wie beispielsweise eine Baumdarstellung von einem Dokument.
Anlage:
Bestimmung des Bitstroms
Der Bitstrom wird in der erweiterten Backus-Naur Form (ENBF) bestimmt. Zeichen werden durch einzelne Anführungszeichen und Zeichenfolgen werden durch doppelte Anführungszeichen eingeschlossen. Wenn nicht anders angegeben, werden UCS-Zeichen in UTF-8-Enkodierung und UTF-Zeichenfolgen (welche eine Längeninformation enthalten) angenommen.

N. B.: Der Bitstrom eines enkodierten XML-Dokuments enthält eine Sequenz von Paketen. Die Sequenz beginnt mit einem Headerpaket und endet mit einem Nachlaufpaket.

N. B.: Mit unsigned short wird ein unsignierter Integer im Bereich 0-65535 unter Verwendung von 2 Byte dargestellt, wobei das erste Byte des High-Order-Byte des Integers ist.

N. B.: Durch variable_length_natural_number wird eine natürliche Zahl im Bereich 0-1.073.741.823 unter Verwendung von 1 bis 4 Bytes dargestellt, wobei das erste Byte das High-Order-Byte von der Nummer ist. Die zwei meist signifikanten Bits des High-Order-Byte werden aktuell dazu verwendet, um die Nummer von zusätzlichen Bytes anzuzeigen, welche zur Darstellung der Nummer verwendet werden. Beispielsweise impliziert „01" ein zusätzliches Byte oder eine 2-Byte-Darstellung, und „11" impliziert drei zusätzliche Bytes oder eine 4-Byte-Darstellung.

N. B.: Mit UTF8 String sind die ersten zwei Bytes unsigniert kurz, wobei die UTF length, welche die Anzahl von zusätzlichen Bytes spezifiziert, auszulesen ist. Die zusätzlichen Bytes enthalten die UTE-8-Enkodierung der Zeichenfolge.

N. B.: Ein Wert von Null impliziert, dass die maximale Paketgröße unbekannt ist.

N. B.: Ein Wert von Null impliziert, dass die maximale Anzahl von Paketen unbekannt ist.

N. B.: Die obige Liste für eingebaute Datentypen ist nicht vollständig. Typ 00-0F ist für eingebaute Datentypen. Ein XML-Enkoder kann Typ 10-FF applikationsspezifischen Typen zuweisen. Die Applikation ist dazu verantwortlich, dem (Java) Typ Enkoder und Dekoder jegliche applikationsspezifische Typen bereitzustellen. Diese Typ Enkoder und Dekoder müssen zuvor installiert oder heruntergeladen werden, bevor sie erforderlich sind. Wenn eine Typinformation nicht verfügbar ist, werden XML-Text und Attributwerte als Zeichenfolge behandelt.

N. B.: Zu dem Zeitpunkt wird das Nachlauf-Paket lediglich dazu verwendet, um das Ende des XML-Dokuments zu signalisieren. Der Hauptbereich des Nachlauf-Paketes ist leer.

N. B.: Obwohl die obige EBNF-Regel die verschiedenen Sektionen des Hauptbereiches von einem Strukturpaket bestimmt, welches in einer bestimmten Reihenfolge anzuordnen ist, wird es den Sektionen tatsächlich erlaubt, in irgendeiner Reihenfolge angeordnet zu werden, da jede Sektion durch ihre eindeutige Signatur identifiziert ist.

N. B.: section size speichert die Größe der Sektion mit Ausnahme ihrer Signatur.

N. B.: Das komprimierte Kennzeichen zeigt an, ob die Tabelle komprimiert ist.
N. B.: Durch Boolean stellt ein Bytewert von 1 wahr dar, und ein Bytewert von 0 stellt falsch dar.

N. B.: ID_table bestimmt die Struktur der unkomprimierten ID-Tabelle. Die ID-Tabelle sammelt lediglich eine ID von Knoten (die Knoten, auf welche durch Knotenlokatoren Bezug genommen wird, sind nicht enthalten), welche in der Dokumenthierarchie des gleichen Pakets erscheint. Wenn eine Typinformation während der Enkodierung nicht verfügbar ist, werden IDs nicht in der ID-Tabelle gesammelt, sogar wenn sie im Dokument dargestellt sind, da es für den Enkoder keinen Weg gibt, sie zu identifizieren.

N. B.: Offset_to_the_document_hierarchy ist der Byte-Versatz zur document_hierarchy in der (unkomprimierten) document_hierarchy_section, nicht der Byte-Versatz der (unkomprimierten) document_hierarchy_section.

N. B.: Das Detail der internen Teilmengen-Sektion ist dennoch zu bestimmen.

N. B.: Der Index in die NS_table ist als Namensraumkode zu verwenden. Die Basis des Index ist im Feld index_base spezifiziert. Der Namensraumkode 0 wird für den 0-Namensraum reserviert. Somit kann eine Namensraum-Tabelle keine index_base von 0 haben.

N. B.: NS_table bestimmt die Struktur der unkomprimierten NS-Tabelle. Der Index in der Tabelle wird als der Namensraumkode verwendet. Die Basis des Index ist im Feld index_base spezifiziert. Der Namensraumkode 0 wird für den 0-Namensraum reserviert. Somit kann eine Namensraum-Tabelle keine index_base von 0 haben.

N. B.: Der Index in jeder Kodetabelle wird als der Kode verwendet, es sei denn, dass es einen vorbestimmten Kode gibt. Die Kodetabellen erlauben die Abbildung zwischen den Kodes, welche für die Enkodierung der aktuellen Werte verwendet werden. Die Basis des Index für jede Tabelle ist in dem Feld index_base von dieser Tabelle spezifiziert. Es sind lediglich positive Kodes erlaubt. Somit kann index_base keinen Wert von Null haben.

N. B.: Das has_predefined_code-Kennzeichen spezifiziert, ob die Kode-Tabelle eine predefined_code-Spalte hat.

N. B.: Das element_name_codetable bestimmt die Struktur der unkomprimierten Element Name Kode-Tabelle. Der Index in der Tabelle wird als der Elementnamenkode verwendet, es sei denn, dass es einen vorbestimmten Kode gibt. Die Basis des Index wird im Feld index_base spezifiziert. Der Kode 0 ist reserviert. Somit kann eine Kodetabelle keinen index_base von 0 haben.

N. B.: Mit Ausnahme der eingebauten Datentypen und speziellen Typen, welche dem Enkoder bekannt sind, wird ein Textinhalt von allen weiteren Typen als Zeichenfolge enkodiert.

N. B.: Ein leeres predefined_code impliziert, dass es keinen vorbestimmten Kode für diesen Eintrag gibt. Dies sollte nicht auftreten, wenn ein Wert von einer vorbestimmten Kodetabelle fehlt. Der Enkoder hat einen Kode für den Wert zu erzeugen und ihn im predefined_code Feld zu speichern.

N. B.: Die Elementnamen werden für gewöhnlich der Reihe nach in der Tabelle gespeichert. Wenn jedoch ein Elementname zu lang ist, kann er in einem separaten Textpaket gespeichert werden, und anstelle dessen wird ein Zeichenfolgen-Lokator in der Tabelle verwendet.

N. B.: Ein byte_Offset spezifiziert den Offset im Textpaket-Hauptkörper, wo die Zeichenfolge gefunden werden kann.

N. B.: attribute_name_codetable bestimmt die Struktur der unkomprimierten Attributnamen-Kodetabelle. Der Index in der Tabelle wird als der Attributnamenkode verwendet, es sei denn, dass es einen vorbestimmten Kode gibt. Die Basis des Index wird im Feld index_base spezifiziert. Der Kode 0 ist reserviert. Somit kann eine Kodetabelle keine index_base von 0 haben.

N. B.: Die Attributnamen werden für gewöhnlich der Reihe nach in der Tabelle gespeichert. Wenn jedoch ein Attributname zu lang ist, kann er in einem separaten Textpaket gespeichert werden, und es wird ein String-Lokator anstelle dessen in der Tabelle verwendet.

N. B.: attribute_value_codetable bestimmt die Struktur der unkomprimierten Attributwert-Kodetabelle. Der Index in der Tabelle wird als der Attributwertkode verwendet, es sei denn, dass es einen vorbestimmten Kode gibt. Die Basis von dem Index wird im Feld index_base spezifiziert. Der Kode 0 wird reserviert. Somit kann eine Kodetabelle keine index_base von 0 haben.

N. B.: Die Attributwerte werden für gewöhnlich der Reihe nach in der Tabelle gespeichert.

N. B.: Werte werden gemäß ihrer Typen enkodiert. Mit Ausnahme von eingebauten Datentypen und speziellen Typen, welche dem Enkoder bekannt sind, werden Werte als Zeichenfolge enkodiert.
N. B.: Eine leere UTF8-Zeichenfolge muss durch #x00 gefolgt werden, um sie von einem gültigen Zeichenfolgen-Lokator zu unterscheiden. Abermals, wenn ein Attributname zu lang ist, kann er in einem separaten Textpaket gespeichert werden, und ein Zeichenfolgen-Lokator wird anstelle dessen in der Tabelle verwendet.

N. B.: attribute_name_value_pair_table bestimmt die Struktur der unkomprimierten Attribut Name/Wert Paar Tabelle. Die Basis des Index (> 0) wird im Feld index_base spezifiziert.

N. B.: Ein Unterbaum bestimmt die Struktur des unkomprimierten XML-Unterbaums.

N. B.: Das node_size enthält die Größe des Knotens und seiner nachfolgenden Knoten, welche im gleichen Paket enkodiert sind.

N. B.: Wenn next_packet_number gleich Null ist, kann die erste Zeichenfolge des Textpaketes die letzten Fragmente einer langen Zeichenfolge sein. Wenn next_packet_number nicht Null ist, enthält das gesamte Textpaket ein einzelnes Fragment von einer Zeichenfolge.

Command Packet
Ende der Anlage

Claims

Verfahren zum Kommunizieren von zumindest einem Teil eines strukturierten Dokuments (104), welches Daten verwaltet, wobei das Dokument durch eine hierarchische Darstellung beschrieben ist, welche eine Struktur und einen Textinhalt hat, welcher an jedem Flügelknoten von der Struktur dargestellt ist, wobei das Verfahren den Schritt enthält: Identifizieren (904) der hierarchischen Darstellung des Dokuments; und gekennzeichnet durch die Schritte: Paketieren (906) der hierarchischen Darstellung in eine Mehrzahl von Datenpaketen, wobei die Struktur und die Textinhalte in separate Pakete paketiert werden, wobei das Paketieren ein Erzeugen (908) von zumindest einer Verbindung (112) zwischen zumindest einem Struktur-Paket und zumindest einem Textinhalt-Paket enthält; und Übertragen (910) der Datenpakete in einem oder mehreren Strömen.
Verfahren nach Anspruch 1, welches ferner die Schritte enthält: Empfangen des Stroms; Dekodieren der Pakete aus dem Strom, um die zumindest eine Verbindung (112) zu identifizieren; und Verwenden der zumindest einen Verbindung (112), um die Darstellung für Abschnitte von der Darstellung, welche nicht mit einem Paket von dem Strom paketiert ist, zu rekonstruieren.
Verfahren nach Anspruch 1 oder 2, bei welchem der Paketierungs-Schritt ein Erzeugen von zumindest einer Verbindung (112) zwischen dem zumindest einen Struktur-Paket und zumindest einer Hierarchie, welche mit dem Textinhalt-Paket in Zusammenhang steht, enthält.
Verfahren nach Anspruch 1, bei welchem der Identifizierungs-Schritt (904) enthält: Identifizieren von zumindest einem Teil von der Darstellung, und Paketieren der Teile in zumindest ein Paket von einer vorbestimmten Größe; und Bestimmen, wenn irgendein oder mehrere weitere Teile von der Darstellung nicht innerhalb des einen Pakets passt, von zumindest einer Verbindung von dem einen Paket an zumindest ein weiteres Paket, in welchem die weiteren Teile paketiert sind, wobei die Verbindung die hierarchische Struktur des Dokuments in den Paketen beibehält.
Verfahren nach einem der Ansprüche 1 bis 4, bei welchem die hierarchische Darstellung eine Baum-Darstellung enthält.
Verfahren nach einem der Ansprüche 1 bis 5, bei welchem das Dokument ein XML-Dokument enthält.
Verfahren nach Anspruch 4, bei welchem die vorbestimmte Größe eine vorbestimmte maximale Größe ist.
Verfahren nach Anspruch 1, bei welchem das Dokument ein XML-Dokument (104) ist, wobei das Verfahren die Schritte enthält: Untersuchen des XML-Dokumentes (104), um jeden Datentyp zu identifizieren, welcher einen Teil des XML-Dokumentes (104) ausbildet; Identifizieren eines ersten Satzes der Datentypen, für welchen ein entsprechend spezielles Enkodierungs-Format verfügbar ist; erstes Enkodieren von jedem Teil des XML-Dokumentes (104), welcher einen Datentyp in dem ersten Satz hat, mit dem entsprechend speziellen Enkodierungs-Format; zweites Enkodieren von jedem verbleibenden Teil des XML-Dokumentes (104) mit einem vorgegebenen Enkodierungs-Format, welches dem Datentyp des verbleibenden Teils entspricht; Ausbilden einer Darstellung von einer Information, welche sich zumindest auf jeden Datentyp in dem ersten Satz bezieht, mit dem entsprechend speziellen Enkodierungs-Format; und Zuordnen der Darstellung und des ersten und zweiten enkodierten Teils als eine enkodierte Form des XML-Dokumentes (104).
Verfahren nach Anspruch 8, bei welchem der erste und zweite Enkodierungs-Schritt jeweils separat Struktur- und Inhalts-Teile des XML-Dokumentes (104) enkodieren, und wobei die Darstellung in einem Header-Abschnitt der enkodierten Form des XML-Dokumentes (104) einbehalten wird.
Verfahren nach Anspruch 8 oder 9, bei welchem die Darstellung in dem Header-Abschnitt als eine Tabelle einbehalten wird.
Verfahren nach Anspruch 9, bei welchem die separat enkodierten Teile Pakete von zumindest einem Bitstrom enthalten.
Verfahren nach Anspruch 8, bei welchem der erste Enkodierungs-Schritt ein Untersuchen des Datentyps in dem ersten Satz und des entsprechenden Teils, und ein Bestimmen von einem der Enkodierungs-Formate, welches auf den Teil angewendet wird, enthält.
Verfahren nach Anspruch 8, bei welchem der zweite Enkodierungs-Schritt ein Auswählen von einem aus einer Mehrzahl der Enkodierungs-Formate entsprechend einem Datentyp des verbleibenden Teils, und ein Enkodieren des verbleibenden Teils mit dem ausgewählten Enkodierungs-Format enthält.
Verfahren zum Dekodieren eines enkodierten XML-Dokumentes (104), wobei das Verfahren dadurch gekennzeichnet ist, dass es die Schritte enthält: Erlangen von einer Mehrzahl von Paketen, welche zusammengefasst das enkodierte XML-Dokument ausbilden, wobei die Pakete zumindest ein Paket enthalten, welches eine Struktur-Information des XML-Dokumentes enthält, welches von zumindest einem Paket getrennt ist, welches eine Inhalts-Information des XML-Dokumentes enthält; Untersuchen der Pakete, um ein Enkodierungs-Format zu identifizieren, welches mit jedem Datentyp in Zusammenhang steht, welcher ein Teil des XML-Dokumentes (104) ausbildet; und Dekodieren von jedem Teil unter Verwendung eines Dekoders, welcher das Enkodierungs-Format ergänzt, mit welchem der entsprechende Datentyp enkodiert wurde.
Verfahren nach Anspruch 14, bei welchem der Untersuchungs-Schritt ein Identifizieren innerhalb von zumindest einem Struktur-Teil von einer Darstellung enthält, welche einen enkodierten Teil des XML-Dokumentes dem entsprechenden Enkodierungs-Format zuordnet.
Verfahren nach Anspruch 15, bei welchem die Darstellung innerhalb eines Headers von zumindest einem Paket ausgebildet ist.
Verfahren nach Anspruch 16, bei welchem die Darstellung eine Tabelle enthält.
Verfahren nach einem der Ansprüche 15 bis 17, bei welchem die Darstellung eine URI enthält.
Verfahren nach Anspruch 15, bei welchem sich die Darstellung auf zumindest einen Satz von speziellen Datentypen bezieht, welche entsprechende Dekodierungs-Formate haben.
Verfahren nach Anspruch 14, bei welchem das Verfahren, wenn kein Dekoder zum Dekodieren eines Teils des enkodierten XML-Dokumentes verfügbar ist, ein Ignorieren des Teils enthält.
Paketierter Bitstrom, welcher unter Verwendung des Verfahrens nach einem der Ansprüche 1 bis 13 ausgebildet ist.
Einrichtung zum Kommunizieren von zumindest einem Teil eines strukturierten Dokumentes, welches Daten verwaltet, wobei das Dokument durch eine hierarchische Darstellung beschrieben ist, welche eine Struktur und einen Textinhalt hat, welcher an jedem Flügelknoten des Aufbaus dargestellt ist, wobei die Einrichtung enthält: ein Identifizierungsmittel (302) zum Identifizieren der hierarchischen Darstellung des Dokumentes; und gekennzeichnet durch: ein Paketierungsmittel (302) zum Paketieren der hierarchischen Darstellung in eine Mehrzahl von Datenpaketen, wobei die Struktur und die Textinhalte in separate Pakete paketiert sind, wobei das Paketierungsmittel dazu angeordnet ist, um zumindest eine Verbindung zwischen zumindest einem Struktur-Paket und zumindest einem Textinhalt-Paket zu erzeugen; und ein Übertragungsmittel (302) zum Übertragen der Datenpakete in einem oder mehreren Strömen.
Einrichtung nach Anspruch 22, welche ferner enthält: ein Mittel zum Empfangen des Stroms; ein Mittel zum Dekodieren der Pakete aus dem Strom, um die zumindest eine Verbindung (112) zu identifizieren; und ein Mittel zum Verwenden der zumindest einen Verbindung (112), um die Darstellung für Abschnitte von der Darstellung, welche nicht mit einem Paket von dem Strom paketiert sind, zu rekonstruieren.
Einrichtung nach Anspruch 22 oder 23, bei welcher das Paketierungsmittel dazu angeordnet ist, um zumindest eine Verbindung zwischen dem zumindest einem Struktur-Paket und zumindest einer Hierarchie, welche mit dem Textinhalt-Paket in Zusammenhang steht, zu erzeugen.
Einrichtung nach Anspruch 22, bei welcher das Identifizierungsmittel (302) enthält: ein Mittel zum Identifizieren von zumindest einem Teil von der Darstellung und ein Mittel zum Paketieren der Teile in zumindest ein Paket von einer vorbestimmten Größe; und ein Mittel zum Bestimmen, wenn irgendein oder mehrere weitere Teile der Darstellung nicht innerhalb des einen Paketes passt, von zumindest einer Verbindung von dem einen Paket an zumindest ein weiteres Paket, in welchem die weiteren Teile paketiert sind, wobei die Verbindung die hierarchische Struktur des Dokuments in den Paketen beibehält.
Einrichtung nach einem der Ansprüche 22 bis 25, bei welcher die hierarchische Darstellung eine Baum-Darstellung enthält.
Einrichtung nach einem der Ansprüche 22 bis 26, bei welcher das Dokument ein XML-Dokument (104) enthält.
Einrichtung nach Anspruch 25, bei welcher die vorbestimmte Größe eine vorbestimmte maximale Größe ist.
Einrichtung nach Anspruch 22, welche ferner enthält: ein Mittel (302) zum Untersuchen des XML-Dokumentes (104), um jeden Datentyp zu identifizieren, welcher einen Teil des XML-Dokumentes ausbildet; ein Mittel (302) zum Identifizieren eines ersten Satzes der Datentypen, für welche ein entsprechend spezielles Enkodierungs-Format verfügbar ist; ein erstes Enkodierungsmittel (302) zum Enkodieren jedes Teils des XML-Dokumentes (104), welcher einen Datentyp in dem ersten Satz hat, mit dem entsprechend speziellen Enkodierungs-Format; ein zweites Enkodierungsmittel (302) zum Enkodieren jedes verbleibenden Teils des XML-Dokumentes mit einem vorgegebenen Enkodierungs-Format, welches dem Datentyp des verbleibenden Teils entspricht; ein Mittel (302) zum Ausbilden einer Darstellung von einer Information, welche sich zumindest auf jeden Datentyp in dem ersten Satz bezieht, mit dem entsprechend speziellen Enkodierungs-Format; und ein Mittel (302) zum Zuordnen der Darstellung und des ersten und zweiten enkodierten Teils als eine enkodierte Form des XML-Dokumentes (104).
Einrichtung nach Anspruch 29, bei welcher das erste und zweite Enkodierungsmittel (302) dazu angeordnet sind, um separat Struktur- und Inhaltsteile des XML-Dokumentes (104) zu enkodieren, und wobei das Mittel zum Ausbilden (302) von einer Darstellung dazu angeordnet ist, die Darstellung in einem Header-Abschnitt von der enkodierten Form des XML-Dokumentes (104) einzubehalten.
Einrichtung nach Anspruch 29 oder 30, bei welcher das Mittel (302) zum Ausbilden einer Darstellung dazu angeordnet ist, die Darstellung in dem Header-Abschnitt als eine Tabelle einzubehalten.
Einrichtung nach Anspruch 30, bei welcher die separat enkodierten Teile Pakete von zumindest einem Bitstrom enthalten.
Einrichtung nach Anspruch 29, bei welcher das erste Enkodierungsmittel (302) dazu angeordnet ist, den Datentyp in dem ersten Satz und den entsprechenden Teil zu untersuchen, und eines der Enkodierungs-Formate zu bestimmen, welches auf den Teil anzuwenden ist.
Einrichtung nach Anspruch 29, bei welcher das Enkodierungsmittel (302) dazu angeordnet ist, eines aus einer Mehrzahl der Enkodierungs-Formate entsprechend einem Datentyp des verbleibenden Teils auszuwählen, und den verbleibenden Teil mit dem ausgewählten Enkodierungs-Format zu enkodieren.
Einrichtung zum Dekodieren und Enkodieren eines XML-Dokumentes, gekennzeichnet durch: ein Mittel (402) zum Erlangen einer Mehrzahl von Paketen, welche zusammengefasst das enkodierte XML-Dokument ausbilden, wobei die Pakete zumindest ein Paket enthalten, welches eine Struktur-Information des XML-Dokumentes enthält, welches von zumindest einem Paket getrennt ist, welches eine Inhalts-Information des XML-Dokumentes enthält; ein Mittel (402) zum Untersuchen der Pakete, um ein Enkodierungs-Format zu identifizieren, welches mit jedem Datentyp in Zusammenhang steht, welcher ein Teil des XML-Dokumentes (104) ausbildet; und ein Mittel (402) zum Dekodieren jedes Teils unter Verwendung eines Dekoders, welcher das Enkodierungs-Format ergänzt, mit welchem der entsprechende Datentyp enkodiert wurde.
Einrichtung nach Anspruch 35, bei welcher das Untersuchungsmittel (402) dazu angeordnet ist, um innerhalb von zumindest einem Struktur-Teil eine Darstellung zu identifizieren, welche einen enkodierten Teil des XML- Dokumentes (104) dem entsprechenden Enkodierungs-Format zuordnet.
Einrichtung nach Anspruch 36, bei welcher die Darstellung innerhalb eines Headers von zumindest einem Paket ausgebildet ist.
Einrichtung nach Anspruch 37, bei welcher die Darstellung eine Tabelle enthält.
Einrichtung nach einem der Ansprüche 36 bis 38, bei welcher die Darstellung eine URI enthält.
Einrichtung nach Anspruch 36, bei welcher sich die Darstellung auf zumindest einen Satz von speziellen Datentypen bezieht, welche entsprechende Dekodierungs-Formate haben.
Einrichtung nach Anspruch 35, bei welcher das Dekodierungsmittel (402) dazu angeordnet ist, einen Teil des enkodierten XML-Dokumentes (104) zu ignorieren, wenn kein Dekoder zum Dekodieren des Teils verfügbar ist.
Computerlesbares Medium, welches ein darauf gespeichertes Programm hat, wobei das Programm Anweisungen enthält, um einen Computer zur Ausführung eines Verfahrens nach einem der Ansprüche 1 bis 21 zu konfigurieren.