DE69126805T2

DE69126805T2 - Datenformatumwandlung

Info

Publication number: DE69126805T2
Application number: DE69126805T
Authority: DE
Inventors: Jean Kelly; Paul Mcnelis; Jonathan Smith
Original assignee: Digital Equipment International Ltd
Current assignee: Compaq Computer Holding Ltd
Priority date: 1990-03-14
Filing date: 1991-03-11
Publication date: 1998-02-12
Anticipated expiration: 2011-03-12
Also published as: US5173853A; EP0447157B1; GB9005697D0; EP0447157A3; DE69126805D1; JPH05282131A; EP0447157A2

Description

Gebiet der Erfindung

Die vorliegende Erfindung betrifft die Umwandlung von Dokumentendaten zwischen verschiedenen Formaten, und insbesondere eine derartige Umwandlung zwischen verschiedenen Formen einer Architektur eines zusammengesetzten Dokuments.

Datenarchitekturen - allgemein

Bei der Textverarbeitung, beim Desktop-Publishing (rechnerunterstützte Druckvorlagengestaltung) und ähnlichem ist eine Vielzahl von Datenformaten entwickelt worden. Die einfachsten Formate sind zum Behandeln von nur einer Textsache entwickelt. Selbst bei einer derartigen offensichtlich einfachen Situation gibt es viele Aspekte, die behandelt werden können oder nicht, und die dann, wenn sie behandelt werden, auf eine Vielzahl von Arten behandelt werden können. Diese sind beispielsweise ein Zeilenumbruch, eine Rechtsausrichtung, Anfangsblöcke und Fußblöcke und eine Randsteuerung. Weiter fortentwickelte Formate enthalten ein Vorsehen für Dinge wie Fußnoten und Absatz- und Abschnittnumerierung, Tabelleninformation, geometrische Graphik und Bitbildgraphik.
Da die Art solcher Formate in wachsendem Maße komplex wird, ist es angenehm, zwischen den allgemeinen Prinzipien oder Regeln eines Formats und den Details der Implementierung einer solchen Gruppe von Prinzipien zu unterscheiden. Die Gruppe von Prinzipien wird allgemein Architektur genannt, und eine Implementierung wird oft Austauschformat jener Architektur genannt.
Bei einer einfachen Architektur, wie bei jener, die durch ein grundlegendes Textverarbeitungssystem bereitgestellt wird, sind die strukturellen Merkmale eines unter jener Architektur formatierten Dokuments sehr einfach. Bei einer derartigen Architektur wird das Dokument normalerweise als Strom von alphanumerischen Zeichen - der Text - mit dem formatiert, welche strukturellen Merkmale auch immer innerhalb jenes Stroms eingebaut sind. Das bedeutet, daß Merkmale, wie beispielsweise Zeilenrücksprünge bzw. -rückläufe durch Steuercodes dargestellt werden, die an den geeigneten Stellen innerhalb des Zeichenstroms auftreten. Gleichermaßen können solche Dinge wie das Beginnen und das Beenden von Schrägschrift und Fettdruck durch den Einbau von Steuerzeichen in den Zeichenstrom dargestellt werden. Dieser Architekturstil kann offensichtlich auf kompliziertere Situationen ausgeweitet werden. Beispielsweise dann, wenn die Architektur eine Paginierung enthält, können die Codes für ein Beenden einer Seite offensichtlich im Zeichenstrom enthalten sein.
Die geeignete Information bezüglich solcher Dinge wie einer Zeilen- und einer Seitenlänge muß offensichtlich spezifiziert werden. In sehr einfachen Fällen kann dies manchmal durch die Operation eines Druckers behandelt werden, zu welchem auch immer das Dokument gesendet wird. Es ist jedoch nützlicher, daß eine derartige Information im Dokument enthalten ist. Wenn die Zeilen- und Seitenlängen im ganzen Dokument unverändert bleiben, wird diese Information normalerweise am Anfang des Dokuments eingebaut, der dem Text voransteht und einen Anfangsblock bildet.
Diese Technik erstreckt sich natürlich auf das Vorsehen ähnlicher Steuerblöcke an geeigneten Stellen innerhalb des Informationsstroms, wo das Format (in dem Sinn solcher Dinge wie Ränder und eine Seitenlänge) des Dokuments sich ändert. Ein einfaches Beispiel ist der Einbau einer Anmerkung in Form eines unterschiedlichen Absatzes unter Verwendung einer kleineren Schriftart als für den Haupttext und gegenüber diesem mit seinen Rändern eingerückt. Dieser wird ein Steuerblock vorangestellt sein, der die Schriftart und Ränder einstellt, und ihr wird natürlich ein anderer Steuerblock folgen, der die ursprüngliche Schriftart und die ursprünglichen Ränder einstellt.
Bis hier ist bei der Diskussion größtenteils angenommen worden, daß das Dokument vollständig formatiert ist. Es ist jedoch oft angenehm, die Informationsinhalte des Dokuments von seiner Endformatierung zu trennen. Das Dokument ist in seinem Anfangszustand in etwas, das verarbeitbare Form genannt wird. (Der Ausdruck "Informationsinhalte" ist im weiten Sinn die Bedeutung einer Definition für die allgemeinen Parameter des Dokuments, wie beispielsweise Seitenanfangsblöcke und -fußblöcke, Schriftart, Absatzeinrückungen, verengte Ränder, etc.)
Bei einem verarbeitbaren Dokument sind die Details des aktuellen Seitenlayouts (primär die Seitenbreite oder Zeilenlänge und Seitenänge) undefiniert gelassen. Wenn das Dokument schließlich als Hardcopy bzw. Druckkopie gedruckt wird, muß dem Drucksystem eine solche Formatierungsinformation zugeführt worden sein, und das System muß die Positionen für ein Beendigen einer Zeile und einer Seite berechnen und geeignete Einstellungen durchführen (z.B. bei einer Seitennumerierung und einer Fußnotenpositionierung).
Ein größerer Vorteil beim Verwenden von Dokumenten in einer verarbeitbaren Form besteht darin, daß ein Editieren des Dokuments vereinfacht wird, und zwar aus zwei Gründen.
Einer besteht darin, daß das Editieren des Dokuments (normalerweise an einem Wortprozessor) nicht die Details des Layouts des Dokuments auf der Seite berücksichtigen muß. Dies bedeutet, daß der Betrieb des Textsystems schneller ist, und zwar insbesondere in Situationen, wo der Bediener zwischen weit auseinanderliegenden Stellen im Dokument hin- und herspringt. (Wenn das Dokument in vollständig formatierter Form vorliegt, müßte das System den gesamten Text zwischen den relevanten Stellen beim Vorwärtsbewegen von einer zur anderen neu formatieren.)
Der andere Grund besteht darin, daß das Dokument zwischen unterschiedlichen Systemen viel einfacher übertragen werden kann. Solche unterschiedlichen Systeme können unterschiedliche Hardware enthalten, oder etwas offensichtlich geringeres als eine geringfügige Änderung eines Druckerzeichenstils (was eine Neuberechnung von Zeilenlängen erforderlich machen wird), oder vielleicht einfach eine Änderung bezüglich der Papiergröße. Wiederum würde eine solche Änderung dann, wenn das Dokument vollständig formatiert wäre, ein neues Formatieren des gesamten Dokuments enthalten, wohingegen beim Dokument in einer verarbeitbaren Form keine Änderung am Dokument erforderlich ist.
Es wird von hier an angenommen, daß Dokumente in einer verarbeitbaren Form sind.

Architekturen eines zusammengesetzten Dokuments - allgemein

