DE68928190T2

DE68928190T2 - Dynamische Wiederbestimmung einer Rahmenstruktur

Info

Publication number: DE68928190T2
Application number: DE68928190T
Authority: DE
Inventors: Barbara A Barker; Thomas R Edel; Jeffrey A Stark
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1988-06-30
Filing date: 1989-05-23
Publication date: 1998-01-08
Anticipated expiration: 2009-05-24
Also published as: DE68928190D1; EP0349457A3; BR8903216A; JPH0576061B2; JPH0224755A; EP0349457B1; EP0349457A2; US4969093A

Description

HINTERGRUND DER ERFINDUNG

Die vorliegende Erfindung betrifft allgemein digitale Kommunikationen und im einzelnen die Verwaltung und Verarbeitung von Datenstromkonstrukten in der Weise, daß eine sinnvolle und genaue Verwaltung des Datenstroms erreicht wird, unabhängig von dem Anwendungsprogramm, das den Datenstrom generierte. Die Erfindung stellt eine Datenstromarchitektur bereit, die einen hohen Grad an Flexibilität bei der Weitergabe von Dokumentendaten, Formatierungsinformationen und Ressourcen von einem Anwendungsprogramm zu einem anderen erlaubt, indem sie ermöglicht, daß solche Daten enthaltende existierende Rahmenstrukturen vorübergehend durch Erzeugung von Formatierungsrahmenfragmenten modifiziert werden.
Die Verwaltung eines Datenstroms in einem digitalen Kommunikationsnetz, beispielsweise einem Nahverkehrsnetz (LAN) oder in größeren Fernverarbeitungsnetzen, wirft viele Probleme auf, insbesondere wenn die Datenströme an verschiedenen Endeinrichtungen oder Workstations erzeugt werden, die mit einer Vielzahl verschiedener Anwendungsprogramme mit unterschiedlichen Steuerungsmerkmalen und Protokollen arbeiten.
Betrachten wir zum Beispiel ein hypothetisches Fernverarbeitungsnetz, das Kommunikationen zwischen zwei oder mehr Endanwendern unterstützt. Diese Endanwender können Anwendungsprogramme, Speichereinrichtungen oder Bediener an einem Bildschirmarbeitsplatz sein. Den Endanwendern steht hierbei einer Reihe von Kommunikationsfunktionen zur Verfügung; zum einen ist dies die Sprache, beispielsweise das Formatieren, die Übersetzung und/oder das Editieren; zum anderen der Dialog, eine Disziplin zur Steuerung des Datenflusses, eine Übertragungssteuerung, wie die Steuerung der Übertragungsgeschwindigkeit und des Ablaufs, und der Transport, wie z.B. das Leiten der Signale zwischen adressierfähigen Einheiten durch ein mehr oder weniger komplexes Übertragungsnetz.
Die Systemnetzarchitektur (SNA) definiert Gruppen von kommunikationsbezogenen Funktionen, die innerhalb eines Netzes verteilt sind. Sie definiert außerdem die Formate und Protokolle, mit denen diese verteilten Funktionen zueinander in Bezug gebracht werden. Ein SNA-Netz ist hoch transparent; das heißt, jeder Bitstrom ist erlaubt und die Endanwender müssen sich nicht um die Netztopologie, die Auswahl des Leitwegs oder die eingesetzten Medien kümmern. Eine Sitzung ist definiert als eine temporäre logische Verbindung zwischen netzadressierfähigen Einheiten zum Austausch von Nachrichten in Übereinstimmung mit einer Gruppe von SNA-Funktionen, die für diese Sitzung bestimmt sind. Das SNA-Netz stellt also Gruppen von verteilten Diensten bereit, um Dialoge zwischen Anwender- Paaren zu vereinfachen. Die SNA-Dienste sind in einzelnen Schichten organisiert, so daß voneinander logisch unabhängige Funktionen auch voneinander unabhängig entworfen, implementiert und aufgerufen werden können. Ein Endanwender kann gleichzeitig ablaufende Sitzungen für die Kommunikation mit anderen Endanwendern an mehreren Netzadressen einsetzen.
Wie bereits oben erwähnt, kann ein Endanwender in einem SNA- Netz ein Anwendungsprogramm, ein Bediener eines Ein-/Ausgabe(E/A)-Geräts, oder ein Speichermedium sein. Die üblichste Form eines Endanwenders ist ein Anwendungsprogramm. Die Interaktion zwischen einem Programm und einem SNA-Netz umfaßt den Datenaustausch und/oder die Datenübermittlung und den gelegentlichen Austausch von Befehlen und Indikatoren zur Steuerung von SNA-Funktionen. Verschiedene Anwendungsprogramme in einem SNA-Netz erzeugen im typischen Fall eindeutig diesem Programm zugeordnete Datenströme. Zwar wird durch die SNA-Netzarchitektur die Kommunikation zwischen den Endanwendem und dem Netz vereinfacht, jedoch kann eine sinnvolle Kommunikation nicht erreicht werden, wenn es sich bei den Endanwendern um Anwendungen handelt, die inkompatible Datenströme erzeugen.
Im Zusammenhang mit der vorliegenden Beschreibung ist ein Datenstrom eine Sammlung von strukturierten Feldern und wird definiert von der Syntax und der Semantik der strukturierten Felder. Syntax ist die Art und Weise der Gruppierung der strukturierten Felder und Parameter, unabhängig von ihrer Bedeutung oder der Art und Weise ihrer Interpretation und Anwendung. Mit Semantik ist die Bedeutung der strukturierten Felder und Parameter unabhängig von ihrer Interpretation und Verwendung gemeint. Der Datenstrom wird interpretiert, um eine visuelle oder begriffliche Entität zu erzeugen, wie zum Beispiel ein Dokument. Ein Dokument wiederum ist zusammenge setzt aus Seiten, Datenobjekten, Ressourcen und Befehlen und liegt entweder im Revisions-, Präsentations- oder Ressource- Datenformat vor.
Textverarbeitungsprogramme erzeugen beispielsweise Datenströme, in die Formatierungs- und Textbefehle eingebettet sind. Typischerweise sind diese Befehle von einem Anwendungsprogramm zum anderen unterschiedlich. Für den Austausch von Datenströmen aus unterschiedlichen Textverarbeitungsanwendungen und um die konsistente Interpretation von eingebetteten Formatierungs- und Textbefehlen zu ermöglichen, wurde Revisable/Format/Text/Document/Content/Architecture (RFTDCA) entwickelt.
Von der International Standards Organization (ISO) wurden Normen zur Verarbeitung und für den Austausch von Dokumenten definiert. Zwei dieser Normen sind die Standard Generalized Markup Language (SGML), Publikation 8879, und die Office Document Architecture/Office Document Interchange Facility (ODA/ODIF), Publikation 8613. SGML ist eine Repräsentationssprache für Zeichentext und kann zur Definition der Spezifikationen für Publishing-Systeme eingesetzt werden. Die Basis von SGML ist die generische Markierung, das heißt die Identifizierung der Rolle der Dokumentenelemente und nicht der Art und Weise, wie diese Elemente präsentiert werden sollen. SGML wird auch zum Austausch von Textdokumenten verwendet; da jedoch in einem Dokument neben den Textdaten auch Nichttextdaten enthalten sein können, beispielsweise eingescannte Bilder und Graphiken, wird die Forderung, Dokumente mit Nichttextdaten auszutauschen, von SGML nicht ganz erfüllt. Diese Forderung wird besser von ODA abgewickelt.
ODA ist ein Verfahren zur Beschreibung von Dokumentenstrukturen und aller Arten von Text- und Nichttextinformationen, die in einem Dokument enthalten sein sollen. Diese Strukturbeschreibung wird als Architektur bezeichnet und die Darstellung des Dokuments erfolgt in einer für den Austausch geeigneten Form. Die Codierung von ODA für den Austausch ist in serieller Form, das heißt als Datenstrom, definiert. Ein ODA- Dokument kann Daten gescannter Bilder und Graphiken, aber auch Zeichentext enthalten, wobei beides in einen konsistenten Datenstrom integriert ist
ODA ermöglicht eine Steuerung des Formatierungsprozesses, nicht durch Einbettung von Formatierungsbefehlen, sondern vielmehr durch Spezifizierung von Attributen, genannt Layoutund Präsentationsdirektiven, welche den von der Dokumentenstrukturbeschreibung definierten Objekten zugeordnet sind. Diese Direktiven werden in Gruppen zusammengefaßt und bilden Layout- und Präsentationsformate, die ihrerseits von einem oder mehreren Objekten in der Dokumentenstruktur referenziert werden können.
ODA-Formate können auf ein Dokument beschränkt sein oder sich außerhalb eines Dokuments befinden, die Interpretation der Formatattribute und Formatwerte wird jedoch explizit vom ODA- Standard kontrolliert Es gibt keine explizite Verknüpfung von einem Punkt in einem ODA-Datenstrom zu einer bestimmten Stelle in einer Formatspezifikation. Der Erzeuger eines ODA- Dokuments kann die Formatspezifikation vergrößern, indem er in die ODA-Objektbeschreibungen vom Anwender definierte Attributnamen und -werte einbettet. Vom Anwender definierte Attribute spezifizieren eine von der Anwendung abhängige Funktion, die während der Dokumentenverarbeitungsphase für ein ODA-Objekt angewendet werden soll. Diese Information ist nur innerhalb der erzeugenden Anwendung sinnvoll und kann nicht von einem beliebigen Endanwender interpretiert werden.
Interleaf, Xerox Ventura Publisher und Microsoft Word sind Beispiele für Editierungsanwendungen, in denen anstelle von eingebetteten Steuerungen oder Befehlen zur Steuerung der Formatierung und des Layouts Seitendruckformatvorlagen eingesetzt werden. Diese Methode kann schwerfällig sein, denn nachdem dem Inhalt eines Dokuments bestimmte Eigenschaften zugeordnet wurden, kann das Durchführen systematischer, globaler Veränderungen weitschweifig und schwierig sein. Außerdem können Veränderungen an der Seitendruckformatvorlage nur innerhalb der Anwendung ausgeführt werden, in der das Dokument erzeugt wurde. Ventura Publisher verfügt über eine starke Importfunktion, die eine große Vielfalt von Dateiformaten akzeptiert, die von Textverarbeitungsanwendungen erzeugt wurden. Diese Dateien werden roh in Ventura Publisher importiert, und hier werden dann in Form einer Nachverarbeitungs-Task die ausführlichen Formatierungen ausgeführt, basierend auf einer Seitendruckformatvorlage, die von dem Bediener ausgewählt wird, der die Dateiimportierungs-Task initiiert hat. Standard-Seitendruckformatvorlagen werden sowohl bei Ventura Publisher als auch bei Microsoft Word separat abgelegt; auf sie können mehrere Dokumente innerhalb der Ventura Publisher- und der Microsoft Word-Anwendung zugreifen. Microsoft Word-Dokumente enthalten normalerweise eine lokale Seitendruckformatvorlage; diese kann editiert werden, wenn der Bediener wünscht, daß jedes Dokument eine unterschiedliche Seitendruckformatvorlage hat. In beiden Anwendungen ist eine kundenspezifische Anpassung der Seitendruckformatvorlage nur aus dem Anwendungsprogramm heraus verfügbar, und es gibt keine expliziten Verweise von einem Punkt in einem Dokument zu einer Stelle in der Seitendruckformatvorlage. Eine Seitendruckformatvorlage kann nur von einem Endanwender von Ventura Publisher oder von Microsoft Word verändert werden.
Die nach den ISO-Standards oder von bekannten Anwendungsprogrammen erzeugten Datenströme sind in der Regel komplex, weil man bestrebt ist, möglichst viele zu erwartende Formatierungsforderungen darin zu berücksichtigen. Nehmen wir zum Beispiel ein Tabellenkalkulationsprogramm. Bei jedem Bediener sind die Verarbeitungsanforderungen zwischen den einzelnen Zellen, Reihen und Spalten unterschiedlich. Der Entwurf eines Anwendungsprogramms, in dem alle möglichen Wünsche berücksichtigt werden, führt zu einem extrem unübersichtlichen Datenstrom. Benötigt wird eine Datenstromarchitektur, die übersichtlich ist und eine kompatible Kommunikation unter verschiedenen Anwendungsprogrammen in einem Netz erlaubt. Das heißt, es wird eine Mischobjekt-Dokumenteninhaltsarchitektur bevorzugt, bei der Dokumente unter den verschiedenen Produkten ausgetauscht werden können, so daß die in den Dokumenten enthaltenen Daten in einer konsistenten Weise verarbeitet werden können. In einer solchen Mischobjekt-Dokumenteninhaltsarchitektur wird ein Datenstrom-Standard benötigt, der den Datenstrom von den verschiedenen Formatierungsbefehlen entlastet und dadurch die Datenstromarchitektur vereinfacht und einen kompatibleren Austausch von Dokumentendaten erleichtert.
Vor kurzem wurde ein System vorgeschlagen, in dem eine Rahmenstruktur verwendet wird; diese gibt an, wie markierte Konstrukte oder Elemente verwaltet und verarbeitet werden können, die unabhängig vom Dateninhalt sind, jedoch gleichzeitig mit den Daten in einer Datenstromrepräsentation eines Dokuments erscheinen können, das von einem Editor oder einer anderen ähnlichen Anwendung erzeugt wurde. Die Rahmenstruktur ist getrennt vom Datenstrom, kann unabhängig übertragen und in jeder vom Netz wiedererkannten Form gespeichert werden.
Das Rahmenstruktursystem umfaßt eine Markierungselementfunktion, die Konstrukte in einem Datenstrom miteinander verknüpft, indem auf mit Namen versehene Konstrukte in einer Rahmenstruktur Bezug genommen wird. Das mit einem Namen versehene Rahmenkonstrukt legt die Regeln, Beziehungen und die Formatierungsinformationen entweder direkt oder indirekt fest, welche die Verarbeitung und die Verwaltung des Datenstromkonstrukts bestimmen, das die Referenz enthält. Diese Rahmenstrukturen können von einem Endanwender leicht an den eigenen Bedarf angepaßt werden; nachdem sie jedoch einmal verändert wurden, steht die ursprüngliche Rahmeninformation dem Anwender nicht mehr zur Verfügung. Es liegt daher auf der Hand, daß ein Verfahren benötigt wird, mit dem eine solche Rahmenstruktur auf einfache Weise und temporär modifiziert und wiederbestimmt werden kann, ohne daß die ursprüngliche Rahmenstruktur selbst verlorengeht.
Das Dokument EP-A-Q 179 206 beschreibt ein Verfahren zur Übertragung von Dokumentendaten und Formatierungsinformationen von einem ersten Anwendungsprogramm zu einem zweiten Anwendungsprogramm durch Zugriff auf einen ausgewählten Formatierungsrahmen mittels in den Datenstrom eingebetteter Markierungen.

