Normen gehen aus evolutionären Prozessen hervor; auch die hier abgehandelte Bürodokumentarchitektur ist noch nicht "festgeschrieben". Die Weiterentwicklung des Office Document Architecture (ODA) Standards wird noch einige Jahre dauern mit dem Ziel, dieses "offene" Modell zu erweitern um zum Beispiel komplizierte Layoutvorschriften auszudrücken. multi-mediale Dokumente zu erlauben, verschiedene Sicherheitsaspekte bei der Dokumentübertragung und -bearbeitung zu berücksichtigen oder Dokumente immer stärker zu integrieren und mit Datenbeständen und Büroabläufen zu verbinden.
Neben den bereits im Standard beschriebenen Content Architectures für Character Content, Geometric Graphics Content und Raster Graphics Content werden weitere Content Architectures hinzugefügt werden, wie zum Beispiel für mathematische Formeln, chemische Formeln etc. Es ist jedoch nicht zwingend, daß der Content zweidimensional darstellbar sein muß. Im Bürobereich kann es wünschenswert sein, Dokumente oder Teile von Dokumenten mit Sprachanmerkungen zu versehen, die änderbar und abrufbar sind. Um Sprachanmerkungen in dem standardisierten Dokumentenaustauschformat ODIF mit übertragen zu können, muß eine entsprechende Content Architecture für Voice Content Bestandteil des Standards sein. Es ist auch vorstellbar, daß Bewegtbild-Sequenzen in Dokumenten auftreten können. So könnte zum Beispiel in einem elektronischen Handbuch ein Rechteck erscheinen, in dem nach Anklicken auf dem Bildschirm eine Bewegtbild-Sequenz abläuft, die bestimmte Vorgänge besser beschreiben kann als es mit Text möglich ist. Diese Erweiterungen des Standards werden unterstützt durch die saubere Trennung von Document Architecture und Content Architectures in ODA.
TC29 in Vorreiterrolle
In den derzeitigen Standards sind zunächst keine Regeln oder Mechanismen enthalten, um beim Austausch von Dokumenten Schutzfunktionen vorzusehen. Insbesondere das anvisierte Ziel, ODA-Dokumente als Drehscheibe und anderem für den Informationsaustausch im Büro und Administration auf der Basis offener Rechnersysteme einzuführen, stellt eine starke Motivation dar, diese Lücke zu schließen. Die Vorreiterrolle übernimmt die ECMA-Arbeitsgruppe TC29, die die Erweiterung des ODA-Standards mit folgender Zielrichtung betreibt (ECMA-TGS):
- eine Sicherungsmöglichkeit des vollständigen Dokuments einzuführen,
- einzelne Bestandteile des Dokuments zu schützen,
- Zugriffsrechte auf einzelne Bestandteile des Dokuments zu spezifizieren, einschließlich der Möglichkeit zur Weitergabe von Rechten,
- die Integrität des Dokuments oder Teilen davon zu gewährleisten,
- die Urheberschaft auf das Dokument oder Teilen davon zu fixieren und (juristisch) nachprüfbar zu machen,
- das nachträgliche Anfügen von Anmerkungen und Kommentaren zuzulassen.
Die geplanten Erweiterungen des ODA-Standards werden als neue optionale Attribute festgelegt, die den bereits definierten Objekten und Objektklassen zugeordnet werden. Außerdem werden Ableitungsregeln formuliert, wie Sicherheitsregeln von hierarchisch höheren Objektdefinitionen in untergeordnete übernommen werden.
Folgende Attributklassen sind bereits identifiziert:
(1) Attribute für unmittelbare Sicherheitsmechanismen, wie zum Beispiel
- Zugriffsrechte ausgewählter Benutzer(klassen)
- Authentifizierung zum Beispiel durch elektronische Unterschriften, um Integrität und Urheberschaft zu manifestieren
- Verschlüsselung
- Kennzeichnung von Anmerkungen
(2) Darstellungs-Attribute, wie zum Beispiel
- Verbot von Ausdrucken oder unverschlüsselter Abspeicherung,
- Beschränkung der Darstellung eines Objekts auf bestimmte Terminals
- besondere Darstellung von Anmerkungen
(3) Attribute des Dokumentprofils, wie zum Beispiel
- Klassifikation eines Dokuments (geheim, streng geheim etc.)
- Liste von Zugriffsberechtigungen
- Verschlüsselungsverfahren
- Authentifizierung (siehe oben)
Als technische Grundlage der Sicherheitsmechanismen werden insbesondere Verschlüsselungsverfahren und Zugriffsrechtsmodelle untersucht und auf ihre Eignung überprüft.
Sicherheitsregeln selbst festlegen
Als Verschlüsselungsverfahren kommen sowohl symmetrische als auch unsymmetrische in Betracht. Die symmetrischen Verfahren (zum Beispiel DES) setzen den gleichen Schlüssel bei Sender und Empfänger voraus, während unsymmetrische Verfahren (zum Beispiel RSA) unterschiedliche Schlüssel einsetzen (DEN 83). Letztere werden so angewendet, daß jeder Benutzer ein Schlüsselpaar mit einem privaten beziehungsweise geheimen und einem öffentlichen Schlüssel besitzt, der an beliebige Kommunikationspartner ohne besondere Sicherheitsvorkehrungen weitergegeben werden kann. Damit sind unsymmetrischer Verfahren neben der reinen Verschlüsselung von Daten auch zum Erzeugen und Verifizieren elektronischer Unterschriften geeignet (Riv 78).
Über die Festlegung von spezifischen Rechten soll der Zugriff auf das Dokument oder auf Teile davon eingeschränkt werden. Dies kann zum Beispiel durch die Attribut-Zuordnung von Listen aller Berechtigten zu einem Objekt inklusive deren Berechtigungsklasse (zum Beispiel Lesen, Ändern) erfolgen. Alternativ beziehungsweise ergänzend hierzu kann die Zugriffsberechtigung auch durch Eingabe eines Paßworts, den Besitz einer bestimmten Kennung (zum Beispiel Kennkarte oder Chipkarte (Wei 85) oder Eigenschaft (zum Beispiel Zugehörigkeit zu einer bestimmten Benutzerklasse) erworben werden (Den 83). Hierbei besteht ein enger Zusammenhang zu Festlegungen auf übergeordneten Systemebenen (zum Beispiel Benutzerverwaltung).
Die festzulegenden Sicherheitsregeln für ODA-Dokumente müssen insbesondere gewährleisten, daß der Benutzer diese weitgehend selbst formulieren kann. Außerdem muß die Einhaltung einmal formulierter Sicherheitskriterien erzwungen werden.
Kompliziertes Layout
Wie in der ersten Folge beschrieben, sieht der derzeitige Standard vor, daß Frames rechteckige Bereiche mit fester Position und fester Dimension sind. Während der automatischen Layouterzeugung werden innerhalb dieser Frames rechteckige Blöcke erzeugt, die den Inhalt des Dokuments, also den Text oder Bilder enthalten. Die Bildung dieser Blöcke kann variabel gesteuert werden durch Attribute wie Separation oder Offset.
Kompliziertes Layout läßt sich bilden, wenn die Frames flexibel sind, das heißt wenn ihre Dimension und Position während der Layouterzeugung erst errechnet wird. Dafür sind grundsätzlich zwei Ansätze denkbar: Ähnlich wie bei der Berechnung von Blockdimensionen, wird für Frames explizit festgelegt, wie ihre Dimension und Position zu berechnen ist, zum Beispiel in Abhängigkeit vom einzufüllenden Inhalt. Dies würde zum Beispiel ermöglichen, daß in einem zweispältigen Dokument mit deutschem Text in der linken Spalte und englischem Text in der rechten Spalte, die entsprechenden Ansätze im Layout stets nebeneinander angeordnet werden. Der zweite Ansatz geht davon aus, daß für einen Frame eine optimale Dimension und Position vorgegeben wird; es wird aber zusätzlich definiert, wie sich Dimension und Position verändern dürfen und wie sich aus dieser Abweichung "Strafpunkte" ergeben (Ham 81). Das Layout des gesamten Dokuments wird schließlich so gestaltet, daß die Summe aller "Strafpunkte" minimal wird. Dieser Ansatz ermöglicht es, deskriptiv für eine Dokumentklasse ein "schönes" Layout zu definieren. Die Layouterzeugung wird dann im allgemeinen jedoch zu einem zeitraubenden Optimierungsprozeß, der kaum in einem interaktiv formatierenden Editor, sondern nur in einem Batch-Formatierer durchführbar ist. Durch Einführung von "Fences" kann das Dokument jedoch in Teilbereiche zerlegt werden, auf die sich die jeweilige Optimierung beschränkt. Dadurch kann der Aufwand für Layouterzeugung vermindert werden.
Durch die saubere Trennung von Document Architecture und Content Architectures erlaubt es gegenwärtig der Standard nicht, daß zum Beispiel mathematische Formeln zusammen mit Text in einer Zeile erscheinen, oder daß formatierbarer Text in Zeichnungen verwendet wird. Wird bei der Bearbeitung des Dokuments die Zeichnung zum Beispiel vergrößert, dann sollte der Bereich und die Position des formatierbaren Textes entsprechend verändert werden und eventuell sogar auch die Schriftgröße angepaßt werden. Dazu wäre eine enge Kopplung des Graphik- und des Textobjektes nötig, andererseits sollte jedoch die saubere Trennung von Document Architecture und voneinander unabhängigen Content Architectures so weit wie möglich erhalten bleiben. Bisher gibt es noch keine konkreten Ansätze in den Normungsgremien zur Lösung dieses Problems.
Tabellen können nahezu beliebig komplex sein. Es wird darauf ankommen, in ODA Konzepte einzubringen, die einerseits implementierbar und handhabbar sind, andererseits aber Gestalt und Struktur von Tabellen nicht zu sehr einschränken. Tabellen bestehen aus Zeilen und Spalten, wodurch eine zweidimensionale Anordnung von Tabelleneinträgen erreicht wird. Aus logischer Sicht können Tabelleneinträge Basic Logical Objects oder wieder composite Logical Objects sein, das heißt ein Tabelleneintrag könnte wieder eine Untertabelle sein. Das macht deutlich, daß Tabellen nicht in einer Content Architecture beschrieben werden können, sondern daß die Document Architecture erweitert werden muß. Es sollte auch möglich sein, mehrere benachbarte Tabelleneinträge zusammenzufassen zu einem einzigen Eintrag. Die Layout-Direktiven müßten erweitert werden, um die Layoutgestaltung von Tabellen und den Umbruch von Tabellen auf mehrere Seiten zu beschreiben.
Tabellen können auch als Spreadsheets betrachtet und bearbeitet werden. Dazu müssen die Inhalte von Tabelleneinträgen jedoch nicht als Zeichentext, sondern als Daten interpretiert werden. Zusammen mit Tabellen sollte also auch ein Datenkonzept in ODA eingeführt werden. Darauf wird im folgenden Kapitel noch näher eingegangen.
Werden Tabelleneinträge als Daten interpretiert, dann ist es auch vorstellbar, daß einfache Tabellen in einer anschaulicheren Form, nämlich als Bar Charts oder Pie Charts in Dokumenten dargestellt werden. Diese Charts können automatisch aus Tabellen generiert werden als Basisobjekte mit Grafikinhalt. Sie sind dann bequem indirekt edierbar durch Veränderung der Tabelleneinträge.
Noch gibt es in den Standardisierungsgremien keine Vorschläge für ein Konzept, das alle diese Aspekte berücksichtigt .
Stets als geschlossene Einheit übertragen
Gemäß dem derzeitigen Stand werden Dokumente stets als eine geschlossene Einheit übertragen, ohne jegliche Bezüge zu anderen Dokumenten oder Dokumentteilen. Solche externe Referenzen würden folgendes ermöglichen:
- Dokumentteile, wie zum Beispiel Anhänge, die dem Empfänger bereits bekannt oder für ihn nicht interessant sind, könnten bei der Übertragung durch eine externe Referenz ersetzt und weggelassen werden.
- Auch das getrennte Ablegen von Dokumentteilen würde dadurch unterstützt. Dies wäre zum Beispiel wünschenswert für Sprachanmerkungen oder Bewegtbildfolgen.
- Externe Referenzen würden auch die verteilte Erstellung und Bearbeitung von Dokumenten unterstützen. Von einem Stammdokument könnte zum Beispiel auf mehrere Teildokumente verwiesen werden, die an verschiedenen Stellen erzeugt werden.
Jedoch sollte auch das Konzept externer Referenzen mit dem Datenkonzept abgestimmt sein, weil dieses ebenfalls Bezüge zu Datenbanken, Büroabläufen usw. benötigt. Ein einfaches aber wichtiges Beispiel dafür ist das Erstellen von Serienbriefen aus Briefschablonen, in die Adresse und Anrede aus einer Datei oder Datenbank eingetragen werden.
Es gibt einige ESPRIT-Projekte, in deren Rahmen die Dokumentarchitektur ODA um ein Datenkonzept erweitert wird:
Minstrel (Projekt 59), "Models of Informations, Storage and Retrieval", versucht ODA in ein übergeordnetes Office Data Model zu integrieren, das die Basis für den Aufbau von Datenbeständen für das gesamte Unternehmen sein kann.
Multos (Projekt 28), "Multimedia Office Server", dagegen verfolgt einen anderen Ansatz. Neben der Layoutstruktur für die zweidimensionale Anordnung des Dokumentinhalts und der layout-unabhängigen Gliederung durch die logische Struktur, gibt es eine dritte Struktur, die sogenannte konzeptionelle Struktur, für das Datenkonzept (Gib 83). Von dieser konzeptionellen Struktur kann automatisch auf die logische Struktur abgebildet werden, von der dann in gewohnter Weise automatisch die Layoutstruktur erzeugt werden kann. Ähnlich wie die logische und die Layoutstruktur, würde auch die konzeptionelle Struktur einer Dokumentklasse in der Dokumentklassendefinition definiert. Es wäre dann zum Beispiel möglich, am Monatsende automatisch aus einem Teil der Unternehmensdaten in einer Datenbank automatisch einen Monatsbericht (mit logischer und Layoutstruktur) zu erzeugen.
Auch konzeptionelle Struktur
Ein vereinfachtes Prozeßmodell in Bild 1 zeigt diesen Vorgang: Neben der bereits bekannten logischen und Layoutstruktur existiert für ein Dokument auch eine konzeptionelle Struktur. Diese kann auf Grund der Dokumentklassifikation, die auch die konzeptionelle Struktur definiert und entsprechende externe Referenzen enthält, automatisch aus externen Datenbeständen generiert werden. sie kann jedoch auch explizit vom Benutzer bearbeitet werden, ähnlich wie die logische Struktur.
Ein solches Datenkonzept könnte auch die Abwicklung von Bürovorgängen unterstützen auf der Basis von Dokumenten als Informationsträgern. Dadurch sind diese automatisch durchgeführten Vorgänge für den Menschen jederzeit durchschaubar, nachvollziehbar und dokumentiert. Außerdem können bestehende Organisationsformen beibehalten werden. Allerdings werden noch einige Jahre vergehen bis ein solch mächtiger Standard diese Vorgänge, eventuell über mehrere Unternehmen verteilt, in offenen Systemen ermöglichen wird.
Literatur
Den 83
Denning, D.: Cryptography and Data Security, Addison Wesley, Reading Mass., 1983
ECMA-TGS
ECMA Task Group on Security (J. Mollier): Extensions to the Document Architecture to Inelude Attributes for the Control of Sesurity, ECMA/ TC29/85/47, September 1985
Ham 81
Hammer, M. et al.: An Integrated and Interactive Document Production System. Proceedings of the 1981 Office Automation Conference, AFIPS, March, 1981
Gib 83
Gibbs, S; Tsichritzis, D.: A Data Modeling Approach for Office Information Systems, ACM Transactions on Office Information Systems, Vol. 1, No. 4, October 1983, p.29-319
Riv 78
Rivest, R. L.; Shamir, A.; Adleman L.; A Method for Obtaining Digitai Signatures and Public-Key Cryptosystems, Comm. of the ACM,21, No.2, 1978,pp. 120 - 126
Wei 85
Weimann, J.: Chip-Karten: Realisierungs- und Anwendungsmöglichkeiten, Proc. Datenschutz und Datensicherheit, München, 1985, GI Informatik Fachberichte 113, P. P. Spies (HSG), Springer Verlag 1985, pp. 2632
*Die Autoren sind Siemens-Mitarbeiter in München
Auf Basic von ECMA 101
In den vorangegangenen fünf Folgen wurde der Stand der Normung und der Einfluß des Office Document Architecture (ODA) Standards auf Bürowerkzeuge beschrieben. Basic ist der Standard ECMA 101, der im Juni 1985 verabschiedet wurde. Andere Gremien, wie ISO, DIN und CCITT, entwickeln das Normenwerk innerhalb der vereinbarten Rahmenbedingungen weiter.
Teil 1 der mit dieser letzten Folge nun beendeten CW-Serie, erschien in CW Nr. 15, Seite 24. Die Teile 2 bis 5 wurden in den anschließenden Ausgaben 16 bis 19 unter der Rubrik Bürokommunikation abgedruckt. (CW Nr. 16, Seite 20; CW Nr, 17, Seite 39; CW Nr. 18, Seite 22; CW Nr. 19, Seite 18)