Die oben diskutierte Formatiertechnik besteht im wesentlichen aus einem Einbauen der Formatierinformation in den Zeichenstrom des Dokuments. Bei einem sehr einfachen Wortverarbeitungssystem kann eine solche Information beispielsweise aus wenig mehr als einer Absatzbildung bestehen, und diese Technik ist allgemein zufriedenstellend. Jedoch kann diese Technik in komplizierteren Situationen unhandlich werden.
Ein einfaches Beispiel kann in der oben angegebenen Situation auftreten, wo es Anmerkungen im Text gibt. Wenn es mehrere derartige Anmerkungen gibt, wird es eine entsprechende Anzahl von Wiederholungen der Steuerblöcke geben. Eine weitere Situation ist die, wo das Dokument groß ist, das aus einer Anzahl von Kapiteln besteht, die jeweils in Abschnitte unterteilt sind.
Weiterhin gibt es oft eine Notwendigkeit für Systeme, die weiterentwickelt sind als einfache Textverarbeitungssysteme. Die Möglichkeiten von solchen Dingen, wie Änderungen des Schriftbildes, sind bereits genannt worden, und solche Systeme können weiterentwickelt werden, um den Einbau von beispielsweise geometrischer und/oder rastermäßiger Graphik und verschiedener Arten von Listen und Tabellen zuzulassen.
Aus diesen und anderen Gründen ist ein alternativer Ansatz entwickelt worden, da die Architektur komplizierter wird, was zu einem zweiten Architekturstil führt, der allgemein Architektur für ein zusammengesetztes Dokument genannt wird. Dieser zweite Stil enthält die Trennung der Struktur eines Dokuments von seinen Inhalten. Mit diesem Ansatz ist die logische Struktur eines Dokuments in der Form eines Baums definiert, was am einfachsten anhand eines Beispiels erklärt werden kann. Es soll angenommen werden, daß das Dokument ein Text-Buch ist. Dann kann die erste Ebene einer Struktur des Dokuments derart definiert werden, daß sie aus einem Titel, einer Liste von Inhalten, einer Einführung, einer Anzahl von Kapiteln, einer Liste von Referenzen, und einem Index besteht, wobei die Anzahl von Kapiteln variabel ist und, sagen wir, das Vorhandensein einer Einführung optional ist. In Folge hat jedes dieser Elemente seine eigene Struktur; beispielsweise kann die Struktur eines Kapitels aus einem Titel und einer Anzahl von Abschnitten bestehen, und zwar jeweils mit einem Abschnitts-Anfangsblock. Ein Element mit einer solchen Struktur von sich selbst wird zusammengesetztes Element genannt; ein Element ohne solche Subordinatenstruktur wird Grundelement genannt.
Bei diesem zweiten formalmäßigeren und strukturierteren Architekturstil ist das Format oder das Layout des Dokuments eine abgetrennte und bis zu einigem Ausmaß untergeordnete Sache, die der logischen Struktur zu überlagern ist. Dies wird durch Definieren einer Layoutstruktur für jedes logische Element durchgeführt. Prinzipiell könnte dies durch Definieren einer Gruppe unabhängiger Layoutstrukturen erreicht werden, weil aber die gewünschten Layouts der verschiedenen logischen Elemente normalerweise viele Merkmale gemeinsam haben werden, wird dies in der Praxis durch Definieren eines Baums von Layoutelementen erreicht.
Die logische Struktur wird somit aus einem Baum von Elementen bestehen, wobei die letzten oder "Blatt"-Elemente die aktuellen Daten (Text oder andere Information) enthalten. Die "Blatt"-Elemente der Layoutstruktur oder des Baums werden mit den "Blatt"-Elementen der logischen Struktur verbunden. Unbedeutendere lokale Merkmale des Layouts, wie beispielsweise Fettdruck und Kursivdruck, sind in der Zeichenkette des logischen Elements durch den Layoutprozeß eingebettet.
Wie beim ersten Architekturstil kann der Stil eines zusammengesetzten Dokuments darauf zugeschnitten sein, entweder ein verarbeitbares oder ein vollständig formatiertes Dokument herzustellen. Es gibt eine weitere Komplikation bei der vollständig formatierten Form, da die logischen Elemente, die bislang beschrieben sind, unabhängig von Seitenumbrüchen sind. Was normalerweise getan wird ist, daß ein logisches Element, das über einen Seitenumbruch hinausgeht, als zwei getrennte logische Elemente neu definiert wird, und zwar als eines auf jeder Seite. (Diese zwei logischen Elemente nutzen natürlich ein gemeinsames logisches Elternelement.) Wir werden hier jedoch wie zuvor annehmen, daß wir uns primär mit Dokumenten in einer verarbeitbaren Form beschäftigen.
Es ist auf einen anderen wesentlichen Punkt hinzuweisen, wenn komplizierte Information zu behandeln ist. Information kann, wie es bislang angenommen ist, in der Form von Text sein; jedoch kann es auch erwünscht sein, Information in anderen Formen zu behandeln, wie beispielsweise eine geometrische Graphik, Raster- (Bitbild)-Graphik, Tabellen, Arbeitsblätter, und so weiter. (Geometrische Graphiken sind Diagramme, die als Linien definiert sind, deren Endstellenkoordinaten gegeben sind, als Kreise, deren Zentralkoordinaten und Radien gegeben sind, volle Muster, &c; Bit-Bild-Graphiken sind Diagramme, die durch die Zustände ihrer einzelnen Pixel definiert sind.) Für diese wird es im allgemeinen nötig sein, daß ihre eigenen Formate größtenteils unabhängig von den Formaten anderer Typen von Information definiert sind, und diese Formate werden als Steuerblöcke oder Layoutelemente in Abhängigkeit vom Architekturstil enthalten sein.
Im allgemeinen können Blöcke von Information von unterschiedlichen Typen einander folgen und/oder ineinander eingebettet sein, und zwar sehr frei beim ersten Architekturstil. Beim zweiten Stil muß ein logisches Grundelement vom Einzelinformationstyp sein, aber ein zusammengesetztes logisches Element kann logische Grundelemente unterschiedlicher Informationstypen enthalten.
Eine besondere Situation entsteht bei Fußnoten, die bis zu einem gewissen Maß derart zu behandeln sind, als ob sie von einem anderen Informationstyp sind, obwohl sie normalerweise ein Text sind, der im Text auftritt. Beim zweiten Architekturstil wird eine Fußnote mittels eines einzelnen logischen Elements behandelt. (Beim ersten Stil ist eine Fußnote im Zeichenstrom mittels eines geeigneten Steuerblocks eingebettet.)
Es gibt natürlich eine breite Vielzahl spezifischer Datenformate, und es gibt oft eine Notwendigkeit zum Umwandeln von Daten von einem Format in ein anderes. Eine derartige Umwandlung kann selten perfekt durchgeführt werden, selbst wenn die zwei Formate denselben Architekturstil anwenden. Die vorliegende Erfindung betrifft die Umwandlung zwischen bestimmten unterschiedlichen Implementierungen oder Architekturen des zweiten Stils.

CDA- und ODA-Architekturen für ein zusammengesetztes Dokument

Mehrere Architekturen für ein zusammengesetztes Dokument existieren gegenwärtig, z.B. CDA und ODA (es ist zu beachten, daß das Wort "zusammengesetzt" mit zwei unterschiedlichen Bedeutungen verwendet wird, und zwar einmal allgemein und das andere Mal spezifisch (CDA)). Jede dieser Architekturen definiert, wie zusammengesetzte Dokumente dargestellt und gespeichert werden können. Insbesondere ist CDA eine Architektur für ein zusammengesetztes Dokument und ODA ist eine Architektur für ein Amtsdokument. Diesen sind zwei jeweilige spezifische Formate zugeordnet, und zwar DDIF (digitales Dokumentenaustauschformat) bzw. ODIF (Amtsdokumentenaustauschformat). Die ODA/ODIF-Architektur und das zugehörige Format sind durch das ISO-Dokument ISO 8613 definiert, und die DDIF-Architektur und das zugehörige Format sind durch das Dokument DEC STD 078 von Digital Equipment Corporation definiert. CDA und ODA sind Architekturen, und DDIF und ODIF sind bestimmte Formate, die mit jenen jeweiligen Architekturen übereinstimmen.
Beide dieser Architekturen und ihre zugehörigen Formate werden auf einem weiten Gebiet benutzt, und es gibt eine offensichtliche Notwendigkeit dafür, Daten in einem Format in das andere umwandeln zu können. Jedoch unterscheiden sich diese zwei Architekturen und Formate signifikant voneinander. Die Umwandlung zwischen ihnen ist daher nicht trivial.
Die vorliegende Erfindung wird unter Bezugnahme auf CDA/DDIF und ODA/ODIF beschrieben. Es sollte jedoch verstanden werden, daß sie nicht auf bestimmte Merkmale jener bestimmten Architekturen beschränkt ist, und auch, daß viele der Eigenschaften jener Architekturen in modifizierter und/oder vereinfachter Form für gegenwärtige Zwecke beschrieben sind.
Die Details der Strukturen von Dokumenten in ODA/ODIF und CDA/DDIF sind durch die oben angegebenen Dokumente definiert. Jedoch ist zum Verstehen der vorliegenden Erfindung eine kurze informelle Beschreibung dieser Strukturen wünschenswert.
Beide Strukturen verwenden eine Hierarchie von Elementen (bei ODA/ODIF allgemein "Objekte" genannt, und bei CDA/DDIF "Segmente"), die in Baumform angeordnet sind, wobei der Baum mit einem Wurzelelement beginnt. Beispielsweise dann, wenn das Dokument ein Buch ist, wird das Wurzelelement das gesamte Dokument (das Buch) sein; die Elemente in der ersten Ebene nach unten werden Kapitel sein; die Elemente in jedem Kapitel können ein Titel und eine Abschnittsnummer sein; die Elemente in einem Abschnitt können ein Abschnittsanfang und eine Absatznummer sein; und so weiter. Jedes Element wird im allgemeinen eine Anzahl von Attributen haben, von denen jedes einen aus einem Bereich möglicher Werte haben kann.
Bei ODA/ODIF bilden die gerade angegebenen Elemente die logische Struktur. Das Wurzelelement wird logisches Wurzelobjekt genannt. An den "Blatt"-Enden der Zweige werden die untersten Elemente "Inhaltsteile" genannt. Diese enthalten den Inhalt oder das Material des Dokuments. Die Elemente zwischen dem Wurzelelement und den Inhaltsteilelementen werden "logische Grundobjekte" (BLOs) genannt, wenn sie nur Inhaltsteile enthalten, oder sonst "zusammengesetzte logische Objekte" (CLOs) (d.h. wenn sie weitere logische Objekte enthalten).
In ODA/ODIF wird das Layout eines Dokuments durch eine Layoutstruktur beschrieben, die auch die Form eines Baums hat. Die Layoutstruktur hat ein Wurzelelement, nämlich das Dokument. Die Elemente eine Ebene darunter sind Seitengruppen; die Elemente auf der nächsten Ebene darunter sind Seiten; diesen können Frames (optional mehrere Ebenen davon) folgen; und diesen Blöcke (die die unterste Ebene bilden). Dieser Layoutbaum ist unabhängig von der logischen Struktur, obwohl er normalerweise gewisse allgemeine Ähnlichkeiten zu jenen logischen Strukturen haben wird. Beispielsweise wird dann, wenn das Dokument ein Buch ist, die logische Struktur eines Kapitelelements, das aus einem Anfangsblokkelement und Abschnittselementen zusammengesetzt ist, normalerweise in einer Layoutstruktur eines Anfangsblock-Layoutelements und eines Abschnitts- Layoutelements berücksichtigt werden, aber die meisten oder alle der logischen Abschnittselemente werden ein einziges gemeinsames Abschnitts-Layoutelement gemeinsam nutzen.
In ODA/ODIF müssen diese zwei Bäume für ein Dokument derart aufgebaut sein, daß jeder Inhaltsteil der logischen Struktur mit einem entsprechenden Block in der Layoutstruktur gepaart ist. Wie es oben angegeben ist, wird dies oft ein Aufteilen eines Absatzes in zwei oder mehrere Inhaltsteile enthalten, um den aufgeteilten Absatz zwischen zwei Spalten oder Seiten unterzubringen.
Es wird realisiert werden, daß dann, wenn ein Dokument gerade bearbeitet (erzeugt oder editiert) wird, normalerweise nicht die vollen Beschränkungen beobachtet werden. Wie es gut erkannt wird, ist dies deshalb so, weil das Editieren eines Dokuments merklich verlangsamt und kompliziert wird, wenn das Dokument jedesmal neu formatiert wird, wenn eine kleine Änderung an seinen Inhalten durchgeführt wird. Statt dessen werden die vollständigen Beschränkungen dem Dokument auferlegt, wenn ein Editieren endet. (Dieses Prinzip betrifft gleichermaßen ODA/ODIF und CDA/DDIF).
In CDA/DDIF gibt es logische Strukturen und Layoutbaumstrukturen, die irgendwie ähnlich zu jenen von ODA/ODIF sind. Jedoch ist die Struktur von CDA/DDIF weniger streng beschränkt und definiert als jene von ODA/ODIF, welche strenger formalisiert und strukturiert ist.
Bis zu einem gewissen Ausmaß benutzt CDA/DDIF ein implizites auf einer Korrekturfahne basierendes Layout (obwohl die Attribute der verschiedenen Elemente allgemein viele der Charakteristiken oder Merkmale des Layouts definieren werden - beispielsweise Schriftarten, Schriftartengrößen, Zeilenbreiten, etc.). CDA/DDIF ist somit in einiger Hinsicht einfacher als ODA/ODIF; jedoch ist es in anderer Hinsicht mühsamer (beispielsweise erlaubt sie die Verwendung von lebenden Verbindungen und externen Referenzen).
Bis zu einem beachtlichen Ausmaß entsprechen einzelne Elemente in ODA/ODIF und CDA/DDIF einander direkt auf einer Eins-zu-Eins-Basis. Unter diesen Elementen können beispielsweise Elemente, Attributnamen, Attributwerte, Textketten, usw. sein.
Jedoch bedeuten die Unterschiede zwischen diesen zwei Architekturen, daß diese Entsprechung nicht exakt ist. Somit läßt CDA/DDIF zu, was in der Auswirkung ein Verschachteln von Segmenten ist, was darin resultiert, daß die Segmentierung etwas weniger klar zugeschnitten ist als in ODA/ODIF. Weiterhin kann bei dieser Verschachtelung in CDA/DDIF einem Inhaltsteil eines Typs (z.B. textmäßig) ein Inhaltsteil eines anderen Typs (z.B. graphikmäßig) folgen, wohingegen in ODA/ODIF Inhaltsteile unterschiedlichen Typs in unterschiedlichen (logischen) Objekten sein müssen. (Die unterschiedlichen Typen von Inhalten - z.B. Text, Rastergraphiken und geometrische Graphiken - können auch Überklassen genannt werden.)
Zusätzlich zu den offensichtlich unterschiedlichen Typen von Inhalten (Text, geometrische Graphiken, Rastergraphiken, Listenstrukturen, usw.), gibt es eine weitere Situation, in der unterschiedliche Stücke von Inhalten bis zu einem gewissen Ausmaß als unterschiedliche Typen behandelt werden müssen, auch wenn sie beide zu einem Text gehören. Diese Situation ist diejenige von Fußnoten. In CDA/DDIF kann eine Fußnote in der Mitte eines Textsegments enthalten (eingebettet) sein. In ODA/ODIF muß eine Fußnote ihr eigenes Objekt (oder tatsächlich ihren eigenen Objektbaum, wie es später beschrieben wird) haben. Irgendwie ähnliche Situationen entstehen bei Dingen, wie beispielsweise der Einfügung von Seitenzahlen in der Form von Kreuzreferenzen im Körper des Dokuments (als Unterschied zu Seitenzahlen in Anfangsblöcken oder Fußblöcken, welche in Dokumenten in verarbeitbarer Form nicht enthalten sind.)
Für den Betrieb des zu erklärenden Systems ist es erwünscht, die Art von ODA/ODIF und CDA/DDIF noch detaillierter zu umreißen.