ZUSAMMENFASSUNG DER ERFINDUNG

Es ist daher eine Aufgabe der vorliegenden Erfindung, eine Umgebung für den Austausch digitaler Kommunikationen zu schaffen, in der die Übertragungsleistung verbessert wird.
Eine andere Aufgabe der vorliegenden Erfindung ist die Schaffung einer Umgebung für den Austausch digitaler Kommunikationen, in der die Übertragungsleistung dadurch verbessert wird, daß eine dynamische Wiederbestimmung von Formatierungsrahmenstrukturen möglich ist, die angeben, wie markierte Konstrukte in einem Datenstrom zu verwalten und zu verarbeiten sind.
Eine weitere Aufgabe der vorliegenden Erfindung ist die Schaffung einer Umgebung für den Austausch digitaler Kommunikationen, in der die Übertragungsleistung dadurch verbessert wird, daß die dynamische Wiederbestimmung von Formatierungsrahmenstrukturen möglich ist, die angeben, wie markierte Konstrukte in einem Datenstrom zu verwalten und zu verarbeiten sind, ohne daß die Formatierungsrahmenstruktur dauerhaft geändert werden muß.
Die obengenannten Aufgaben werden erreicht durch Bereitstellung eines Verfahrens nach Anspruch 1. Jede Formatierungsrahmenstruktur umfaßt Endanwender-Bedingungen, die zur Verarbeitung von Konstrukten innerhalb eines Datenstroms notwendig sind, auf die mittels in den Datenstrom eingebetteter Markierungen zugegriffen wird. Der Datenstrom ist dadurch weniger überfrachtet und die Endanwender-Formatierung wird flexibler, indem in den Datenstrom die Markierungen für einen Punkt in einem oder mehreren Rahmen eingebettet werden, auf den die Workstation des Endanwenders zugreifen kann; oft ist es jedoch wünschenswert, einen bestimmten Rahmen für eine bestimmte Anwendung zu modifizieren, ohne den Rahmen dauerhaft zu verändern. Gemäß der vorliegenden Erfindung wird ein Formatierungsrahmenfragment erzeugt, das einen Bezug zu einem kompletten Rahmen und einer für diesen Rahmen anzuwendenden temporären Modifizierung enthält. In einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung kann ein Formatierungsrahmenfragment ein anderes Formatierungsrahmenfragment referenzieren, welches wiederum ein anderes Formatierungsrahmenfragment oder einen kompletten Rahmen referenzieren kann. Auf diese Weise kann ein Datenstrom unter Verwendung einer vorhandenen Rahmenstruktur verarbeitet werden, die zu diesem Zweck temporär neu definiert wurde.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Die neuartigen Merkmale, die für die Erfindung als charakteristisch gelten, sind in den Ansprüchen im Anhang dargelegt. Die Erfindung selbst, sowie eine bevorzugte Ausführungsform derselben, und weitere Aufgaben und Vorteile der Erfindung, werden jedoch am besten verständlich anhand der folgenden ausführlichen Beschreibung eines illustrativen Ausführungsbeispiels in Verbindung mit den beiliegenden Zeichnungen; es zeigt:
FIGUR 1 ein Blockdiagramm, das die Beziehung der verschiedenen Architekturen darstellt, die einen Datenstrom definieren;
FIGUR 2 ein Funktionsblockdiagramm, das die Hierarchie der Komponenten in einer Architektur mit Mischobjekt-Dokumenteninhalt zeigt, welche das bevorzugte Ausführungsbeispiel der vorliegenden Erfindung darstellt;
FIGUR 3 eine Erläuterung von Seitenelementen einer Seite innerhalb eines Dokuments, die von einem Datenstrom beschrieben werden können;
FIGUR 4 eine High-Level-Beschreibung einer Formatierungsrahmenstruktur;
FIGUR 5 ein Blockdiagramm, das die Erzeugung eines Rahmens oder einer Rahmenfragmentstruktur gemäß der vorliegenden Erfindung zeigt;
FIGUR 6 eine High-Level-Beschreibung eines Formatierungsrahmenfragmentes;
FIGUR 7 eine Erläuterung der Verkettung mehrerer Rahmenfragmentstrukturen und einer Rahmenstruktur zur Bildung einer neu definierten Rahmenstruktur in Textform;
FIGUR 8 eine Erläuterung der Verkettung mehrerer Rahmenfragmentstrukturen und einer Rahmenstruktur zur Bildung einer neu definierten Rahmenstruktur in graphischer Form; und
FIGUR 9 eine Erläuterung des Aufbaus einer neu definierten Rahmenstruktur gemäß der vorliegenden Erfindung als logisches Flußbild.

