Auf der Grundlage des in den vorangegangenen Folgen beschriebenen Standards werden in mehreren Esprit-Projekten Werkzeugprototypen zum Umgang mit Dokumenten implementiert. Ergebnisse dieser Arbeiten fließen auch wieder in die Weiterentwicklung des Standards ein. Diese Folge betrachtet den Einfluß des Standards auf die Dokumentbearbeitung, die nächste Folge wird andere Vorgänge untersuchen, wie das Archivieren oder Erfassen von Dokumenten.
Ende 1984 wurde das Esprit-Projekt 121, "Herode" (Handling the Electronic Representation of Mixed Text-Image Office Documents based on ECMA Standard 101 /Hor 84, Hor 84/a unter Federführung von Siemens gestartet. Die Partner in diesem Projekt sind TITN (Paris), Queen Mary College Industrial Research Ltd. (London) und Centre de Recherche Informatique de Nancy. Dieses Projekt (Bild 1) umfaßt drei Komponenten, die auf der Grundlage des Standards entwickelt werden, nämlich eine Dokumentablage, ein Dokumenterfassungssystem und einen formatierten Dokumenteneditor. Entscheidend für den Benutzer ist, daß er mit diesen Komponenten über eine gemeinsame Benutzerschnittstelle kommuniziert, die ihm alle Werkzeuge, als ein einziges, mächtiges integriertes Werkzeug erscheinen läßt. Dokumente werden zwischen den Komponenten oder mit anderen offenen Systemen in standardisierten ODIF-Formaten ausgetauscht.
Dokumenteneditor mit Inhaltsarchitekturen
Als komplementär ergänzendes Projekt zu Herode wurde Anfang 1986 das Esprit-Projekt 1024, PODA (Piloting of ODA) ebenfalls unter der Leitung von Siemens gestartet. Partner sind Bull (F), ICL (GB), Queen Mary College Industrial Research Ltd. (GB), Olivetti (I), SEPT (F) und TITN (F). Dieses Projekt besteht aus zwei Teilen: (1) Der Austausch von Dokumenten in ODIF-Formaten zwischen existierenden Editoren und (2) Ergänzung von Herode um die in Bild 1 gezeigten Komponenten. Der formatierende Dokumenteneditor wird erweitert für zusätzliche Inhaltsarchitekturen, nämlich Bürografik, Daten, Sprache und Zeichentext in vollem Umfang. Der Druckservice akzeptiert Dokumente im ODIF-Format und der Generator für Dokumentklassen ist ein Werkzeug zum Erstellen und Ändern von Dokumentklassendefinitionen.
Bedeutung des Dokumentklassenkonzepts
Gemäß dem Standard werden Dokumente als Exemplare von Dokumentklassen ausgetauscht. Im Idealfall betrachtet jedes Werkzeug ein empfangenes Dokument ebenfalls als ein Exemplar der mitausgetauschten Dokumentklasse und adoptiert sich gemäß dieser. Solche Werkzeuge können im Vergleich zu nicht adaptiven Werkzeugen, den Benutzer von vielen Routinearbeiten entlasten (Krö 84).
Bild 2a und 2b zeigen schematisch einen Vergleich zwischen einer Bürolandschaft mit nicht adaptiven Werkzeugen und einer Bürolandschaft mit adaptiven Werkzeugen. Zur Be- und Verarbeitung von Dokumenten ist das Wissen über die Dokumentklasse, also Meta-Information, nötig. Im Falle nicht adaptiver Werkzeuge wird diese Meta-Information entweder getrennt vom Dokument zwischen den Bearbeitern ausgetauscht (Absprache, Erfahrung, Richtlinien), steht als Vordruck auf dem Dokument (Ausfüllanweisung bei Formularen) oder der Bearbeiter versucht, diese Meta-Information von einem oder mehreren existierenden Dokumenten dieser Klasse abzuleiten. Bei manchen Büroabläufen ist es nötig, aufgrund existierender Dokumente neue Dokumente zu erzeugen, wie zum Beispiel ein neues Formular auszufallen oder Parameter für ein Dienstprogramm zusammenzustellen.
Adaptive Werkzeuge passen sich an die Klasse des empfangenen Dokuments an, das heißt, ein Dokumentenerfassungssystem wird zum Beispiel zu einem Erfassungssystem speziell für Antragsformulare, oder ein Dokumenteneditor wird zum Beispiel zu einem Editor speziell für Jahresberichte. Entsprechend formulierte Büroprozeduren erlauben es auch, ausgehend von einem empfangenen Dokument ein neues Dokument automatisch oder halbautomatisch zu erzeugen.
Auch das Bearbeiten von Dokumenten wird durch das Konzept von Dokumentklassen erheblich vereinfacht.
Nehmen wir an, der Benutzer arbeitet an einem Bericht. Auf seinem Bildschirm sieht der Benutzer diesen Bericht "durch zwei Fenster": Das eine zeigt diesen Bericht gemäß dem WYSIWYG-Prinzip ("What you see is what you get") das heißt, es zeigt Text zusammen mit Bildern, so formatiert und positioniert, wie der Bericht auch auf Papier gedruckt würde. Das andere Fenster bietet dem Benutzer einen Oberblick über das gesamte Dokument, zum Beispiel in Form eines Inhaltsverzeichnisses.
Nun will der Benutzer das zweite Kapitel, das aus zwölf Seiten besteht, hinter das vierte Kapitel einfügen. In einem normalen WYSIWYG-Dokumenteneditor muß der Benutzer den Anfang des zweiten Kapitels selektieren, dann über die zwölf Seiten bis zum Ende des Kapitels scrollen und dieses ebenfalls selektieren, wodurch er den Bereich, der zwölf Seiten selektiert hat. Jetzt sucht er das Ende des vierten Kapitels und fügt den selektierten Bereich dahinter ein. Die Kapitel sind nun in der richten Reihenfolge, aber die Nummern der Kapitel und Unterkapitel stimmen nicht mehr und müssen vom Benutzer korrigiert werden. Mit dem Herode-Dokumenteneditor ist dies viel einfacher: Der Benutzer selektiert im Übersichtsfenster das zweite Kapitel und fügt es hinter dem vierten ein. Das ist alles.
Der Benutzer hat dadurch die logische Struktur des Dokuments verändert. Dadurch wird ein Re-Formatierungsprozeß gestartet, der den Inhalt der geänderten Kapitelfolge in der richtigen Reihenfolge auf eine Folge von Seiten plaziert. Auch die Kapitelnummern werden automatisch neu berechnet und entsprechend verändert. Bei diesen Aktionen wird der formatierende Editor von der Dokumentklassendefinition gesteuert.
Nehmen wir jetzt an, daß, der Benutzer einen weiteren Absatz ans Ende des dritten Kapitels anhängen will. Dazu selektiert er im WYSIWYG-Fenster den letzten Absatz des dritten Kapitels und fordert die Erzeugung des nächsten Objekts an dieser Stelle. Daraufhin wird ihm in einem Menü die Liste der an dieser Stelle erlaubten Objekte angeboten. Diese Liste ist natürlich abhängig von der Dokumentklasse und dem selektierten Objekt. In unserem Beispiel könnte die Liste zum Beispiel die drei Einträge "Absatz", "Bild" und "Kapitalüberschrift" haben, und den Benutzer wird "Absatz" selektieren. Diese Eigenschaft des Editors stellt sicher, das das Dokument immer konsistent mit der Dokumentklasse bleibt.
Editor und Datenerfassung eng gekoppelt
Hätte der Benutzer zum Beispiel "Bild" gewählt, so kann er im nächsten Schritt festlegen, ob er eine geometrische Grafik oder eine Rastergrafik haben möchte. Nehmen wir an, er wählt Rastergrafik, darin werden ihm Werkzeuge zum manuellen Erzeugen einer Rastergrafik, zum Beispiel Brushes, am Bildschirm angeboten und die Möglichkeit, ein Foto abzutasten und an der entsprechenden Stelle im Dokument einzufügen. An der zweiten Möglichkeit wird deutlich, daß der Dokumenteneditor und das Dokumentendatenerfassungssystem, auf das in der nächsten Folge näher eingegangen wird, eng gekoppelt sein müssen. Will der Benutzer ein Foto ins Dokument einfügen, so wird er aufgefordert, die Vorlage unter die Kamera des Dokumenterfassungssystems zu legen und zwei gegenüberliegende Ecken des abzutastenden Bereichs zu markieren. Alles andere wird automatisch durchgeführt. Beleuchtungsfehler, schiefes Einlegen der Vorlage oder ungenaues Markieren des Bereichs werden automatisch korrigiert. Gibt der Benutzer nicht explizit die gewünschte Größe des Bildes in seinem Dokument an, so wird das abgetastete Foto automatisch so vergrößert oder verkleinert, daß es die Breite des vorhergehenden oder nachfolgenden Textes annimmt.
Das Bild wird im Layout möglichst nahe an die Stelle positioniert, an der es eingefügt wurde. Es ist jedoch möglich, daß es aus Platzgründen auf die nächste Seite verschoben werden muß. Dann erscheinen Bild und Text im Layout in anderer Reihenfolge als in der logischen Struktur. Die logische Struktur ist jedoch unverändert erhalten geblieben, so daß nach einem Editierschritt beim nachfolgenden Formatieren wieder von der ursprünglichen Reihenfolge ausgegangen wird.
Ist das Bild eingefügt, und der Benutzer fordert nun die Erzeugung des nächsten Objektes, dahin wird ihm kein Menü angeboten sondern sofort das Objekt für die Bildunterschrift erzeugt, wenn die Dokumentenklasse vorsieht, daß jedes Bild eine Bildunterschrift haben muß. Die Funktion "nächstes Objekt erzeugen" ist auch für das Ausfüllen von Formularen sehr geeignet.
Die Architektur eines standardkonformen Dokumenteditors (Bild 3) wird im wesentlichen geprägt von Anforderungen, die vom Dokumentarchitekturmodell ableitbar sind, und von der WYSIWYG-Eigenschaft (Krö 85, Krö 85a, Hor 85).
Das Architekturmodell kennt zwei eigenständige Baumstrukturen, die logische und die Layoutstruktur. Beim Editieren wird die logische Struktur erzeugt oder verändert. Dazu ist ein Editor für die logische Struktur nötig. Die Layoutstruktur wird beim Formatieren erzeugt oder verändert. Sie kann auch vom Benutzer in einem Layoutrevisionsprozeß manipuliert werden, wenngleich dieser vom Architekturmodell her nicht unterstützt wird. Beide Prozesse benutzen die Operationen des Editors für die Layoutstruktur. Existierende Editoren sind entweder logisch oder layoutstrukturorientiert, aber stellen nicht beide Strukturen zur Verfügung.
Da sowohl die Objekte der logischen als auch der Layoutstruktur Attribute besitzen, arbeiten beide Struktureditoren auf attributierten Bäumen. Ferner muß gemäß dem Standard der Dokumenteditor an Dokumentklassen angepaßt sein. Dies kann mit Methoden erreicht werden, die im Compilerbau bereits erprobt und eingesetzt wurden ( Kas 85):Beide Struktureditoren werden von attribuirten Grammatiken (Rech 84, Wil 79) gesteuert. Wird ein Dokument im ODIF-Format empfangen, so werden aus dem Definition-Part die zwei attributierten Grammatiken abgeleitet und in die adaptiven Struktureditoren eingelesen. Das Ableiten dieser Grammatiken geschieht durch Ausfüllen und Kombinieren von Schemata für attributierte Produktionen, die die Information des ODA processing models gewissermaßen formal ausdrücken.
Insbesondere der Layoutstrukturbaum ist reich attributiert und Formatieren eines Dokuments bedeutet die Berechnung einer im Sinne der attributierten Grammatik korrekten Attributierung (Ken 76, Mön 84) des Baumes. Das WYSIWYG-Prinzip fordert interaktives Formatieren nach jedem Editierschritt, was jedoch im allgemeinen zu nicht akzeptablen Wartezeiten führt. Folgende zwei Strategien verkürzen diese Wartezeiten erheblich:
Das Konzept des inkrementellen Formatierens besteht darin, daß nicht das ganze Dokument neu Formatiert wird, sondern nur die Teile, die wirklich neu formatiert werden müssen.
Das heißt, eventuell bekommen Seiten nur neue Seitennummern, oder formatierte Blöcke werden als Ganzes verschoben.
Nach abgeschlossenem inkrementellen Formatieren ist das gesamte Dokument gültig formatiert. Der Bearbeiter sieht jedoch auf dem Bildschirm nur einen Teil des Dokuments, so daß es dem WYSIWYG- Prinzip bereits genügen würde, wenn dieser Teil gültig formatiert und entsprechend angezeigt würde. Diese Überlegung führt dazu, daß das
inkrementelle Formatieren verzögert ausgeführt wird: Nach einem Editiervorgang wird zunächst die nächste Umgebung konsistent formatiert und es wird markiert, welche Layoutobjekte dadurch ungültig formatiert sind, das heißt ungültig attributiert sind. Diese Objekte werden zunächst noch nicht formatiert. Daraufhin ist sofort wieder ein Editiervorgang zulässig, dem die gleiche Aktion folgt. Folgt jedoch nicht unmittelbar ein Editiervorgang, so wird schrittweise die inkrementelle Formatierung für die markierten Layoutobjekte durchgeführt, bis entweder das gesamte Dokument gültig formatiert ist oder der Benutzer wieder eine Editieroperation startet. Der Formatiervorgang nützt also die vom Editierprozeß nicht benützte Zeit voll aus, er behindert aber den Benutzer keineswegs in seinem Arbeitstempo beim Bearbeiten des Dokuments.
Basisobjekte haben ihre eigene Inhaltsarchitektur. Für jede vom Dokumenteditor akzeptierte Inhaltsarchitektur muß deshalb ein entsprechender Editor für Basisobjekte, zum Beispiel für Text und Rastergrafik existieren. Diese formatierenden Editoren müssen mit dem Layoutstruktureditor zusammenarbeiten und Attribute austauschen, ähnlich wie Scanner und Parser in Compilern. Der Editor für die Layoutstruktur gibt zum Beispiel die maximale Dimension eines Blocks als inherited Attribut an den Editor für Basisobjekte vom Typ Text. Dieser füllt den Text in diesen provisorischen Block ein und erzeugt dadurch einen tatsächlichen Block, dessen Dimension er als synthesized Attribut zurückgibt an den Editor für die Layoutstruktur.
Die Interndarstellung der beiden Dokumentstrukturen und des Dokumentinhalts erhält man durch Konversion des Object-Part von dem empfangenen ODIF-Format.
Der letzte Teil dieser Artikelfolge: gibt einen Ausblick, wie sich der ODA/ODIF-Standard in den nächsten Jahren weiter entwickeln wird um die Bearbeitung von ausgetauschten Dokumenten noch komfortabler zu ermöglichen. Entsprechende Attribute in den ODIF-Deskriptoren werden festgelegt und die dokumentklassengetriebenen Dokumentbearbeitungssysteme müssen dadurch entsprechend gesteuert werden. Soweit heute überschaubar, lassen sich auch diese Attribute in die attributierten Grammatiken einbetten, die ODA-Edition steuern.
Serie wird fortgesetzt
*Günther Krönert ist Siemens-Mitarbeiter in München.
Literatur
/Hor84/
Horak, W.: ESPRIT-Pilotprojekt. Handhabung von gemischten Text-/Bild-/Sprach-Dokumenten auf der Basis einer standardisierten Bürodokumentarchitektur, ONLINE84, Symposium P, 14.-17. Feb. 84, Berlin
/Hor84a/
Horak, W.:, Tartanson, F.; Coulouis, G.: Handling of mixed text/image/voice documents based on a standardised office document architecture, ESPRIT 1984 Conference, Brussels, North-Holland, pp. 395-410
/Hor85/
Horak, W.; Krönert, G.: Konzept eines Editors basierend auf der Büro-Dokumentarchitektur ECMA 101, Tagungsband ACM-Tagung "Büroautomation '85", B.G. Teubner Stuttgart, 1985, S. 62-69
/Kas85/
Kastens, U.: Anwendungen intelligenter Übersetzungsgeneratoren, GI-Kongreß (...) "Wissensbasierte Systeme", Springer-Verlag, S. 99-104
/Ken76/
Kennedy, K.; Warren, S.K.: Automatic Generation of Efficient Evaluators for Attributed Grammars. Conf. Record 3rd ACM Symp. Principies of Programming Languages, pp. 32-48, 1976
/Krö84/
Krönert, G.: Textverarbeitung auf Basis der standardisierten Dokumentarchitektur. Tutorium zur GI-Tagung "Offene Multifunktionale Büroarbeitsplätze und Bildschirmtext", Berlin, Juni 1984
/Krö85/
Krönert, G.: Anforderungen an ein Textverarbeitungssystem auf der Basis des Standard-Dokumentarchitekturmodells, Gl/ ÖCG/ÖGI-Jahrestagung 1985, Springer-Verlag, S. 879-891
/Krö85a/
Krönert, G.; Friedrich, J.; Schneider, U.; Lauber, G.: Requirements on a Formating Document Editor based on the ECMA Standard 101 , ESPRIT Technical Week'85, Brussels, North-Holland
/Mnö84/
Möncke, U.; Weisgerber, B.; Wilhelm, R.: How to Implement a System for Manipulation of Attributed Trees. 8. Fachtagung "Programmiersprachen und Programmentwicklung", Informatik Fachberichte, Vol. 77, pp 112-117, Springer, 1984
/Rech84/
Rechenberg, P.: Attributierte Grammatiken als Methoden der Softwaretechnik. Elektronische Rechenanlagen, 26 (1984), Heft 3, S. 111-119
/Wil79/
Wilhelm R.: Attributierte Grammatiken. Informatik Spektrum 2, 1979, S. 123-130