ODA-Dokumentenstruktur

Betrachtet man zuerst ODA/ODIF, ist ein ODIF-Dokument als ein Paar von Bäumen strukturiert, und zwar als logischer Baum für die Inhalte und als Layout-Baum. Der logische Baum endet in Blöcken, die in einer Eins-zu-Eins-Entsprechung "Inhalts"-Objekten (logischen Grundobjekten BLOs) entsprechen und die die aktuellen Inhalte der BLOs sind. Die zwei Bäume treffen sich auf der "Blatt"-Ebene, wobei jedes BLO (oder jeder Block) des logischen Baums auch ein End- oder "Blatt"- Element des Layout-Baums ist. Ein einzelnes "Inhalts"-Objekt kann Inhalte von nur einem Typ enthalten - und zwar Text, geometrische Graphiken, Bit-Bild-Graphiken, etc. (Somit wird ein Diagramm typischerweise durch ein "Diagramm"-Objekt derart definiert, als ob es aus einem Objekt für geometrische Graphiken, nämlich einem Titel, und optional einem oder mehreren Kennzeichen bzw. Sprungmarken zum Gelangen in das Diagramm bestehen.)
Die Objekte des logischen Baums, wie sie oben diskutiert sind, definieren die logische Struktur des Dokuments, und jedes Objekt beschränkt die Anzahl, den Typ und die Anordnung der Objekte, die mit ihm direkt unter ihm verbunden sind. Die Layoutobjekte definieren des Layout des Dokuments, und jedes kann Attribute enthalten. Attribute werden durch eine Vorgabe geerbt; somit haben jene Attribute dann, wenn ein Objekt keine Werte für einige Attribute erklärt, die im Objekt erklärten Werte im Baum über ihm. Logische Objekte können auch Attribute enthalten, die die Attribute der Layoutobjekte aufheben, die sonst angewendet wurden. Jedes End-Layoutobjekt definiert das Layout und die Präsentation der Inhalte der mit ihm gekoppelten logischen Objekte.
Die allgemeine Struktur eines ODIF-Dokuments kann somit als doppelter Baum gezeigt werden, wobei Fig. 1 ein vereinfachtes Beispiel ist. Dasselbe Dokument kann alternativ in Tabellenform dargestellt werden, wie es in Tabelle I gezeigt ist. Dies ist weithin die Form, in der das Dokument im Speicher gespeichert ist. Die Tabellenstruktur des Dokuments in dieser Form ist in einer relativ expliziten Weise vorhanden. Tabelle I

CDA-Dokumentenstruktur

Betrachtet man nun CDA/DDIF, ist ein DDIF-Dokument auch allgemein als zwei Bäume von Segmenten strukturiert, und zwar als logischer (oder "Inhalts"-)Baum und als Layout-Baum. Wie bei ODA/ODIF können die logischen Segmente Layout- oder Formatierinformation oder Attribute sowie Inhalte enthalten, und es genügt für gegenwärtige Zwecke, primär die logischen Segmente zu betrachten. Jedes Segment kann Attribute enthalten, und ebenso primitive Inhaltselemente. Wenn ein Segment primitive Inhaltselemente enthält - d.h. Informationsinhalte - dann enthält es auch eine Anzeige für den Typ der Inhalte - d.h., ob die Inhalte Text, geometrische Graphiken, Bit-Bild-Graphiken, etc. sind.
Die allgemeine Struktur eines DDIF-Dokuments kann somit als ein Baum gezeigt werden, wobei Fig. 2 ein vereinfachtes Beispiel ist. Dasselbe Dokument kann alternativ in Tabellenform dargestellt werden, wie es in Tabelle II gezeigt ist. Dies ist weithin die Form, in der das Dokument im Speicher gespeichert ist. (Die Einrükkungen sind natürlich zur Klarstellung seiner logischen Struktur vorgesehen.) Die Baumstruktur ist nur in impliziter Form vorhanden. Tabelle II
Es wird natürlich realisiert werden, daß es viele Merkmale von ODA/ODIF und CDA/DDIF gibt, die hier nicht beschrieben sind. Beispielsweise hat ein Dokument auch einen Dokumentenbeschreiber (der die Version von DDIF identifiziert, die gerade benutzt wird, und die Software, die das Dokument erzeugte), und einen Dokumenten-Anfangsblock (der z.B. den Titel, den Autor, die Versionennummer, das Datum, etc. enthält). Der Dokumenteninhalt kann auch weitere Merkmale enthalten, wie beispielsweise das Segment E für "berechnete Inhalte" der Fig. 2, das Inhalte zur Verfügung stellt, die von irgendeiner äußeren Quelle kopiert werden (irgendwo im Dokument oder von irgendeinem anderen Dokument). Eine Referenz im Text auf die Seitenzahl eines anderen Teils des Dokuments ist ein Beispiel dafür, und die Numerierung von Fußnoten ist ein weiteres.
Es wird realisiert werden, daß dann, wenn ein Dokument in der ODIF- oder der DDIF-Form ist, es in der Form eines Stroms von Daten ist (von denen einige Steuerdaten sind). Obwohl beispielsweise die vollständigen Baumstrukturen natürlich vorhanden sind, sind diese Baumstrukturen implizit und können nur von dem Strom von Daten durch eine geeignete Verarbeitung wiedergewonnen werden. Mechanismen, die Programmierwerkzeuge (toolkits) genannt werden, sind für sowohl ODA/ODIF als auch CDA/DDIF entwickelt worden, die ein Dokument in der ODIF- oder der DDIF-Form analysieren können, um zuzulassen, daß es viel schneller manipuliert bzw. behandelt wird, als es erforderlich wäre, wenn die Kette selbst für jede Operation zu analysieren wäre. Ein derartiges Programmierwerkzeug kann die Attribute eines Dokuments manipulieren, kann aber nicht das Dokument selbst (seine "Inhalte") manipulieren.
Es wird natürlich realisiert werden, daß die Umwandlung eines Dokuments von einem Format zu einem anderen normalerweise in einem Verlust kleinerer Details des Aufbaus des Dokuments resultieren wird. Beispielsweise können die genauen Schriftzeichen und der Bereich der Zeichengrößen in den zwei Systemen unterschiedlich sein. Ein extremeres Beispiel ist gegeben, wenn das Quellendokument ein graphisches Element (eine Zeichnung oder ein Diagramm) mit zugehörigen Textelementen (Kennzeichen für Teile der Zeichnung) enthält. Es ist sehr unwahrscheinlich, daß die Umwandlung die umgewandelten Textelemente automatisch in den richtigen Positionen im umgewandelten graphischen Element anordnen kann; und eher als diese Aufgabe zu versuchen, wird die Umwandlung normalerweise lediglich die Textelemente in eine einfache Liste "ber oder unter dem graphischen Element umwandeln. Ein derartiger Verlust feiner Details ist normalerweise tolerierbar; es wird jedoch allgemein für wesentlich gehalten, daß kein Informationsinhalt (im Gegensatz zu seiner Darstellungsform) bei der Umwandlung verloren werden sollte.
Computer Communications Bd. 12, Nr. 2, S. 69-79: "ODA: a document architecture for open systems" beschreibt das Bürodokumentenarchitekturprotokoll. EP- 0186007 beschreibt ein Verfahren und ein Gerät zum Umsetzen eines Dokuments mit einer Struktur in ein Dokument mit einer anderen Struktur über eine Zwischenstruktur. EP-0214536 beschreibt ein Verfahren zum Erzeugen eines Objektcodes, der eine Übereinstimmung von Eingangsdatenstrukturen in eine zuvor spezifizierte Ausgangsdatenstruktur darstellt, so daß Daten in der Eingangsstruktur zur Laufzeit in die Ausgangsstruktur eingebettet werden können. Computer Communications Bd. 12, Nr. 2, S. 102-106: "Conformance testing of Office Document Architecture" beschreibt Techniken zum Testen einer Übereinstimmung von standardmäßigen Dokumentenaustauschformaten.