AUSFÜHRLICHE BESCHREIBUNG DES BEVORZUGTEN AUSFÜHRUNGSBEISPIELS

Bezugnehmend auf die Figuren und hier insbesondere auf Figur 1; Figur 1 gibt einen Überblick über die Struktur der verschiedenen Architekturen, die einen Datenstrom definieren. Als erstes werden die Object Content Architectures (OCAs) aufgeführt, welche die Strukturen und die Steuerungen für bestimmte Datentypen bereitstellen. Beispiele sind OCA für revidierbaren Text, in denen Tabs, Randeinstellungen und ähnliches angegeben werden, und OCA für Bilder, in denen die Auflösung, die Komprimierungsalgorithmen und ähnliches angegeben werden. Diese OCAs umfassen Datenstromstrukturen mit einem Anfangscode, der den Daten- und Steuerungscodes vorangestellt ist, und werden mit einem Ende-Code abgeschlossen.
Die Document Content Architectures (DCAs), mit der spezifischen Mischobjekt-Dokumenteninhaltsarchitektur (MO:DCA), sind eine bevorzugte Umgebung der vorliegenden Erfindung und stellen unter anderem das Seiten-Layout und die Beziehungen zwischen Objekten bereit. Wie in Figur 1 zu sehen ist, ist der OCA-Datenstrom in den Objekten enthalten, plus dem Steuerungsteil des DCA-Datenstroms. Der DCA-Datenstrom ist seinerseits Teil der Document Interchange Architecture, die einen Datenstrom der Document Interchange Unit (DIU) definiert. Diese Architektur stellt Dokumentenverteildienste, Dokumentenbibliotheksdienste und Anwendungsverarbeitungsdienste bereit. Der Datenstrom hat ein von einem Befehlscode und einem Dateneinheitscode gefolgtes Präfix. Dann folgt der DCA-Datenstrom als die Dokumenteneinheit. Ein Suffix beendet den DIU- Datenstrom.
Die Systems Network Architecture (SNA), wie bereits oben beschrieben, steuert den Informationsaustausch zwischen den einzelnen Netzentitäten. Diese Architektur definiert einen Datenstrom der Path Information Unit (PIU), der einen Übertragungskopf, einen Anforderungskopf und eine Anforderungseinheit umfaßt. Die zuletztgenannte ist der DIU-Datenstrom.
Ein Datenübermittlungsprotokoll, beispielsweise Synchronous Digital Link Control (SDLC) sorgt für die Synchronisation und die Fehlerbeseitigung auf einer Datenstrecke. Das Protokoll definiert einen Übertragungsrahmen, der ein Anfangskennzeichen, eine Adresse, Steuerbits, die Daten, BCC-Prüfbits für die Fehlererkennung und ein Endekennzeichen umfaßt. Die Daten sind der PIU-Datenstrom. Das Thema der Datenstromdefinition und der Protokolle im allgemeinen wird ausführlicher bei R.J. Cypser in Communications Architecture for Distributed Systems, veröffentlicht von Addison-Wesley (1978), behandelt.
Da das bevorzugte Ausführungsbeispiel zur praktischen Umsetzung der vorliegenden Erfindung im Bereich der Architektur mit Mischobjekt-Dokumenteninhalt liegt, soll zunächst eine kurze Beschreibung dieser Architektur und anschließend ein spezifisches Beispiel einer Implementierung der Erfindung gegeben werden. Mixed Object Document Content Architecture (MO:DCA) stellt eine Definition für eine einzelne Schnittstelle bereit, über die verschiedene Anwendungsprogramme Objekte untereinander austauschen können, und zwar so, daß diese Daten hierbei mit unterschiedlichen Eigenschaften und für einen unterschiedlichen Zweck editiert, präsentiert oder manipuliert werden können. MO:DCA stellt sowohl eine logische Struktur als auch eine Layout-Struktur für den Aufbau eines Dokuments bereit, das aus einem der unterstützten Objekttypen besteht. Die Objekttypen können beispielsweise Textobjekte, Graphikobjekte, Bildobjekte, Tabellenobjekte und so weiter sein. Innerhalb einer einzelnen Datenstromdefinition können durch MO:DCA und seine Datenobjekte sowohl leicht revidierbare als auch extrem unrevidierbare Konstrukte spezifiziert werden. Die Bezeichnung "gemischt" bezieht sich in MO:DCA also sowohl auf gemischte Datenobjekte als auch auf gemischte Dokumentenkonstrukte. Ein Dokument mit gemischten Objekten ist die Sammlung von Ressourcen, Datenobjekten und Formatierungsspezifikationen, die angeben, welche Verarbeitungsfunktionen mit dem Dokumenteninhalt durchgeführt werden sollen. Jede Komponente ist eindeutig definiert und eingegrenzt. Der Inhalt der Komponenten besteht aus anderen Komponenten und strukturierten Feldern (also aus Befehlen). Die strukturierten Felder bestehen ihrerseits aus einem oder mehreren Parametern und jeder Parameter stellt einen Wert dar, der aus einer von der Architektur definierten Gruppe von Werten ausgewählt wurde.
Zu den Eigenschaften des MO:DCA-Datenstroms und der ihm zugeordneten Objektinhalt-Architektur gehört die in Figur 2 der Zeichnungen erläuterte Hierarchie. Ein Dokument wird demnach von einem Datenstrom beschrieben, der einen Dokumentenanfangscode umfaßt, gefolgt von einer Vielzahl von Dokumentenkomponenten, hier bezeichnet als Komponente 1, 2, ..., und endend mit einem Dokumentenendecode. Eine dieser Dokumentenkomponenten, beispielsweise Komponente 2, könnte eine Seite sein, die wiederum von demjenigen Teil des Datenstroms beschrieben wird, der einen Seitenanfangscode umfaßt, gefolgt von einer Vielzahl von Seitenkomponenten, die hier als Komponente 1, 2, ... bezeichnet wurden, und endend mit einem Seitenendecode. Eine dieser Seitenkomponenten, beispielsweise Komponente 2, könnte ein Objekt sein, das wiederum von demjenigen Teil des Datenstroms beschrieben wird, der einen Objektanfangscode enthält, gefolgt von einer Beschreibung des Objekts, den Objektdaten, und der mit einem Objektendecode endet. Die Objektbeschreibung ist ein Befehl, der sich aus einer strukturierten Feldeinleitung, gefolgt von einer Vielzahl von Parametern, zusammensetzt. Der Datenstrom enthält also eine geordnete verschachtelung von Objekten, die aus strukturierten Feldern (also aus Befehlen) bestehen. Außerdem können auf einer einzelnen Seite mehrere Datenarten auftauchen, zum Beispiel Text, Bild, Graphik und so weiter. Alle Funktionen und Daten, die einen MO:DCA-Datenstrom umfassen, werden in logischen Sätzen zusammengefaßt, die als strukturierte Felder bezeichnet werden. Diese strukturierten Felder sind in Wirklichkeit "Befehle" mit Null oder mehr Parameterfeldern. Alle strukturierten Felder werden eingerahmt von einem Beginn/Ende-Paar.
Eine Seite eines Dokuments enthält Datenobjekte, die Teil einer Präsentation oder eines revidierbaren Dokumentes sind, die entsprechend der Seitenmodellbeschreibung abgebildet werden sollen. Figur 3 zeigt ein Beispiel des Seitenelements, das von einem Seitenmodell definiert werden kann. Obwohl sie von dem Modell definiert werden, müssen nicht alle Elemente auf jeder Seite vorhanden sein. Das Hauptdatenobjekt kann jede beliebige Datenart sein, Text, Graphik, etc. oder eine Mischung dieser Typen. Textobjekte können in einer oder in mehreren Spalten vorhanden sein. Ein revidierbares Dokument besteht aus Daten und Informationen, welche die Präsentation der Daten bestimmen. Der Urheber muß nicht für jeden Dokumentenabschnitt das Format getrennt angeben. Einige Formataspekte können einmalig am Beginn des Dokumentes angegeben werden, während andere Aspekte innerhalb des Dokuments angegeben werden können. Das revidierbare Dokument kann auch Ressourcen referenzieren, die benutzt oder in das aktuelle Dokument eingeschlossen werden sollen, wenn dieses in Präsentationsform umgewandelt wird. Ein Präsentationsdokument definiert, wie die Datenströme, die zu druckende oder anzuzeigende Dokumente repräsentieren, aufgebaut sind.
Die vorliegende Erfindung verwendet anstelle der Formatierungskonstrukte strukturierte Felder in dem Datenstrom nach dem Prinzip Tag Logical Element (TLE). Die TLE können für den Aufruf von Makros und die Weitergabe von Parametern verwendet werden. Außerdem können die TLE zum Beginnen und Beendigen einer spezifischen Instanz eines logischen Elementes verwendet werden. Wenn das TLE verwendet wird, um ein logisches Element zu beginnen, zum Beispiel eine Abbildung, kann es ein oder mehrere Attribute angeben, zum Beispiel einen Rahmen für das logische Element und einen Wert, zum Beispiel ein Kästchen für jedes Attribut. Ein strukturierter Rahmen an der Workstation des Endanwenders wird verwendet, um anzugeben, wie in den Datenstrom eingebettete TLEs zu verwalten und zu verarbeiten sind. Der strukturierte Rahmen ist getrennt vom Datenstrom und kann entweder vom Urheber des Dokuments oder vom Endanwender generiert werden. Wird er vom Urheber generiert, kann der Rahmen unabhängig vom Datenstrom übertragen und in jeder vom Netz wiedererkannten Form gespeichert werden, wodurch er für jede Workstation am Netz zugänglich wird.
Wird er vom Endanwender erzeugt&sub1; kann der Rahmen lokal gespeichert werden, und kann dann nur vom Endanwender verwendet werden. Der Endanwender kann auch den vom Urheber generierten Rahmen modifizieren, um den Rahmen speziell an die Formatierungs- und Verarbeitungsanforderungen des Endanwenders anzupassen.
Das TLE verbindet Konstrukte in dem Datenstrom durch Bezugnahme auf mit einem Namen versehenen Konstrukte in dem Rahmen. Das mit einem Namen versehene Rahmenkonstrukt gibt die Regeln, die Beziehungen und die Formatierungsinformationen, entweder direkt oder indirekt, an, welche die Verarbeitung und Verwaltung des Datenstromkonstruktes bestimmen, das die Referenz enthält. Außerdem wird das TLE verwendet, um den Dateninhalt dem markierten Konstrukt zuzuordnen. Eine eindeutige Zuordnung ist möglich mit einer internen oder externen Referenz zu einer Datenobjekthülle, welche die gewünschte Inhaltsinformation enthält, oder mit einem inhaltsgenerierenden Ausdruck, der beschreibt, wie die gewünschte Inhaltsinforrnation bestimmt wird. Zu einer impliziten Zuordnung kommt es, wenn die Datenobjekthülle dem markierten Konstrukt in dem Datenstrom sequentiell folgt. Enthält das TLE einen Hinweis auf einen inhaltsgenerierenden Ausdruck, kann der zugeordnete Dateninhalt durch Auswerten des referenzierten Ausdrucks bestimmt werden. Das TLE kann auch zur Spezifizierung eines oder mehrerer Attribute und erklärter Werte verwendet werden, mit denen die Spezifikationen im Rahmen entweder für diesen selbst oder für verschachtelte, markierte Konstrukte übersteuert werden können, wenn der Endanwender nichts anderes angegeben hat. Neben den Formatdeskriptoren und den Direktiven können die Syntax der Attribute und die Gruppe der erlaubten Attributwerte direkt im Rahmen enthalten sein, aus dem Rahmen heraus referenziert werden oder aus dem TLE heraus referenziert werden. Referenzierungen aus dem Rahmen oder aus dem TLE können sich auf ein Makro, eine Prozedur, ein Ressource-Objekt oder ein anderes Konstrukt beziehen, das Formatierungsinformationen spezifiziert. Die referenzierten Konstrukte können in demselben Rahmen oder in einem anderen Rahmen enthalten sein und können Referenzierungen zu anderen Konstrukten enthalten. Referenzierungen von der TLE ersetzen temporär ihre jeweiligen Pendants in dem Rahmen. Die Dauer dieses Ersetzens entspricht der Dauer des Umfangs des markierten Konstrukts. Der Umfang des markierten Konstrukts wird bestimmt von der hierarchischen Position des referenzierten benannten Konstrukts in dem Rahmen. Der Rahmen ist wie ein Baum aufgebaut, jedes benannte Konstrukt ist ein Knoten in dem Baum. Die Knoten sind verschachtelt, die Verschachtelungsebene bestimmt den Umfang des benannten Konstrukts, das von dem Knoten repräsentiert wird.
Bezugnehmend auf Figur 4; hier ist eine High-Level-Beschreibung eines Formatierungsrahmens dargestellt. Wie zu sehen ist, umfaßt die Rahmenstruktur einen Rahmennamen, einen Wurzelnamen und eine Inhaltsreferenzierung innerhalb eines Strukturfeldes, das als Rahmendeskriptor bekannt ist. Danach kann jedes Strukturfeld zur Rahmensteuerung zusätzlich zu einem Steuerungsnamen Steuerungsprozeduren, Steuerungsdaten und einen Hinweis auf die nächste Steuerung in der Rahmenstruktur enthalten. Auf diese Weise können Markierungen innerhalb des Datenstroms für spezifische Abschnitte der Rahmenstruktur als Richtlinie für die Verarbeitung und die Verwaltung des Datenstromteils verwendet werden, der die Referenz enthält. Das Format, das Layout und die Prozeduren, die dann zur Verarbeitung und Verwaltung eines Teils des Datenstroms verwendet werden, liegen innerhalb der Rahmenstruktur und ermöglichen einen weniger überfrachteten und einfacher zu verwaltenden Datenstrom.
Bezugnehmend auf Figur 5; hier wird ein Blockdiagramm beschrieben, das die Erzeugung eines Rahmens oder einer Rahmenfragmentstruktur gemäß der vorliegenden Erfindung erläutert. Wie man sehen kann, ist ein Bildschirm 11 dargestellt, auf dem die Erstellung eines Rahmens oder einer Rahmenfragmentstruktur 12 abgebildet ist. Der Rahmen oder die Rahmenfragmentstruktur werden als Teil einer Anwendung 13 erzeugt, die von einem Anwender eines mit dem Bildschirm 11 verbundenen Gerätes 14 eingeleitet wurde. Die Anwendung ermöglicht die Erstellung eines Rahmens oder einer Rahmenfragmentstruktur. Da ein Rahmen oder ein Rahmenfragment von der beschriebenen Anwendung erstellt werden können, beginnt die Anwendung 13 mit der Abfrage des Anwenders, um festzustellen, ob ein Rahmen oder ein Rahmenfragment erstellt werden soll oder nicht. Wie zu sehen ist, fordert die Anwendung den Anwender, nachdem dieser sich für die Erstellung eines Fragmentes entschieden hat, auf, den Namen des Fragments einzugeben. In diesem Fall wurde als Name für das zu erzeugende Fragment "FRAG A2" ausgewählt.
Gemäß der vorliegenden Erfindung muß der Anwender anschließend den Namen des Rahmenfragments oder der Rahmenstruktur eingeben, die von dem erstellten Fragment modifiziert werden soll. Jedes Rahmenfragment enthält, entsprechend dem Verfahren der vorliegenden Erfindung, einen Hinweis zu einem zweiten Rahmenfragment oder einer Rahmenstruktur, die entsprechend den in dem erstellten Rahrnenfragment enthaltenen Konstrukten modifiziert wird. Wenn die Eingabeaufforderung erscheint, gibt der Anwender als Name der zu modifizierenden Struktur "FRAG A1" ein. Anschließend spezifiziert der Anwender den Wurzelnamen und beginnt mit der Erstellung des spezifizierten Rahmenfragments.
Sowohl bei Rahmenstrukturen als auch bei Rahmenfragmentstrukturen kann der Anwender jetzt die Formatierungsdirektiven eingeben (zum Beispiel Einrücken um fünf, Zentrieren, etc.), untergeordnete Konstruktnamen und logische Positionsbeziehungen, Vorgänger-Konstruktnamen, Präsentationsattribute und Standardschriften (zum Beispiel Times, Roman, Font), Layout- Informationen (zum Beispiel horizontale und vertikale Position in Bezug zum enthaltenen benannten Konstrukt) oder Verarbeitungs routinen.
Bezugnehmend auf Figur 6; hier ist eine High-Level-Beschreibung eines Formatierungsrahmenfragmentes dargestellt, das entsprechend der vorliegenden Erfindung aufgebaut wurde. Wie man sehen kann, umfaßt die Rahmenfragmentstruktur ein strukturiertes Feld mit einem Rahmendeskriptor, der einen Hinweis auf den Namen des Rahmenfragments oder des zu modifizierenden Rahmens enthält, sowie den Wurzelnamen des Rahmenfragments. Außerdem enthält die Rahmenfragmentstruktur eine Inhaltsreferenz. Danach enthält die Rahmenfragmentstruktur Steuerungsnamen, Prozeduren, Daten und Hinweise zu der nächsten zu verwendenden Steuerung. Es sei darauf hingewiesen, daß die in dem Rahmenfragment beschriebenen Steuerungsnamen identisch mit Steuerungsnamen sind, die in anderen Rahmenfragmenten oder Rahmenstrukturen vorhanden sind, die, entsprechend dem Verfahren der vorliegenden Erfindung, temporär geändert werden sollen.
Bezugnehmend auf Figur 7; hier wird eine Erläuterung der Verkettungstechnik in Textform dargestellt, mit der mehrere Rahmenfragmentstrukturen verbunden werden können, um für einen bestimmten Datenstrom eine neu definierte Rahmenstruktur zu bilden. Wie man sehen kann, enthält die Rahmenfragmentstruktur FRAG A2, wenn auf sie durch eine Markierung innerhalb des Datenstroms Bezug genommen wird, einen Hinweis auf das Rahmenfragment FRAG A1, der besagt, daß sie zur Modifizierung des Rahmenfragments FRAG A1 verwendet wird.
Dieser Prozeß wird dann fortgesetzt mit dem Rahmenfragment FRAG A1, das einen Hinweis für den Rahmen A enthält. Der Rahmen A wird dann entsprechend den im Rahmenfragment FRAG Al und im Rahmenfragment FRAG A2 enthaltenen Steuerungen modifiziert. Der Fachmann wird natürlich erkennen, daß es hinsichtlich der Zahl der verketteten Rahmenfragmentstrukturen, die bei Anwendung dieser Technik erreicht werden kann, keine Beschränkung gibt. Die Rangordnung der "verketteten" Definitionen für die Rahmenfragmentstruktur ist einfach zu definieren, so daß Änderungen an einer Rahmenstrukturdefinition, die zuerst in der Kette angetroffen werden, Vorrang haben gegenüber Änderungen an demselben Teil der Rahmenstruktur, die später in der Kette angetroffen werden.
Bezugnehmend auf Figur 8; hier wird eine graphische Darstellung der Verkettungstechnik gezeigt, bei der mehrere Rahmenfragmentstrukturen und eine Rahmenstruktur miteinander kombiniert werden können, um eine neu definierte oder "hybride" Rahmenstruktur zu bilden. Wie zu sehen ist, ist das Rahmenfragment FRAG A2 graphisch bei der Bezugszahl 15 dargestellt und umfaßt zwei markierte Konstrukte, Tag 111 und Tag 1111. Das Rahmenfragment FRAG A1 ist bei Bezugszahl 16 graphisch dargestellt und umfaßt, wie man sehen kann, ebenfalls ein markiertes Konstrukt Tag 111, zusätzlich zu den markierten Konstrukten Tag 11, Tag 102 und Tag 1021.
Durch die hier beschriebene Hybridisierungstechnik wird das Rahmenfragment FRAG A2 mit dem Rahmenfragment FRAG A1 verkettet und bildet ein hybrides Rahmenfragment FRAG A1, das an Bezugszahl 17 dargestellt ist. Das neue Tag 111 und das ihm zugeordnete Tag 1111 wurden, wie man sieht, durch das hybride Rahmenfragment FRAG A1 ersetzt. Das hybride Rahmenfragrnent FRAG A1 wird anschließend mit dem Rahmen A verkettet, der an Bezugszahl 18 dargestellt ist.
Nach einer ähnlich ablaufenden Hybridisierung ist der daraus resultierende hybride Rahmen A an Bezugszahl 19 dargestellt. Wie man sieht, enthält der hybride Rahmen A jetzt diejenigen markierten Konstrukte, die entsprechend dem Inhalt der Rahmenfragmente FRAG A2 und FRAG A1 modifiziert wurden. Auf diese Weise kann eine komplexe Rahmenstruktur für einen bestimmten Zweck modifiziert werden, ohne daß eine gänzlich neue Rahmenstruktur erstellt werden muß.
Figur 9 zeigt abschließend ein logisches Flußbild, das den Aufbau einer neu definierten oder hybriden Rahmenstruktur gemäß der vorliegenden Erfindung erläutert. Wie man sieht, dient der Entscheidungsblock 22, nachdem zunächst wie in Block 20 begonnen wurde, zur Erläuterung der Feststellung, ob der betreffende Rahmen oder das betreffende Rahmenfragment einen Hinweis zu einer Rahmenstruktur enthält oder nicht. Wenn ja, zeigt Block 24 den Zugriff auf den referenzierten Rahmen. Anschließend zeigt Block 26 die Feststellung, ob der referenzierte Rahmen oder das referenzierte Rahmenfragment einen Hinweis zu einem zweiten Rahmen oder Rahmenfragment enthalten oder nicht. Wenn ja, zeigt Block 28 den Zugriff auf das nächste referenzierte Rahmenfragment beziehungsweise die nächste referenzierte Rahmenstruktur. Wenn nicht, wird der resultierende hybride Rahmen entsprechend Block 32 aktiviert.
An diesem Punkt wird der erste referenzierte Rahmen mit dem nächsten referenzierten Rahmen verkettet, wie in Block 30 beschrieben wird, und das Programm kehrt zu Block 26 zurück, um festzustellen, ob eine zusätzliche Rahmen- oder Rahmenfragmentreferenz vorhanden ist, die eine zweite Verkettung erfordert. Enthält das aktuelle Rahmenfragment oder die aktuelle Rahmenstruktur keinen Hinweis auf einen anderen Rahmen oder enthält das ursprüngliche Rahmenfragment oder die ursprüngliche Rahmenstruktur keine Referenz zu einem anderen Rahmen, wie in Block 22 gezeigt wird, dann zeigt Block 34 die Auflösung des betreffenden Markierungsbezugspunktes innerhalb des spezifischen Rahmens. Im nächsten Schritt, wie in Block 36 erläutert wird, werden die an dem referenzierten Punkt in dem Rahmen enthaltenen Verarbeitungs- und Formatierungsinformationen abgerufen. Schließlich wird der Teil des Datenstroms, der im Bereich der Markierung liegt, entsprechend der abgerufenen Verarbeitungs- und Formatierungsinformation verarbeitet und das Programm ist beendet, wie in Block 40 dargestellt ist.
Die vorliegende Erfindung beschreibt demnach eine Verbesserung des Konzepts von Rahmenstrukturen, die Formatierungs-, Verarbeitungs- und Ressource-Informationen enthalten, welche von Markierungselementen innerhalb eines Datenstroms referenziert werden können, indem die schnelle und effiziente Modifizierung existierender Rahmenstrukturen ermöglicht wird, ohne daß eine komplette Rahmenstruktur erstellt werden muß. Diese Aufgabe wird erreicht durch Erstellen eines Rahmenfragments, das nur diejenigen Verarbeitungs-, Formatierungs- oder Ressource-Informationen enthält, die in dem existierenden Rahmen modifiziert werden müssen. Durch Verkettung von Rahmenfragmenten und Rahmenstrukturen gemäß der vorliegenden Erfindung ist es möglich, eine bestimmte Rahmenstruktur für eine bestimmte Anwendung anwenderspezifisch anzupassen, ohne daß eine vollständige Rahmenstruktur erstellt werden muß oder eine existierende Rahmenstruktur modifiziert und entfernt werden muß, die notwendigerweise zu einem späteren Zeitpunkt in ihrer ursprünglichen Form wieder gebraucht wird.