Aufgabe der Erfindung

Es ist die allgemeine Aufgabe der Erfindung, eine verbesserte Einrichtung zum Umwandeln von Dokumenten in einer CDA-artigen Form in eine ODA-artige Form zu schaffen.

Zusammenfassung der Erfindung

Die vorliegende Erfindung schafft ein Datenstrukturformat-Umwandlungssystem nach Anspruch 1.
Dieser Aspekt des vorliegenden Umwandlungssystems sorgt somit für die Umwandlung zusammengesetzter Dokumente, wo eine wohldefinierte Untergruppe der gesamten Architektur des zusammengesetzten Dokuments zum Repräsentieren einer einzelnen Gruppe von zusammengesetzten Dokumenten verwendet wird. In diesem Fall wird die Untergruppe der gesamten Architektur für ein zusammengesetztes Dokument "Profil" genannt. Ein Profil identifiziert daher, welche Teile der gesamten Architektur für ein zusammengesetztes Dokument zum Repräsentieren dieser Untergruppe von Dokumenten benutzt werden darf. Es identifiziert die Attribute (und ihre Werte), die innerhalb zusammengesetzter Dokumente definiert werden können, die mit dem Profil übereinstimmen. Es kann auch Beschränkungen bezüglich der Komplexität der logischen Strukturen und/oder der Layoutstrukturen definieren, die durch jene zusammengesetzten Dokumente definiert sind.
Diese Architektur läßt zu, daß das System so entwickelt wird, daß weitere Profil- und/oder Inhaltsarchitekturumwandlungskomponenten schnell hinzugefügt werden können, ohne daß eine Modifikation der existierenden Komponenten des Systems nötig ist.
Die vorliegende Erfindung kann eine Strukturarchitektur-Umwandlungskomponente zum Erzeugen logischer Objekte der Solldokumentenarchitektur enthalten, die folgendes aufweist: eine Struktur-Wandlereinheit zum Erzeugen zusammengesetzter logischer Objekte des Solldokuments und eine Vielzahl von Rückrufeinheiten, die jeweils zum Erzeugen eines unterschiedlichen Typs eines grundlegenden logischen Objekts oder einer Gruppe von logischen Objekten einschließlich wenigstens eines grundlegenden logischen Objekts dienen; eine Vielzahl von Inhaltsarchitektur-Umwandlungskomponenten, die jeweils zum Umwandeln von einem der möglichen Datentypen des Inhalts des Quellendokuments in das Sollformat dienen, die jeweils von den anderen und von den Einheiten der Strukturarchitektur- Umwandlungskomponente aufrufbar sind und jeweils zu einer beliebigen einer entsprechenden Gruppe der Rückrufeinheiten zurückrufen können, um eine Umwandlung miteinander vermischter Inhaltstypen im Quellendokument zu bewirken.
Es ist für einen Inhalt unterschiedlicher Typen möglich, daß er innerhalb eines zusammengesetzten Dokuments vermischt ist. Dieser Aspekt der vorliegenden Erfindung sorgt für ein System von Rückrufen, um diese Situation zu behandeln. Wenn herausgefunden wird, daß ein Inhalt eines ersten Typs einen Inhalt eines zweiten Typs in sich eingebettet hat, wird die Umwandlungskomponente für den ersten Typ unfähig werden, den Inhalt des zweiten Typs umzuwandeln. Sie wird daher einen Rückruf zur Profil-Umwandlungskomponente durchführen. In Antwort darauf ruft die Profil-Umwandlungskomponente die Inhalts-Umwandlungskomponente für den zweiten Typ eines Inhalts auf, und diese Inhalts-Umwandlungskomponente führt dann die nötige Umwandlung durch, und dann, wenn diese Umwandlung beendet ist, kehrt sie zur Profil-Umwandlungskomponente zurück. Die Profil- Umwandlungskomponente erkennt, daß eine Rückrufverarbeitung durchgeführt wurde, und bringt daher eine Verarbeitung zur Umwandlungskomponente vom ersten Inhaltstyp zurück.

Detaillierte Beschreibung

Ein Umwandlungssystem, das die Erfindung verkörpert, wird nun anhand eines Beispiels unter Bezugnahme auf die Zeichnungen beschrieben, wobei:
Fig. 1 und 2 Blockdiagramme sind, die jeweils die allgemeine Struktur eines ODA- Dokuments und eines CDA-Dokuments darstellen;
Fig. 3 ein allgemeines Blockdiagramm des gegenwärtigen Wandlers ist;
Fig. 4 ein detaillierteres Blockdiagramm von Teilen des gegenwärtigen Wandlers ist; und
Fig. 5 und 6 Blockdiagramme sind, die die Umwandlung von Teilen von zwei ODA-Dokumenten in entsprechende CDA-Dokumente durch den gegenwärtigen Wandler darstellen.
Das gegenwärtige Umwandlungssystem trennt die Umwandlung der Inhaltstypen (Architekturen) innerhalb der zusammengesetzten Dokument von der Umwandlung der logischen Struktur und der Layoutstruktur innerhalb jener Dokumente. Es ist aus einer Anzahl einzelner Umwandlungskomponenten aufgebaut, einschließlich einer Haupt-Umwandlungskomponente, Profil-Umwandlungskomponenten und Inhaltsarchitektur-Umwandlungskomponenten. Die Profil-Umwandlungskomponenten und Inhalts-Umwandlungskomponenten werden durch Namen entsprechend den Profil- oder Inhaltsarchitekturnamen identifiziert. Das System sorgt für das Hinzufügen von zusätzlichen Profil-Umwandlungskomponenten und Inhalts- Umwandlungskomponenten als neue Profile, und Inhaltsformat- Umwandlungskomponenten werden entwickelt. Diese Hinzufügungen können bewirkt werden, ohne daß es nötig ist, daß irgendwelche Änderungen bezüglich der anderen (existierenden) Umwandlungskomponenten des Systems durchzuführen sind.
Die Haupt-Umwandlungskomponente führt die Funktion eines Identifizierens des Profils durch, mit dem das zusammengesetzte Dokument übereinstimmt, und die Auswahl und den Aufruf der Profil-Umwandlungskomponente. (Wenn ein zusammengesetztes Dokument ein Profil spezifiziert und eine Profil- Umwandlungskomponente für jenes Profil im System nicht existiert, wird ein Fehler zum Aufrufsystem berichtet und die Umwandlung wird abgebrochen.) Die Profil- Umwandlungskomponente wird dann mit dem Verarbeiten und der Umwandlung der logischen Struktur und der Layoutstruktur innerhalb des Dokuments fortfahren, das gerade umgewandelt wird. Wenn ein Inhalt innerhalb eines zusammengesetzten Dokuments angeordnet ist, das gerade umgewandelt wird, wird die Inhaltsarchitektur, zu der der Inhalt gehört, identifiziert, und die entsprechende Inhaltsarchitektur-Umwandlungskomponente wird aufgerufen, um die Umwandlung durchzuführen.
Es ist für einen Inhalt unterschiedlicher Typen möglich, daß er innerhalb eines zusammengesetzten Dokuments vermischt ist. Das vorliegende System schafft ein System von Rückrufen zum Handhaben dieser Situation. Wenn herausgefunden wird, daß ein Inhalt eines ersten Typs einen Inhalt eines zweiten Typs in sich eingebettet hat, wird die Umwandlungskomponente für den ersten Typ unfähig gemacht, den Inhalt des zweiten Typs umzuwandeln. Sie wird daher einen Rückruf zur Profil-Umwandlungskomponente durchführen. In Antwort darauf ruft die Profil- Umwandlungskomponente die Inhalts-Umwandlungskomponente für den zweiten Typ eines Inhalts auf, und diese Inhalts-Umwandlungskomponente führt dann die nötige Umwandlung durch, und springt dann, wenn diese Umwandlung beendet ist, zur Profil-Umwandlungskomponente zurück. Die Profil-Umwandlungskomponente erkennt, daß eine Rückrufverarbeitung durchgeführt wurde und bringt daher eine Verarbeitung zur Umwandlungskomponente des ersten Inhaltstyps zurück.
Fig. 3 ist ein Blockdiagramm des Umwandlungssystems zum Umwandeln eines DDIF-Dokuments in eine ODIF-Form. von dem DDIF-Dokument kann angenommen werden, daß es in einer CDA-Wandler-Kerneleinheit 15 gespeichert ist, die mit einer ODA FEBE-(Vorderes Ende-Hinteres Ende)-Hauptkomponente 14 gekoppelt ist. Eine Gruppe von Strukturhandhabungseinheiten 12 ist mit der FEBE-Einheit 14 gekoppelt, und eine Gruppe von Inhaltshandhabungseinheiten 13 ist mit den Strukturhandhabungseinheiten 12 gekoppelt. Diese Einheiten 12 und 13 führen zusammen die wesentlichen Aspekte zum Erzeugen des geforderten ODIF- Dokuments durch, das zu einer ODA-Toolkit-Einheit 11 weitergeleitet wird, welche wiederum mit einer ODA-Dokumenteneinheit 10 gekoppelt ist.
Die Prinzipien eines Betriebs der zwei Komponenten 14 und 15 sind in der US- Anmeldung mit der Seriennr. 07/368697, eingereicht am 19. Juni 1989, mit der DEC ref PD89-0139, beschrieben, und sind hier daher nicht gezeigt. Es kann jedoch angemerkt werden, daß an den CDA-Umwandlungskernel 15 eine CDA- Toolkiteinheit (analog zur ODA-Toolkiteinheit 11), eine DDIF-Dokumenteneinheit und möglicherweise eine DTIF-(Dokumententabellen-Austauschformat)- Dokumenteneinheit gekoppelt ist. Die Details der DDIF- und DTIF-Einheiten und/oder der Struktur der in ihnen gespeicherten Daten ist in den zwei weiteren US-Anmeldungen mit den Seriennr. 07/368703 und 368716, die gleichzeitig mit der PD89-0137 eingereicht wurden, und die DEC-Referenzen PD89-0138 und PD89- 0139 haben, beschrieben.
Die Toolkits bzw. Programmierwerkzeuge arbeiten zum Analysieren der zugehörigen Dokumente (zum Identifizieren der verschiedenen Segmente und anderer Merkmale der Dokumente), um aus den Dokumenten die verschiedenen Komponenten jenes Dokuments zu extrahieren und um die Dokumente allgemein zu manipulieren. Die Dokumente sind allgemein in Formen gespeichert, die für eine vernünftige effiziente Speicherung geeignet sind, und die Tookits sorgen allgemein für eine Schnittstelle, die die organisatorischen und strukturellen Aspekte der Dokumente zeigt.
Der ODA/ODIF-Standard ist natürlich sehr aufwendig, und viele seiner Benutzer benötigen nicht den vollständigen Bereich der ODA/ODIF-Möglichkeiten. Bestimmte Untergruppen des vollständigen ODA/ODIF-Standards sind daher entwickelt worden; diese sind als DAPs (Dokumentenanwendungsprofile) bekannt. Diese Untergruppen können grob in Ebenen eingeteilt werden. Eine Ebene 1 ist eine einfache Textmanipulation; eine Ebene 2 ist eine einfache Textverarbeitung (mit einer Seitennumerierung und einer sehr durchdachten logischen Struktur); eine Ebene 3 ist eine komplexe Textverarbeitung und Desktop-Publishing (mit komplexen Layouts, Schriftarten und einem Drucken, Diagrammen, etc.); und eine Ebene 4 ist ein vollständiger ODA/ODIF. Drei spezifische DAPs sind als Q111, Q112 und Q121 bekannt.
Es gibt daher eine Vielzahl von Strukturhandhabungseinheiten 12, die auch DAP- Handhabungseinheiten genannt werden. Eine Anfangsbestimmung wird diesbezüglich durchgeführt, mit welchem der DAPs das Dokument in Übereinstimmung gebracht werden soll, und wählt die geeignete DAP-Handhabungseinheit demgemäß aus. Dies resultiert in einer größeren Effizienz, wenn die DAP-Ebene niedrig ist.
Wie es oben diskutiert ist, gibt es verschiedene Typen oder Meterklassen von Inhalten; solche Typen können beispielsweise Text, Rastergraphiken und geometrische Graphiken aufweisen. Es gibt eine Vielzahl von Inhalts- Handhabungseinheiten 13 (die auch Inhaltsarchitektur-Handhabungseinheiten genannt werden), und zwar eine für jeden Typ, um die Umwandlung von Inhalten von entsprechenden Typen durchzuführen.
Es wird realisiert werden, daß das System durch das Hinzufügen von weiteren DAP-Wandlern erweitert werden kann, wenn weitere DAPs in der Zukunft entwikkelt werden, und auch durch das Hinzufügen von weiteren Inhaltsarchitektur- Handhabungseinheiten, wenn die möglichen Inhalts-Metaklassen in Zukunft erweitert werden.
Zum Durchführen der Umwandlung des CDA-Dokuments in eine ODA-Form ist seine Struktur (primär seine Segmentierung) zu analysieren und die verschiedenen Inhaltskomponenten von ihm zu konvertieren, und die geeigneten Objekte von dem ODA-Dokument zu erzeugen, das gerade erzeugt wird. Die ausgewählte DAP- Handhabungseinheit und die Inhaltsarchitektur-Handhabungseinheiten kooperieren beim Analysieren der Struktur des CDA-Dokuments; die verschiedenen Inhaltsarchitektur-Handhabungseinheiten führen die Umwandlung der verschiedenen Inhaltskomponenten des CDA-Dokuments durch; und die ausgewählte DAP- Handhabungseinheit erzeugt die Objekte des ODA-Dokuments.
Fig. 4 ist ein detaillierteres Blockdiagramm einer typischen DAP- Handhabungseinheit und zugehöriger Inhaltsarchitektur-Handhabungseinheiten. Wenn ein Dokument umzuwandeln ist, wird eine der Gruppe von DAP- Handhabungseinheiten ausgewählt. Daher ist eine einzelne DAP- Handhabungseinheit 12-1 gezeigt. Es ist angenommen, daß es ein DAP ist, das drei Typen von Inhalten zuläßt, nämlich Text TEXT, geometrische Graphiken GG und Rastergraphiken RG. Daher sind drei jeweilige Inhaltsarchitektur- Handhabungseinheiten 13-1 bis 13-3 gezeigt.
Beim Prozeß zum Umwandeln eines CDA-Dokuments in ein ODA-Dokument sind die verschiedenen Objekte und Blöcke des ODA-Dokuments zu bilden. Jedes Objekt hat eine Struktur mit ihrer Identifikation und Verbindungen zu anderen Objekten und ihrem Inhaltsblock (wenn es einen gibt). Beim Umwandlungsprozeß ist es oft nötig, mehrere Objekte gleichzeitig im Aufbauprozeß zu halten. Die DAP- Handhabungseinheit 12 enthält daher einen Objektspeicher 20, in dem Objekte im Aufbauprozeß gehalten werden können. Dieser Speicher ist ein Stapelspeicher, da tatsächlich dann, wenn einmal der Aufbau eines neuen Objekts begonnen hat, keine Änderungen an früheren Objekten durchgeführt werden müssen, die noch aufgebaut werden, bis der Aufbau des letzten Objekts beendet worden ist.
Es ist für Zwecke der gegenwärtigen Beschreibung angenehm, anzunehmen, daß die Objekte im Speicher 20 vollständig assembliert sind. Jedoch wird es realisiert werden, daß ihre Assemblierung tatsächlich durch die Einheiten 14 und 15 beendet werden kann; diese können für jeden Zweck ein Programmierwerkzeug (Toolkit) enthalten, das dem Toolkit der Einheit 11 entspricht. Wenn ein Objekt Inhalte hat, werden diese Inhalte durch eine der Inhalts-Handhabungseinheiten 13 erzeugt.
Die DAP-Handhabungseinheit 12 enthält eine Struktur-Umwandlungskomponente 21, die die Struktur des ankommenden CDA-Dokuments analysiert und die Erzeugung der geeigneten zusammengesetzten logischen ODA-Objekte initiiert. Sie enthält auch eine Vielzahl von Rückruf-Verarbeitungseinheiten TEXT 22-1, GG 22-2, RG 22-3 und FN 22-4 zur jeweiligen Verarbeitung von Text, geometrischen Graphiken, Rastergraphiken und Fußnoten. Die Rückrufeinheiten werden durch die Inhalts-Handhabungseinheiten aufgerufen und erzeugen die geeigneten logischen Objekte, die zum Unterbringen des geänderten Typs eines Inhalts nötig sind, was die Objekte zurück nach unten zu den geeigneten Inhalts-Handhabungseinheiten für die Umwandlung der Informationsinhalte (Text, Graphiken, etc.) führt.
Einige Segmente in einem CDA-Dokument enthalten nur einen Inhalt eines einzigen Typs. Der Umwandlungsprozeß für ein derartiges Segment ist relativ einfach. Die Struktur-Umwandlungskomponente 21 identifiziert den Typ der Inhalte und leitet das Segment zur geeigneten Inhalts-Handhabungseinheit 13 weiter. Die ausgewählte Inhalts-Handhabungseinheit 13 wandelt den Inhalt des zu ihr weitergeleiteten Segments um. Wenn einmal die Inhaltsumwandlung beendet ist, verwendet die Inhalts-Handhabungseinheit den Rückrufmechanismus zum Identifizieren, wo der Inhalt gespeichert werden soll. Wenn der Inhalt beispielsweise ein Textinhalt ist, ruft die Inhalts-Handhabungseinheit 13-1 zurück zur Text-Rückrufeinheit 22-1 in der DAP-Handhabungseinheit. Die Text-Rückrufeinheit 22-1 erzeugt dann ein grundlegendes logisches Objekt (BLO) des Texttyps und speichert es zum letzten CLO auf dem Stapel 20. Die Text-Rückrufeinheit 22-1 bringt dann dieses neue BLO zur Textinhalts-Handhabungseinheit 13-1 zurück, die dann den umgewandelten Inhalt zum neuen BLO speichert.
Wie es oben angegeben ist, werden die Blöcke selbst im Speicher 20 angehäuft. Jedoch werden die Blöcke durch Zeiger zu ihnen von den Inhalts- Handhabungseinheiten, den Rückrufeinheiten und dem Stapel 20 identifiziert. Somit enthält ein "Erzeugen eines BLO und ein Speichern von ihm zu einem CLO" ein Erzeugen des BLO und ein Eingeben von Verbindungen zum neu erzeugten BLO in das CLO; und ein "Speichern eines Inhalts zu einem BLO" enthält ein Anordnen des BLO und ein Eingeben des Inhalts dort hinein.
Die Verarbeitung einer Folge von Elementen desselben Typs in einem einzelnen Segment ist ähnlich. Was hier passiert ist, besteht darin, daß deshalb, weil aufeinanderfolgenden Elementen des Textsegments begegnet wird, ihre Inhalte durch die Textinhalts-Handhabungseinheit 13-1 umgewandelt werden, und Blöcke durch die Textrückrufeinheit 22-1 erzeugt werden, damit sie die umgewandelten Textelemente enthalten.
Es ist somit klar, daß bei dem bislang beschriebenen vorliegenden System die Verarbeitung der Struktur oder des Layouts des Dokuments von der Verarbeitung seiner Inhalte streng getrennt ist. Die Verarbeitung der Struktur oder des Layouts wird ausschließlich durch die ausgewählte DAP-Handhabungseinheit durchgeführt, wobei die verschiedenen Blöcke durch den Strukturwandler und die verschiedenen Rückrufeinheiten erzeugt werden. Die Verarbeitung der Inhalte wird ausschließlich durch die Inhaltsarchitektur-Handhabungseinheiten durchgeführt, und die Verarbeitung jedes Typs von Inhalten wird ausschließlich durch die Inhaltsarchitektur- Handhabungseinheit für jenen Typ durchgeführt. Diese Prinzipien werden bei den komplizierteren Situationen beibehalten, die unten beschrieben sind.
In den bislang diskutierten Situationen hat es eine genaue Entsprechung zwischen den zwei Systemen (ODA/ODIF und CDA/DDIF) gegeben. Jedoch gibt es Situationen, in welchen diese Entsprechung durchbrochen wird und das Umwandlungssystem mit diesen Situationen fertig werden muß. Dies wird durch wiederholte Übertragungen einer Steuerung zwischen den Rückrufeinheiten und den Inhalts- Handhabungseinheiten erreicht. Wenn das Ende eines bestimmten Typs eines Inhalts erreicht ist, bringt die Inhalts-Handhabungseinheit eine Steuerung zu der Einheit zurück, die sie aufrief. Wenn es mehrere des ursprünglichen Typs von Inhalten gibt, dann fährt die Inhalts-Handhabungseinheit mit dem Umwandlungsprozeß fort, wobei mehrere Blöcke durch die Rückrufeinheit erzeugt werden. Wenn es nicht so ist, bringt die Inhalts-Handhabungseinheit eine Steuerung zurück zur Inhalts- Handhabungseinheit, die sie aufrief, oder dann, wenn sie nicht durch eine Inhalts- Handhabungseinheit aufgerufen wurde, zur Struktur-Umwandlungskomponente 21.
Zum Nehmen eines spezifischen Beispiels kann in CDA/DDIF ein Textsegment Inhalte für geometrische Graphiken und/oder Raster-(Bild)-Graphiken enthalten. (Ein Segment für geometrische Graphiken kann gleichermaßen Inhalte für ein Bild enthalten.) Ein ODA/ODIF-BLO (grundlegendes logisches Objekt (oder grundlegendes Layoutobjekt)) kann jedoch nur einen einzigen Typ eines Inhalts enthalten.
Wenn die DAP-Handhabungseinheit 12 einem Textsegment begegnet, leitet sie den Textinhalt zur Textinhalts-Handhabungseinheit 13-1 weiter, die damit beginnt, den Inhalt zu lesen. Wenn nachfolgenden Textelementen des Segments begegnet wird, werden sie durch die Text-Handhabungseinheit 13-1 umgewandelt. Zum Speichern dieses umgewandelten Inhalts ruft die Textinhalts-Handhabungseinheit 13-1 die Textrückrufeinheit 22-1 auf, um nach einem BLO zu fragen, in dem der umgewandelte Inhalt gespeichert werden kann. Die Rückrufeinheit 22-1 erzeugt ein BLO und speichert es zum letzten CLO auf dem Stapel 20 und leitet dann das neue BLO zurück zur Textinhalts-Handhabungseinheit 13-1. Die Textinhalts- Handhabungseinheit 13-1 speichert dann den umgewandelten Textinhalt zum neuen BLO.
Wenn die Textinhalts-Handhabungseinheit einem Segment mit geometrischen Graphiken begegnet, das innerhalb des Textsegments gespeichert ist, kann die Textinhalts-Handhabungseinheit es nicht behandeln. Die Textinhalts- Handhabungeinheit speichert irgendeinen Text, der bereits umgewandelt ist, durch Fragen nach einem BLO von der Rückrufeinheit 22-1 und durch Speichern des Inhalts zu ihm, und ruft dann die GG-Inhalts-Handhabungseinheit 13-2 auf und leitet das Segment mit geometrischen Graphiken zu ihr weiter. Die GG-Inhalts- Handhabungseinheit 13-2 beginnt dann, den Inhalt für geometrische Graphiken umzuwandeln. Wenn die GG-Inhalts-Handhabungseinheit 13-2 eine Umwandlung des Inhalts beendet hat, verwendet sie den Rückrufmechanismus zum Rückrufen zur (Weiterleiten einer Steuerung zur) GG-Rückrufeinheit 22-2. Die Rückrufeinheit 22-2 erzeugt ein BLO für einen Inhalt mit geometrischen Graphiken und speichert es zum letzten CLO auf dem Stapel 20 und leitet das neue BLO zur GG-Inhalts- Handhabungseinheit 13-2 weiter, die dann den umgewandelten Inhalt zum neuen BLO speichert. Da die GG-Inhalts-Handhabungseinheit 13-2 nun die Inhaltsumwandlung des Segments mit geometrischen Graphiken beendet hat, bringt sie dann eine Steuerung zur Textinhalts-Handhabungseinheit 13-1 zurück, die sie ursprünglich aufrief. Die Textinhalts-Handhabungseinheit 13-1 nimmt dann wieder eine Verarbeitung des übrigen Textinhalts im Textsegment auf.
Dieser Prozeß ist durch Fig. 5 dargestellt. Der linke Teil dieser Figur zeigt einen Teil eines CDA-Dokuments, der aus einem Durchflußsegment DURCHFLUSS besteht, das ein Absatzsegment P1 enthält, das wiederum einen Textinhaltsteil txt1 enthält, wobei ein verschachteltes Element einen Inhaltsteil mit geometrischer Graphik GeoG enthält, und einen weiteren Textinhaltsteil txt2. Das entsprechende ODA-Dokument ist rechts gezeigt und besteht aus einer (Text)Stelle CLO (verbundenem logischen Objekt) (TEXT)STELLE, die einen Absatz CLO PARA enthält, der wiederum drei BLOs TEXT, GEOM und TEXT enthält, die jeweils den Textinhaltsteil txt1, den Inhaltsteil mit geometrischer Graphik GeoG und den Textinhaltsteil txt2 enthält. (Es ist bequem, dieselben Ausdrücke für die Inhaltsteile sowohl im CDA- als auch im ODA-Format zu verwenden.)
Die (TEXT)STELLE und PARA CLOs in der Figur sind Strukturelemente, die durch die Struktur-Umwandlungskomponente für die DAP-Handhabungseinheit erzeugt werden. Die TEXT und GEOM BLOs in der Figur werden durch die Textrückrufeinheit 22-1 und die GG-Rückrufeinheit 22-2 bei der Anfrage der Textinhalts- Handhabungseinheit bzw. der GG-Inhalts-Handhabungseinheit erzeugt. Die verschiedenen Inhalte - txt1, GeoG und txt2 - werden durch die Inhalts- Handhabungseinheiten zu den BLOs gespeichert. Dieser Prozeß ist ausführlicher in den folgenden Absätzen beschrieben.
Beim Umwandlungsprozeß wird das CDA-Dokument anfangs durch die Struktur- Umwandlungskomponente 21 verarbeitet. Diese begegnet zuerst dem Segment (TEXT)FLUSS und erzeugt das entsprechende Objekt (TEXT)STELLE. Da das Objekt (TEXT)STELLE eine Unterstruktur haben wird, ist es ein CLO, und es wird daher in den Stapel 20 eingegeben, um die Erzeugung der abhängigen Objekte zu erwarten. Die Struktur-Umwandlungskomponente 21 begegnet als nächstes dem Segment P1 und erzeugt das entsprechende Objekt PARA, das auch ein CLO ist und in den Stapel 20 eingegeben wird.
Die Struktur-Umwandlungskomponente 21 begegnet als nächstes dem ersten Inhaltselement des Segments P1 und findet heraus, daß es vom Texttyp ist. Sie ruft daher die Textinhalts-Handhabungseinheit 13-1 auf und leitet das Segment zu ihr weiter. Die Textinhalts-Handhabungseinheit identifiziert das erste Inhaltselement txt1 und wandelt es um. Sie identifiziert dann das nächste Inhaltselement des Segments als ein Segment SEG1 mit einem Inhalt mit geometrischer Graphik. Die Textinhalts-Handhabungseinheit 13-1 hat daher eine Steuerung aufzugeben.
Bevor sie dies macht, ruft sie die Textrückrufeinheit 22-1 auf, die ein BLO vom Texttyp (TEXT) erzeugt und es zum letzten CLO (dem PARA) auf dem Stapel 20 speichert. Die Textrückrufeinheit 22-1 bringt dann das neu erzeugte BLO zur Textinhalts-Handhabungseinheit 13-1 zurück. Die Textinhalts-Handhabungseinheit 13- 1 speichert dann den umgewandelten Text txt1 zum neuen BLO. Dann ruft die Textinhalts-Handhabungseinheit 13-1 die GG-Inhalts-Handhabungseinheit 13-2 auf und leitet SEG1 zu jener Inhalts-Handhabungseinheit weiter.
Nun hat die GG-Inhalts-Handhabungseinheit 13-2 die Steuerung und beginnt ein Lesen des Inhalts von SEG1. Sie identifiziert den Inhalt GeoG und wandelt ihn um. Wenn sie das Ende des Inhalts von SEG1 erreicht, ruft die GG-Inhalts- Handhabungseinheit die GG-Rückrufeinheit 22-2 auf. Die GG-Rückrufeinheit 22-2 erzeugt ein BLO vom geometrischen Typ (GEOM) und speichert es zum letzten CLO (PARA) auf dem Stapel 20. Die GG-Rückrufeinheit 22-2 bringt dann das neue BLO zur GG-Inhalts-Handhabungseinheit 13-2 zurück. Die GG-Inhalts- Handhabungseinheit 13-2 speichert dann den umgewandelten Inhalt GeoG zum neuen BLO. Schließlich bringt sie die Steuerung zu der Komponente zurück, die sie aufrief - nämlich zur Textinhalts-Handhabungseinheit 13-1.
Die Textinhalts-Handhabungseinheit hat nun die Steuerung wiedergewonnen und macht mit einem Fortfahren eines Lesens des Inhalts von P1 weiter. Als Ergebnis findet sie das nächste Element txt2 und identifiziert es als ein weiteres Textelement. Die Textinhalts-Handhabungseinheit 13-1 wandelt txt2 um und ruft dann wie zuvor die Textrückrufeinheit 22-1 auf. Die Textrückrufeinheit 22-1 erzeugt ein weiteres BLO vom Texttyp (TEXT) und speichert es zum CLO PARA auf dem Stapel 20. Sie bringt dann das neue BLO zur Textinhalts-Handhabungseinheit 13-1 zurück, die den umgewandelten Inhalt txt2 zum neuen BLO speichert.
Die Textinhalts-Handhabungseinheit 22-1 erkennt dann, daß sie das Ende des Inhalts von P1 erreicht hat, und kehrt somit zur Struktur-Umwandlungskomponente 21 zurück, die sie ursprünglich aufrief. Die Struktur-Umwandlungskomponente 21 erkennt dann, daß sie die Verarbeitung der Segmente P1 beendet hat und sie entfernt somit das CLO PARA vom Stapel und speichert es zum nächsten (jetzt letzten) CLO (dem FLUSS) auf dem Stapel 20 und geht weiter zum nächsten Segment, das unter FLUSS gespeichert ist.
Offensichtlich würde die Textinhalts-Handhabungseinheit 13-1 dann, wenn das Segment P1 nur txt1 und SEG1 mit Geog enthalten hätte, sofort zur Struktur- Umwandlungskomponente 21 zurückgekehrt sein, nachdem die GG-Inhalts- Handhabungseinheit 13-2 eine Verarbeitung (bei der das BLO GEOM beendet wird) beendet hatte und zur Textinhalts-Handhabungseinheit 13-1 zurückgekehrt war.
Der Betrieb der Rastergraphik-(RG)-Rückrufeinheit 22-2 ist ähnlich. Wenn irgendeine andere Komponente - die Struktur-Umwandlungskomponente, die Textinhalts- Handhabungseinheit oder die GG-Inhalts-Handhabungseinheit - ein Segment mit Rastergraphik identifizieren würde, dann wird die RG-Inhalts-Handhabungseinheit aufgerufen, und das Segment mit Rasterinhalt wird zu ihr weitergeleitet. Die RG- Inhalts-Handhabungseinheit 13-3 wandelt den Inhalt um und ruft die RG- Rückrufeinheit 22-3 auf, die ein BLO vom Rastertyp erzeugt und es zum ODA- Dokument speichert. Die RG-Rückrufeinheit 22-3 bringt das neue BLO zur RG- Inhalts-Handhabungseinheit 13-3 zurück, die den umgewandelten Inhalt zum neuen BLO speichert und dann zu der Komponente zurückkehrt, die sie aufrief.
Der Betrieb der Fußnoten-Rückrufeinheit 22-4 ist etwas komplizierter. Eine Fußnote ist tatsächlich eine Struktur, die innerhalb eines Textinhalts auftritt, so daß ein Rückruf dafür vorgesehen ist, der DAP-Handhabungseinheit die Steuerung der Strukturverarbeitung zu erlauben.
Fig. 6 stellt dar, wie Fußnoten behandelt werden. Eine Fußnote besteht aus einem Fußnotentext txta, der der aktuelle Fußnotenkörper ist, einem Fußnotenreferenztext txtb, der im Körper des Haupttextes erscheint, und einem Fußnotenidentifizierertext txtc, der die entsprechende Referenz ist, die gegenüber dem Fußnotenkörper erscheint. Die Fußnote wird allgemein zwischen zwei aufeinanderfolgenden Teilen des Textes txt1 und txt2 enthalten sein. Es wird realisiert werden, daß die Textinhaltsteile txta (der im Hauptkörper des Textes zwischen den Textteilen txt1 und txt2) und txtb identisch sind. Weiterhin sind diese Inhaltsteile eher berechnete Inhalte als explizite Inhalte; anders ausgedrückt werden die Werte dieser Textteile durch das System eher wie Seitennummern berechnet werden, als daß die aktuellen Werte explizit eingegeben werden.
In einem CDA-Dokument besteht die Fußnotenstruktur selbst aus einem Fußnotenreferenzsegment FNLABEL mit dem Fußnotenreferenztext txta und einem Fußnotensegment FN mit einem Fußnotenidentifiziereruntersegment FNID mit dem Text txtb und einem Fußnotentext-Untersegment PARA mit dem Fußnotentext txtc. Im entsprechenden ODA-Dokument erscheint die Fußnote als ein Objektbaum eines CLO-FUSSNOTE mit einem BLO FNREF mit angebrachtem Text txta und eines weiteren CLO FNBODY, das wiederum zwei BLOs hat, und zwar FNNO mit angebrachten Fußnotenidentifizierertext txtb und FNTEXT mit angebrachtem Fußnotenkörpertext txtc.
Wenn die Textinhalts-Handhabungseinheit 13-1 der Fußnote begegnet, d.h. der Kombination aus FNLABEL plus FN, ruft sie die Fußnoten-Rückrufeinheit 22-4 auf und leitet die Fußnote zu ihr weiter. Die Rückrufeinheit 22-4 erzeugt dann ein CLO FUSSNOTE und speichert es auf dem Stapel 20. Die Einheit 22-4 erzeugt dann ein BLO FNREF und speichert es zum CLO FUSSNOTE. Da der Inhalt der Fußnotenreferenz ein berechneter Inhalt ist, sind die geeigneten Attribute zum Berechnen des Inhalts am BLO FNREF definiert. Weil der Textinhaltsteil txta ein berechneter Inhalt ist, muß er nicht umgewandelt werden.
Die Rückrufeinheit 22-4 erzeugt als nächstes den Fußnotenkörper CLO FNBODY und speichert es zum Stapel 20. Sie erzeugt als nächstes die Fußnotennummer BLO FNNO und speichert sie zum CLO FNBODY; der Textinhaltsteil txtb muß nicht umgewandelt werden, da er wie txta ein berechneter Inhalt ist.
Die Fußnoten-Rückrufeinheit 22-4 identifiziert dann den Inhalt des Segments PARA als Text und ruft daher die Textinhalts-Handhabungseinheit 13-1 zum Umwandeln des Inhalts auf. Dieser Aufruf ist rekursiv; d.h. es ist ein neuer Aufruf zur Textinhalts-Handhabungseinheit, von welcher die Rückkehr zur Fußnoten- Rückrufeinheit erfolgen wird. Es ist keine Rückkehr zur Textinhalts- Handhabungseinheit zur Fußnoten-Rückrufeinheit.
Die Textinhalts-Handhabungseinheit verarbeitet dann den Textinhalt des Segments PARA durch ihren normalen Betrieb und der Inhalt txtc wird umgewandelt. Die Textinhalts-Handhabungseinheit ruft dann die Textrückrufeinheit 22-1 auf, die ein BLO FNTEXT erzeugt und es zum CLO FNBODY auf dem Stapel 20 speichert. Das BLO FNTEXT wird dann durch die Textrückrufeinheit zur Textinhalts- Handhabungseinheit 13-1 zurückgebracht, die das umgewandelte txtc zum neuen BLO speichert und eine Steuerung zur Fußnoten-Rückrufeinheit 22-4 zurückbringt (wodurch der rekursive Aufruf zur Textinhalts-Handhabungseinheit endet).
An dieser Stelle ist die Fußnotenverarbeitung beendet, so daß die Fußnoten- Rückrufeinheit 22-4 das CLO FNBODY vom Stapel 20 entfernt und es zum CLO FUSSNOTE auf dem Stapel 20 speichert, der gerade durch das Entfernen des CLO FNBODY freigelegt worden ist. Dann entfernt die Fußnoten-Rückrufeinheit das CLO FUSSNOTE vom Stapel 20 und speichert es zum vorherigen CLO (einem PARA) auf dem Stapel 20. Schließlich bringt die Fußnoten-Rückrufeinheit die Steuerung zur Text-Inhalts-Handhabungseinheit zurück, die dann mit einer Verarbeitung von txt2 auf die normale Weise fortfährt.
Betrachtet man die Beziehungen zwischen den Inhalts-Handhabungseinheiten und den Rückrufeinheiten allgemeiner, werden diese durch die DAP- Handhabungseinheit bestimmt. Jede Inhalts-Handhabungseinheit ist mit einer bestimmten zugelassenen Gruppe von Rückrufen durch die DAP- Handhabungseinheit ausgestattet, und dann, wenn es erforderlich ist, daß eine Inhalts-Handhabungseinheit eine weitere Inhalts-Handhabungseinheit aufruft, wird sie darauffolgend dieselbe Gruppe von Rückrufen durchlaufen, die sie von der DAP-Handhabungseinheit empfing. Aber jede Inhalts-Handhabungseinheit kann nur ihren eigenen Typ von Rückrufeinheiten aufrufen - somit kann die Textinhalts- Handhabungseinheit 13-1 nur die Text- und Fußnoten-Rückrufeinheiten 22-1 und 22-4 aufrufen, die Handhabungseinheit 13-2 für einen Inhalt mit geometrischer Graphik kann nur die Rückrufeinheit 22-2 für geometrische Graphik aufrufen, etc.
Jedoch kann die zulässige Gruppe von Rückrufen unter verschiedenen Umständen geändert werden, wie es an der aktuellen Position im Dokument geeignet ist. Beispielsweise kann der Typ des Textes BLO, der beim Erzeugen eines Dokumentenanfangsblocks erforderlich ist, unterschiedlich von dem Typ sein, der beim Erzeugen des Körpers eines Dokuments erforderlich ist. Die Text-Rückrufeinheit 22-1 wird somit zwei leicht unterschiedliche Funktionalitäten in Abhängigkeit davon haben, welcher Teil des Dokuments enthalten ist. Die DAP-Handhabungseinheit (entweder die Struktur-Umwandlungskomponente oder eine Fußnoten- Rückrufeinheit -welche eine Komponente der DAP-Handhabungseinheit wie die Struktur-Umwandlungskomponente ist) weiß, welche Gruppe von Rückrufen geeignet ist und leitet sie zu den Inhalts-Handhabungseinheiten weiter.
Eine Fußnote ist im allgemeinen auch ein Text. Jedoch enthalten die Funktionalitäten, die für einen Rückruf in dem Fall erforderlich sind, daß einer Fußnote begegnet wird, das Erzeugen der unter Bezugnahme auf Fig. 6 gezeigten und diskutierten verschiedenen CLOs und BLOs. Diese Funktionatäten sind so unterschiedlich von jenen, die beim Erzeugen normaler Textsegmente erforderlich sind, daß es nützlich ist, den Fußnotenrückruf so zu betrachten, als ob er durch eine Fußnoten- Rückrufeinheit 22-4 durchgeführt wird, welche unterschiedlich von der normalen Textrückrufeinheit 22-1 ist.
Wie es oben angegeben ist, enthält das Verarbeiten einer Fußnote einen rekursiven Aufruf zur Text-Behandlungseinheit 13-1. Im Prinzip kann eine Rekursion ganz allgemein auftreten. Beispielsweise dann, wenn Information mit geometrischer Graphik innerhalb eines Textes begegnet wird, kann einem Text innerhalb der geometrischen Graphik begegnet werden (z.B. als Kennungen oder Legenden). Dies wird wiederum eine Rekursion enthalten, und zwar mit einem Rücksprung vom Text innerhalb der Graphik zurück zur Graphik, was die Rekursion beendet).
In der Praxis sind die Arten und die Tiefe einer Rekursion jedoch wahrscheinlich beschränkt. Weiterhin kann die DAP-Handhabungseinheiten den Arten und der Tiefe einer Rekursion, die zugelassen sind, Beschränkungen auferlegen. Beispielsweise kann es sein, daß die DAP-Handhabungseinheit nicht zuläßt, daß eine Graphik innerhalb von Fußnoten auftritt. Eine Art, auf die die DAP- Handhabungseinheit dies erreichen kann, besteht im Beschränken des Ausmaßes, bis zu dem die Inhalts-Handhabungseinheiten einander aufrufen können. Somit kann die Textinhalts-Handhabungseinheit 13-1 eine der Graphik- Handhabungseinheiten 13-2 und 13-3 aufrufen, aber die Rastergraphik- Handhabungseinheit 13-3 kann die Text-Handhabungseinheit 13-1 nicht aufrufen, weil in CDA Textinhalt nicht innerhalb eines Rastergraphik-Bild-Inhalts auftreten wird.
Es wurde oben angegeben, daß es verschiedene DAP-Handhabungseinheiten für verschiedene DAPs gibt. Solche verschiedenen DAP-Handhabungseinheiten können unterschiedliche Gruppen von Inhalts-Handhabungseinheiten haben, die zu ihnen gehören. Verschiedene DAPs können gleichermaßen verschiedene Gruppen von Rückrufeinheiten haben und verschiedene Beschränkungen und/oder Beschränkungsmechanismen gegenüber ihnen, und zwar in ihren entsprechenden DAP-Handhabungseinheiten.
Die obige Diskussion ist im Hinblick auf die Umwandlung logischer Objekte erfolgt, d.h. der Informationsinhalte der Dokumente. Die Umwandlung der Layoutinformation folgt denselben Prinzipien.