Claims

1. Ein Verfahren zum Übertragen von Dokumentendaten und Formatierungsinformationen von einem ersten Anwendungsprogramm auf ein zweites Anwendungsprogramm, wobei das Verfahren aus folgenden Schritten besteht:

- Generieren der Dokumentendaten unter Verwendung des ersten Anwendungsprogramms, wobei diese Dokumentendaten eingebettet Formatierungszeichen enthalten,

- Gesondertes Erstellen eines ausgewählten Formatierungsrahmens, der Bearbeitungsaufrufe als Teil des Dokumentendaten-Generierungsschritts enthält, wobei jeder dieser Bearbeitungsaufrufe einem der Formatierungszeichen zugeordnet ist,

wobei dieses Verfahren dadurch gekennzeichnet ist, daß es ferner die folgenden Schritte enthält:

- gesondertes Erstellen (13, 14) wenigstens eines Formatierungsrahmenfragments, das einen Bezug zum ausgewählten Formatierungsrahmen hat, dieses Formatierungsrahmenfragment in seinem Inneren wenigstens einen Bearbeitungsaufruf aufweist, die Dokumentendaten eingebettet wenigstens ein Zeichen enthalten, das auf das Formatierungsrahmenfragment Bezug nimmt, und

- Bearbeitung der Dokumentendaten unter Verwendung des zweiten Anwendungsprogramms durch Erfassen der eingebetteten Formatierungskennzeichen und durch Zugriff auf die Bearbeitungsaufrufe von dem ausgewählten Formatierungsrahmen und von diesem wenigstens einen Formatierungsrahmenfragment aus.