Claims

1. Datenstrukturformat-Umwandlungssystem, das folgendes aufweist:

eine Haupt-Umwandlungskomponente (14) zum Identifizieren eines einer Vielzahl von Profilen, mit welchen ein zusammengesetztes Dokument übereinstimmt, wobei das zusammengesetzte Dokument durch eine Dokumentenarchitektur beschrieben wird, bei welcher eine Struktur eines Dokuments von seinen Inhalten getrennt ist, wobei jedes der Vielzahl von Profilen eine vorbestimmte Untergruppe von Beschränkungen und Attributen der Dokumentenarchitektur identifiziert;

eine Vielzahl von Inhaltsarchitektur-Umwandlungskomponenten (13) zum Umwandeln eines Teils eines Ursprungsdokuments in ein Sollformat, wobei jede der Vielzahl von Inhaltsarchitektur-Umwandlungskomponenten einer vorbestimmten Klasse von Daten entspricht, wobei das Ursprungsdokument ein zusammengesetztes Dokument ist, das mit einem ersten der Vielzahl von Profilen übereinstimmt; und

eine Vielzahl von Profil-Umwandlungskomponenten (12) zum Umwandeln der Logik- und Layout-Strukturen des Ursprungsdokuments in jene des Sollformats, wobei jede der Vielzahl von Profil-Umwandlungskomponenten einem der Vielzahl von Profilen entspricht;