2. Das Verfahren gemäß Anspruch 1, das ferner beinhaltet das gesonderte Übertragen der Dokumentendaten und des ausgewählten Formatierungsrahmens auf das zweite Anwendungsprogramm.

3. Das Verfahren gemäß Anspruch 1, in dem der Schritt des Erstellens des wenigstens einen Formatierungsrahmenfragments durch einen Urheber des Datenstroms durchgeführt wird.

4. Das Verfahren gemäß Anspruch 1, in dem der Schritt des Erstellens des wenigstens einen Formatierungsrahmenfragments durch einen Endanwender des zweiten Anwendungsprogramms durchgeführt wird.

5. Das Verfahren gemäß Anspruch 1, das ferner den Schritt des Abspeicherns des Formatierungsrahmenfragments in einer wiedererkennbaren Form beinhaltet.

6. Das Verfahren gemäß Anspruch 1, das ferner den Schritt des Erstellens eines zweiten Formatierungsrahmenfragments aufweist, in dem ein Hinweis auf das wenigstens eine Formatierungsrahmenfragment enthalten ist.

7. Das Verfahren gemäß Anspruch 1, in dem die Schritte des gesonderten Erstellens eines ausgewählten Formatierungsrahmens und des wenigstens einen Formatierungsrahmenfragments unter Anwendung des ersten Anwendungsprogramms durchgeführt werden.

8. Das Verfahren gemäß Anspruch 1, in dem der Schritt des gesonderten Erstellens eines ausgewählten Formatierungsrahmens unter Anwendung des ersten Anwendungsprogramms, und der Schritt des Erstellens des wenigstens einen Formatierungsrahmenfragments unter Anwendung des zweiten Anwendungsprogramms durchgeführt werden.

9. Das Verfahren gemäß Anspruch 1, das ferner den Schritt des Abspeicherns des ausgewählten Formatierungsrahmens und des wenigstens einen Formatierungsrahmenfragments in einer Speichervorrichtung, die vom Datenverarbeitungssystem erkannt wird, beinhaltet, und in dem das zweite Anwendungsprogramm von der Speichervorrichtung aus auf die Verarbeitungsaufrufe zugreift.

10. Das Verfahren gemäß Anspruch 1, in dem die Schritte des gesonderten Erstellens eines ausgewählten Formatierungsrahmens und des wenigstens einen Formatierungsrahmenfragments unter Anwendung des ersten Anwendungsprogramms durchgeführt werden, und das ferner den Schritt des gesonderten Übertragens der Dokumentendaten, des ausgewählten Formatierungsrahmens und des wenigstens einen Formatierungsrahmenfragments auf das zweite Anwendungsprogramm beinhaltet.