dadurch gekennzeichnet, daß

die Haupt-Umwandlungskomponente (14) eine entsprechende der Vielzahl von Profil-Umwandlungskomponenten (12) entsprechend dem ersten der Vielzahl von Profilen aufruft, mit denen das Ursprungsdokument übereinstimmt; und

eine der Vielzahl von Inhaltsarchitektur-Umwandlungskomponenten (13) durch die entsprechende Profil-Umwandlungskomponente ausgewählt wird, während ein Umwandeln des Ursprungsdokuments in das Sollformat erfolgt.

2. System nach Anspruch 1, wobei die Vielzahl von Inhaltsarchitektur- Umwandlungskomponenten eine Text-Umwandlungskomponente, eine geometrische Graphik-Umwandlungskomponente und eine Rastergraphik-(Bit- Bild-)Umwandlungskomponente enthält.

3. System nach Anspruch 1, wobei die Vielzahl von Profil- Umwandlungskomponenten (12) Komponenten enthalten, die wenigstens eine definierte Untergruppe des Architekturstandards für ein offenes Dokument implementieren.

4. System nach Anspruch 1 oder 2, wobei jede der Vielzahl von Profil- Umwandlungskomponenten (13) eine Einrichtung zum Erzeugen von logischen Objekten der Soll-Dokumentenarchitektur aufweist, die eine Struktur- Umwandlungskomponente (21) zum Erzeugen zusammengesetzter logischer Objekte des Solldokuments und einer Vielzahl von Rückrufeinheiten aufweisen, die jeweils zum Erzeugen eines unterschiedlichen Typs eines grundlegenden logischen Objekts oder einer Gruppe von logischen Objekten einschließlich wenigstens eines grundlegenden logischen Objekts dienen; und jede der Vielzahl von Inhaltsarchitektur-Umwandlungskomponenten (13) einen unterschiedlichen der möglichen Datentypen des Inhalts des Ursprungsdokuments in das Sollformat umwandelt, die jeweils von den anderen und von den Einheiten der Strukturarchitektur-Umwandlungskomponente aufrufbar sind und jeweils zu einer beliebigen einer entsprechenden Gruppe der Rückrufeinheiten zurückrufen können.

5. System nach Anspruch 3, wobei die Rückrufeinheiten eine Text- Rückrufeinheit, eine graphische Rückrufeinheit und eine Fußnuten- Rückrufeinheit enthalten.

6. System nach Anspruch 1, wobei es eine Vielzahl von Strukturarchitektur- Umwandlungskomponenten (21) gibt, von denen irgendeines auswählbar ist, wobei jede der Vielzahl von Strukturarchitektur-Umwandlungskomponenten die Struktur des Ursprungsdokuments analysiert und die Erzeugung von zusammengesetzten logischen Objekten initiiert.