piloting oda — the poda project

Piloting O D A - The P O D A Project 183

J. N E L S O N , C. BATHE, H. B U N Z , M. C O O N , P. K I R S T E I N , G. K R O N E R T , M. M A B R O U K , F. R E Y N A U D and P. ROBINSON

International Computers Ltd, Lovelace Road, Bracknell, Berks. RG12 4SN, UK

The PODA-2 (Piloting ODA-2) Project is an ESPRIT-funded collaboration involving most of the leading IT companies in Europe. This paper describes the ways in which the Project is promoting and advancing the ODA standard and how the results of the work are being exploited by the individual participants.

Project activities to promote the adoption of the standard include public demonstrations, the specification and validation of Document Application Profiles, the development of a toolkit and converters, the definition of an Applications Program Interface and technology transfer and liaison.

The Project is contributing to the advancement of the standard in a number of new ODA application areas such as hypermedia, security, data in documents, communicat ions requirements, editing, partial documents and printing.

Keywords: ODA, PODA, Applications, Demonstrat ions, API, Toolkit.

- - - - Joe Nelson holds Bachelor of Science (1964), Master of Science (1966) and Doctor of Philosophy (1968) degrees from Queen's University, Belfast.

He joined the Research and Ad- vanced Development Centre of ICL in 1969 where he worked on the Content Addressable File Storage Project and later initiated and managed the Image Research activity.

He transferred to ICL's Office Sys- tems Division in 1985 as ICL con-

~ t ~ - N \ ' ~ w / / / ~ sultant on Document Image Handling Systems. He is currently Manager, Multi-media collaborations in OFFICEPOW E R Applications Product Centre.

Joe Nelson is Project Manager of the PODA-2 Project.

Claus-Dieter Bathe, Dipl.-Ing., studied Electrical Engineering at the Techni- cal University of Berlin.

He joined Nixdorf Development in 1967, and for several years worked in Software Development, rising to Head of Department in 1979. Since 1984 he has been Nixdorf 's representative on various standards bodies involved with Office Systems standards, which is one of his main fields of interest.

From 1985-1987 Claus was the Nixdorf Project Leader in the ESPRIT

Project ' INCA' . He continued this role in the PODA Projects PODA-1 (1988-1989) and now PODA-2.

North-Holland Computer Standards & Interfaces 11 (1990/91) 183-193

1. Introduction

ODA permits multi-media documents to be exchanged between heterogeneous computer systems in such a way that a received document can be displayed, edited, stored or otherwise processed in a manner consistent with the originator's inten- tion. This very real user requirement is addressed by the PODA (Piloting the Office Document Ar- chitecture) Project.

The current PODA Project, PODA-2, is funded as part of the ESPRIT II programme. It started at the beginning of 1989 as a smooth continuation to the PODA-1 Project, and is planned to run until mid 1991. PODA-2 has the twin objectives of accelerating the development of ODA-based products and advancing the application of the ODA standard.

The partners in the project are as follows: British Telecom, UK (Partner) Bull, France (Partner) IBM, Germany (Partner) ICL, UK (Co-ordinating Contractor) Nixdorf, Germany (Partner) Oc6, The Netherlands (Partner) Olivetti, Italy (Partner) Siemens, Germany (Partner) Alcatel TITN ANSWARE (Partner) University College London (Associate Par tner / ICE).

Section 2 and 3 of this paper describe the two main activities in the Project which are respec- tively the promotion and advancement of ODA. Section 4 summarises what is being done to exploit ODA in product.

2. Promot ion of O D A

Promotional activities which are accelerating the adoption of the ODA standard consist of: - public demonstrations of interworking between

currently available office systems - the specification and validation of Document

Application Profiles to allow interworking between systems of different levels of complexity

- the development and increased usage of a toolkit to provide a common technology base for ODA product development

0920-5489/91/$03.50 © 1991 - Elsevier Science Publishers B.V. (North-Holland)

184 J. Nelson et al. / Piloting ODA

- t he d e f i n i t i o n of a n A p p l i c a t i o n s P r o g r a m m i n g

I n t e r f a c e ( A P I ) w h i c h wil l o f f e r a c o m m o n ap-

p l i c a t i o n s e n v i r o n m e n t for t he d e v e l o p i n g too l

se t

t he e s t a b l i s h m e n t o f t he P r o j e c t as a c e n t r e of

e x p e r t i s e fo r t e c h n i c a l l i a i s o n w i t h a r a n g e of

r e l a t e d ac t i v i t i e s a n d fo r t he e f f ec t i ve d i s s e m i -

n a t i o n o f i n f o r m a t i o n w o r l d w i d e .

Herbert Bunz studied physics at the University of Stuttgart, Germany. He received his PhD in 1987 in nonlinear chaotic dynamics. Afterwards his work was concerned with network management in connection with one of the major vendors of public X.25 networks. In 1990 he joined IBM at the European Networking Center at Heidelberg and he is working on communication aspects of multi-media applications.

Mike Coon graduated in 1965 in Ap- plied Physics after a student ap- prenticeship with ICT, an ICL pre- cursor. For four years after graduating he did postgraduate research in solid- state physics.

He has since worked at Sperry Uni- vac and ICL on operating systems and on Community Management. He also worked for a software house for eight years, on packet switch network management, police command and control and Ministry of Defence pro-

jects. Since 1986, Mr Coon has been a member of the ICL PODA team who are piloting Office Document Architecture.

. . . . Peter Kirstein did his undergraduate work at Cambridge University (UK), and his postgraduate work at Stanford University (US). He has been Profes- sor at the Department of Computer Science, University College London since 1973, and Head of the Depart- ment of Computer Science since 1980.

Professor Kirstein has been leading research projects in computer com- munications, computer networks, telematic services and related activities for

~ I 20 years. These include the early inter- connection of the US Arpanet with the British academic research network (JANET), early work in computer graphics, extensive work with electronic mail, OSI protocols, facsimile, network management and directories. Currently he is Chair- man of the International Collaboration Board of the Internet Programme, and member of a number of British Governmental committees on Computer Science Research.

Professor Kirstein is a Fellow of Engineering, and a Fellow of the British Computer Society, Institute of Physics, and Institution of Electronic Engineers.

G~nther Kr6nert, Dipl.-Math., studied mathematics/computer science at the Technical University, Munich and joined the Research Labs. of the Sie- mens AG in 1975. Now he works in the Application Programming Depart- ment and is responsible for the development of document editors. He con- tributed to the International standardization of O D A / O D I F and was project leader in several ESPRIT projects on that standard.

2.1 In terwork ing

T h e p u b l i c d e m o n s t r a t i o n o f i n t e r w o r k i n g be-

t w e e n h e t e r o g e n e o u s , s t a t e - o f - t h e - a r t , d o c u m e n t

p r o c e s s i n g s y s t e m s h a s p r o v e d to b e a m o s t ef fec-

t ive m e a n s o f p r o m o t i n g O D A w i t h p o t e n t i a l u se r s

a n d s u p p l i e r s . F o l l o w i n g succes s fu l d e m o n s t r a -

t i o n s a t t he H a n n o v e r C e B I T e x h i b i t i o n s of 1987

a n d 1988 [1] as p a r t of P O D A - 1 , a n d a t C e B I T '89

[2] as p a r t o f P O D A - 2 , O D A was d e m o n s t r a t e d a t

C e B I T '90 fo r t h e f i r s t t i m e in c o n j u n c t i o n w i t h

E u r O S I n e t as a n i n t e g r a t e d O S I faci l i ty .

E u r O S I n e t is a E u r o p e a n M a r k e t i n g A s s o c i a -

t i o n w h i c h p r o m o t e s a n d d e m o n s t r a t e s t he p r a c t i -

ca l a p p l i c a t i o n o f O p e n S y s t e m s in a m u l t i v e n d o r

e n v i r o n m e n t . O n t he E u r O S I n e t s t a n d 29 v e n d o r s

a n d 9 u se r s e x h i b i t e d a m i x of X.400 , F T A M ,

i i l Mbark Mabrouk, computer science engineer, is a software designer at Bull S.A. He received his engineer diploma and DEA (Diploma of Advanced Studies) at INSA (Institut National des Sciences Appliqu6es) in Lyon, France. He is preparing a PhD in Hy- permedia and document architecture.

Fransjois Reynaud graduated froql the Engineering school of the Ecole Suprrieure d'Electricit6 in Paris in 1981. After having worked in the fields of automation, scientific calculus and CAD, he joined Alcatel TITN AN- SWARE in 1984 to work within the frame of the ESPRIT Project HE- RODE. He is responsible for the design and integration of geometric and raster graphics editors within the PO- DA project.

Peter Robinson has been involved with the development of the ODA standard since 1984 as the ICL representative to the ECMA committee which published the first ODA standard, ECMA-101, in 1985.

From 1986 to 1989 he chaired the ECMA group developing a standardized print format and was the liaison representative to the ISO committee developing the Standard Page De- scription Language SPDL. From 1987 to 1989 he was the ECMA representa-

tive to the ISO committee developing the Document Style Semantics and Specification Language standard, DSSSL.

J. Nelson et al. / Piloting ODA 185

The Consortium Model

Siemens Rank Philips

Xerox Fig. 1. The CeBIT'90 demonstration configuration.

EDI, X.500 and ODA applications in four OSI models.

Using two editors, eleven converters and two printing services thirteen companies (eight PODA members plus Apple, Philips, Rank Xerox, Unisys and Digital) and UCL (on the CEC stand) took turns in playing different roles in two ODA scenarios (see Fig. 1). Both of these scenarios demonstrated the creation, transmission, receipt, editing, printing and display of documents conforming to the ODA T.502 (Level 1) and Ql12 (Level 2) Document Application Profiles using X.400 [3]. The models for the two scenarios were as follows:

The Office Productivity Model

This scenario accurately reflected a work situa- tion of two power generation companies, Electri- cit6 De France and Iberduero who are both OSITOP members. The scenario was concerned with the need for each of the companies to create production reports derived from input from several of their geographically remote power stations together with their own contribution.

This scenario demonstrated the activities of a group of chemical companies (Akzo, Exxon Chemical, Hoechst and Solvay) to produce a joint offer document to supply chemicals to Iberduero to satisfy its needs for 1990.

The demonstrations were well received by the visitors to the EurOSlnet stand, amongst whom suppliers, PTTs and software houses were well represented. In particular, most visitors asking about ODA appeared to have an understanding of its use and benefits.

As has been described, much has been demonstrated and promoted regarding interworking of editors and printers, but the potential uses of ODA for other applications such as storage and distribution systems have had very little exposure; these could prove to be equally important to users. These other application areas are described in section 3 and it is intended to demonstrate the results of developments in these areas in a later phase of the Interworking activity.

2 . 2 0 D A Tools and Their Application

The ODA ToolKit is a set of generic software to assist in the development of consistent and cost-effective ODA applications. The components have been developed by ICL and Bull under the auspices of the PODA project and tested in con- junction with other Project partners. ODA Toolkit components have been used in the demonstration of ODA interworking at the CeBIT Fairs over the last three years.

The ODA ToolKit comprises the following components:

- a n ODA API that supports the generation, access and manipulation of ODA documents held in a specially developed random access format called Stored ODA (SODA)

- a diagnostic tool for browsing SODA to facilitate debugging of applications using the API

- a diagnostic utility that outputs a tree representation of the logical or layout structures of an ODA document held in SODA

- a utility for processing a SODA file and converting raster graphics content in T.4, T.6 and bitmap formats to and from bitmaps

- an ODA Interchange Format Stream Manager that supports the conversion of SODA to and from the ODA interchange format ODIF


- a diagnostic tool for producing symbolic print- out of an ODIF encoded document

- an interactive browser for navigating, viewing and printing ODA documents

- an ODA Formatter which performs the Layout Process as specified in the standard, converting Processable form documents into the For- matted Processable form suitable for display or printing. In addition, an Autonomous Active Mailbox

has been developed in the Project. This satisfies the need for a permanently available facility to test and demonstrate ODA document transfer between sites without the need for elaborate, pre- paratory arrangements or manned intervention. A program in the mail machine scans the X.400 messages arriving at a designated mailbox and takes autonomous action depending on the contents of the message. This action is to return one of a number of previously prepared ODA documents. It is planned to enhance this to allow specified changes to be made to an incoming document and then the document to be returned to the sender.

The PODA Project has also developed software that converts an ODA formatted form, or formatted processable form, document held in SODA format to PostScript 5. This software supports conversion of ODA documents conforming to the ENV 41510 (Ql12) Document Application Profile containing multi-font character text, geometric and raster graphics types of content. The software outputs PostScript conforming to Adobe's Docu- ment Structuring Conventions V2.1. The software is fully compatible with the ODA Interchange Format Stream Manager and can be used together with the T.4, T.6 decoding facility to provide a full ODIF to PostScript conversion capability.

2.3 Applications Program Interface

Independent Software Vendors are companies that offer products which run on systems manu- factured by several hardware vendors. This is made possible by the emergence of 'clones' of proprietary systems, and of 'Open Systems' which offer standardized environments to programs.

1 PostScript is a registered trademark of Adobe Systems Inc.

Because many current office applications are highly dependent upon the internal structure the internal structure of the documents that they manipulate, they are .limited to handling documents with a particular proprietary document structure only. These programs are not portable outside their environment.

A standard Application Program Interface, ('API'), is needed to facilitate the writing of highly portable advanced office applications. These applications access and manipulate electronic documents independently of any underlying proprietary document structure.

Task groups within the PODA-2 project and under the aegis of the European Computer Manufacturers' Association (ECMA), are defining such an API. This will be a set of functions, based on the ODA standard, that supports the pro- grammer in terms of document features rather than ODA constituents and attributes. The experience of the PODA-2 partners in using existing ODA toolkits and their APIs is being freely transferred to this ECMA effort.

It is expected that the ECMA work will be adopted by ISO, X / O p e n and other standards promulgation bodies. It is also expected that companies and consortia will invest in the creation of toolkits that support and exploit the interface. Both expectations are encouraged by discussions that are already taking place. (See reference to ODAC in Section 4.)

An ODA API should support a comprehensive set of applications for general office usage. These applications include: document conversion, filing and retrieval, document input and document printing, security (for confidentiality and authentication) and report generation.

2.4 Technology Transfer and Liaison

Effective technology transfer is crucial to the successful adoption and promotion of ODA. This is being achieved through: - liaison with other projects and institutions. The

project is active in establishing liaison with related US activities, particularly the Internet Engineering Task Force (IETF) [4]. The inten- tion is to provide specific IETF members with complete ODA systems coming mainly from the PODA-2 Project. The feedback from the IETF user experience will be invaluable. The

J. Nelson et aL / Piloting ODA 187

aim will be to get ODA adopted within the Internet community with the ultimate objective of large-scale adoption both by users and vendors.

- the education of potential users and suppliers to the opportunities and benefits of ODA. Pub- lic demonstrations such as CEBIT'89 are obvi- ously a very effective means of achieving this. The formation of the EurOSInet ODA Sub- group, which was a PODA-2 Project initiative, has significantly increased the effectiveness of the promotion of ODA and OSI standards and has led to the use of ODA technology by many companies outside the project.

- increased awareness and understanding of ODA in the appropriate standards bodies. PODA Project Management has established a formal liaison directly with TC29, the Technical Com- mittee within ECMA which is responsible for the development of the ODA standard. Input to other standards bodies such as ISO and CCITT is normally via ECMA, after refinement and formal endorsement in TC29.

rs '

/ / / , ~ / 2 , ,

r , , , J , , , j i ~ , ~ I , i Tree s ~ a c t u r e s i

J i , , , i , '

Content pot t3ons

Fig. 2. The hyperdocument model architecture.

3 . A d v a n c e m e n t o f O D A

The ODA advancement activity is evaluating user and technical requirements in a number of key application areas resulting in the development of prototypes and related extensions to ODA through the standards bodies. The application areas addressed include hypermedia, partial documents, communication requirements, data in documents, editing and security.

3.1 Hypermedia

Hypermedia is a means of structuring information in a network of nodes interconnected by links [5]. Nodes can contain text, graphics or any form of data and users navigate through a hypermedia system by selecting links between nodes [6].

Considering the richness of ODA, and the fact that a huge amount of information already exists in corporate document databases, it is possible to build a hypermedia document (hyperdocument) model which will have real, practical application by combining hypermedia technology and the ODA document representation.

The model defined in the Project aims to ad- dress the following objectives: - to reference existing corporate document data-

bases, - to interchange part or all of a hyperdocument

between heterogeneous document processing systems,

- to guarantee the hyperdocument database and applications validity for a long period of time. The architecture of this model consists of three

hierarchical layers (Fig. 2): - the content layer as defined by ODA parts 6, 7

and 8, - the document architecture layer as defined by

ODA part 2, and - the hyperstructure.

The hyperstructure is the highest level layer and is a network of nodes and links which constitute a hyperdocument. The main characteristics of the hyperstructure are: - independence from the node contents, - s h a r i n g of node contents between different

nodes. The features of this model enable existing ODA

documents to be integrated into a hyperdocument database as well as allowing different user views of the same set of documents.


A prototype based on this model has been developed and demonstrated in the Project. It employs two tools to generate and browse hyper- documents: - Hyperizer, - MicroView.

Hyperizer interprets markups inserted in one or several 0 D A documents and generates a hyperstructure based on those documents. MicroView is a utility which offers the user a means of tracking from one node to another and of using the ODA structure to browse the node content.

3.2 Partial Documents

There is currently no provision in the ODA standard for the storage and interchange of parts of the logical structure of a document. Practically, however, there is a requirement for users to be able to access and manipulate parts of documents.

Partial documents find application in: - easy-to-use text modules and standard phrases

in multiple documents - centralised maintenance of text modules such

as forms - one-time storage of bulky content items - specific servers dedicated to one content archi-

tecture, e.g. image or dedicated to certain sensi- tive content, e.g. signatures for authentication

- integration of externally generated text into documents

- h y p e r m e d i a applications supporting user-de- finable links between content portions of the same or different documents. The consequent technical requirements fall into

two main categories: (a) Incomplete documents and fragments The Project has proposed solutions to the problem of splitting ODA documents for independent, distributed storage and processing. (b) References Different types of references within and between ODA documents have been defined in detail, together with their functional specifications.

These user and technical requirements are being mapped to the extended ODA model. Technical requirements overlapping other extensions such as hypermedia are being identified and studied in more detail.

3.3 Communication Requirements

To enable the electronic interchange of documents in a heterogeneous environment common protocols like the OSI protocol stack and a common document architecture like ODA are necessary prerequisites. Currently within PODA-2, electronic mail (X.400) is used for interchanging documents. Because of the store and forward nature of electronic mail, interactive applications like searching, retrieving and storing documents in a remote library; joint editing; etc., are very re- stricted.

The distributed Office Application Model (DOAM) [7] provides a general framework for these interactive applications. Distributed office applications are modelled within a client-server model and an access protocol, based on remote operation, is used as the standard way for a client to access the server. The application service elements provide the communication function and implement the access protocol. One of the first standardized applications realizing DOAM and the underlying communication is Document Filing and Retrieval (DFR) [8]. D F R provides the functionality for complete documents to be stored and searched in, and retrieved from, a library on an OSI network. The DFR-Document - Store allows the combination of documents into groups which in turn can be arranged in a hierarchical tree structure. Security features like authentication, authorization and access control are included.

A D F R prototype, providing hypermedia access to ODA documents stored in a library, will be realized within PODA-2. Based on this prototype the interworking of the library access protocol with the document architecture will be investi- gated. In order to distribute documents, the access protocol and the document architecture have to embrace a consistent notion of partial documents. In addition, a unique naming and referencing scheme documents is required which can use directory services.

3.4 Data in Documents

Currently, the O D A standard supports com- pound documents containing character text, geometric graphics and raster graphics but is not yet able to embrace the concept that some of these


representations can originate as data, e.g. as form field entries or as business graphics. When the ODA standard was ratified two years ago it was clear that this was one important area where the standard needed to be extended. The strategy adopted in the PODA Project was to begin by analyzing user requirements for the incorporation of computable data and business graphics in documents. Then the technical requirements to match these user requirements were defined. The results of this work have been presented to the international standardization bodies who are specifying appropriate extensions to the ODA standard

The approach taken for data in documents was to separate the data as much as possible from the document in order to minimise the extensions to the standard itself and to establish an interface between documents and existing applications such as databases. The approach also includes providing information on the status and origin of the data such as the specification of a calculation rule or a reference to 'external ' data from a database, file or other document. The formats used for conversion and presentation are also part of the document.

Similarly for business graphics the approach taken was to keep the extension as separate as possible from ODA as currently defined. ODA has been extended by only one new attribute. This is 'generator-for-business-graphics ' which, in principle, works like other content generators. The new attribute refers to data which is the input to the business graphics generation process and also contains all the information necessary to control this process. Once the business graphic is generated it is seen and handled by the layout process as a geometric content portion.

3.5 Document Structure Editing

Two aspects of Document Structure Editing were addressed. These were:

exploitation of the logical document structure for editing purposes manual modification of the layout which has been generated automatically by the ODA layout process. The ODA document model in the H E R O D E

and PODA-1 projects revealed that a mismatch exists between the ODA model used to describe documents and the user's document model. To

eliminate this mismatch a state-of-the-art editor was extended such that the philosophy of what a document is and how it may be processed, as implemented in the editor, was expanded by map- ping in ODA concepts [9]. Based on the experience gained from this prototype we believe this to be the opt imum approach to developing an ODA editor product.

Editable office documents fall into three classes. These are: - those with very rigid layout rules which cannot

be changed when editing, e.g. forms - those with layout rules for which the automati-

cally generated layout may require to be revised by the user, e.g. reports and letters

- those for which the user creates the layout structure explicitly, e.g. invitations, flyers and advertisements. Current O D A / O D I F does not support layout

editing. By investigating state-of-the-art editors the user requirements for an appropriate ODA extension were analysed. The proposal, which was developed and presented to the standardization bodies, is to modify the ODA automatic layout process such that new attributes are defined for those layout objects on which the user has per- formed manual layout editing. The layout process then takes those attributes into account, and pre- serves the corresponding layout parts, when gener- ating the document layout process.

3.6 Graphics and Colour

Two types of Graphics Content Architectures are defined in ODA. These are Raster Graphics which consists of dot matrix images (facsimile) and geometric Graphics which consists of discrete, well-defined, geometric entities such as circles, rectangles and lines. The general goal of the work in this area has been to integrate graphics and document concepts through the design of a raster graphics editor and a geometric graphics editor both of which implement current ODA principles. In line with ODA philosophy both editors are designed to be device- and application-independent. In addition, both editors will observe the ODA colour extension which defines several colour models of all types of content including some specific to raster graphics. The draft ODA colour addendum is currently undergoing the ISO ratifi- cation process. In order to achieve the objectives


described above, including conversion between colour models, both editors embody certain key elements. For the Raster Graphics Editor these are: - scanner connection software - an image formatter capable of matching the

image size to the specified dimensions of the document page

- an imager which can read black and white, monochrome (with different levels of intensity) or colour (with a range of colour definition) images and can display them on devices with different colour and monochrome capabilities

- the editor itself which not only provides facilities such as cut and paste, rotation, symmetry and clipping but also allows for the synthesis of an image from differently sourced components. For the Geometric Graphics Editor the key

elements are: - an ODIF decoder (actually a CGM decoder,

ISO 8632 CGM being the format imported in ODA) capable of internalizing any graphics file without making any assumptions about the coordinate encodings, number of colours, coordinate systems etc.

- an image formatter, as for raster graphics - a nonspecialised, bi-dimensional editor provid-

ing a comprehensive range of facilities such as creation of all standard graphics entities, geometric transformations and storage in picture libraries

- a self-adaptive CGM encoder allowing a picture decoded from a particular CGM format, i.e. with integer coordinates, 64 colours, bottom left coordinate origin etc., to be recoded into the same format after editing.

3. 7 Annota t ion and Revision Control

Annotation is the function of attaching markings to a document where the content of the markings may consist of text, drawings, voice or a combination of two or all of these. The annotation facility must satisfy the following user requirements: - A user must be able to annotate all or part of

the document. - A user must be able to bind multiple annota-

tions to all or part of the document. - A user must be able to annotate an annotation,

i.e. must be able to perform consecutive annotation.

- A number of users must be able to annotate a document at the same time. This should include simultaneous annotation of the same part of the document.

- Annotations can apply to either a single 'point ' in the document or a span of document content or structure, e.g. a paragraph, page or footnote. In addition, an annotation can refer to multiple spans, e.g. the case of a comment referring to a number of paragraphs in different parts of the document.

- Annotation parameters are to be provided which specify whether or not an annotation is revision-dependent or -independent. A revision-dependent annotation emerges only in document revisions that are specified in the document's revision dependency list. A revision independent annotation emerges in all revisions of a document; as if the annotation is a 'par t ' of the document.

- Three annotation classes are to be provided. These are: - user defined notations such as comment or

action item - standards defined notations such as editing

or publishing mark-ups - attributed annotations such as highlighting

or blacking out text. The function of managing document revisions

and their distribution is termed Revision Control and Management (RCM) with revision numbering and control automatically maintained by the RCM function. Under RCM a user may amend a document by identifying that part of the document that requires to be modified and then creating a new revision. More than one user can revise different parts of the same document simultaneously. A part being modified needs to be protected from other users' modifications.

Create revision and delete revision are the two primary functions involved in document revision. A revision is created when all the required modifications to the document are completed.

Document revisions and annotations have an associated security requisite. Users are ranked according to the security functions available to them. Document revisions and annotations have associated permissions which designate those users who are permitted access to the revision or annotation and the type of access allowed. Two types of permission are defined. These are read permission and modify permission.


The above set of user requirements for annotation and revision control management was defined in tile Project and is currently being mapped to technical requirements. It is planned, through input to the ECMA and ISO standards bodies, to extend the ODA standard to satisfy these requirements.

3. 8 Security

There is a very clear requirement for security mechanisms in document interchange. It is not a contradiction in terms to require security mechanisms in Open Systems. Even though one wishes to communicate with people and organisations at will, without having to devise special procedures for each new correspondent, it may still be a requirement that such interchange be controlled carefully.

The bodies defining the different levels and applications of the OSI Reference Model are working somewhat independently, but within a common framework. There is now an addendum to the ODA Standard [10] which was ratified in September, 1990.

The addendum covers the following provisions: to hide the whole or parts of the document from unauthorised persons (confidentiality) to check the correctness of the whole or parts of the content of the received document (integrity)

- to prove the origin of the whole or parts of the received document (authenticity, non-repudiation of origin). The security aspects of the addendum are in-

tended to supplement those provided by other OSI and telematic services, such as the features in X.400. While they are applicable to parts of the document, they also provide indications for the handling of complete documents.

The addendum goes far, but does not specify the processing and encipherment algorithms to be used. In the Security part of the PODA-2 project, we are carrying the work with the Standard to a pilot demonstration stage. We are filling in re- maining gaps in the standards necessary to provide a complete implementation. This includes specifying an RSA (Rivest, Shamir and Adleman) algorithm [11] for the Public Key systems, and DES (Data Encryption Standard) [12] for the confidentiality processes. It is also necessary to choose a method for providing the characteristics of a

message, i.e. a form of Hash; here we use the MD4 algorithm [13].

Based on these, we have defined a complete specification for securing whole documents. The specification has already identified certain problems in the Addendum compared with other OSI standards, which may require later updates. One difficulty is that O D A uses Personal names and X.500 uses Distinguished Names. Nevertheless it is hoped to distribute the certificates needed for security by X.500 Directory Services. Another is that some of the tools used will need updating; the sensitivity of encrypted messages or notarised messages to any change in bit patterns means that a more stringent set of Distinguished Encoding Rules may be needed rather than the Basic Encod- ing Rules [14] usually adopted for X.400 and X.500 systems.

There are further problems in interworking with current X.400 (1984) MHS implementations. We were not prepared to put in any modifications at the MHS level, to denote a different type of document for secure ODA and the previous sort; this would have required some changes to some of the MHS implementations. As a result, it was necessary to define something to indicate that the document is to be secured; this is done by modify- ing the Document Architecture Class. It is necessary to put a small change in all ODA implementations to ensure against failure if the new class is encountered.

Several partners intend to implement this specification onto their Office Automation Sys- tems. We then intend to demonstrate that we can pass complete documents between heterogeneous systems while providing the four security services of confidentiality, integrity, authenticity and non- repudiation of origin. In this activity, we will include prototype key distribution facilities both via Smart Cards and a Certification Authority. Some partners will also implement the full specification for securing parts of documents.

4. Exploitation

The variety of document processing systems available in the market place has not perceptibly decreased but sophistication has visibly increased. This is true for Unix-based Integrated Office Sys- tems and is even more evident for the leading


MS-DOS applications. The latest word processors support embedded graphics to exploit hardware such as laser printers and VGA screens. Use of networks and electronic mail is also increasing. Hence, the real requirement for information interchange standards is increasing both in complexity and opportunity. This is partially met in the MS- DOS world by considerably more availability of explicit impor t /expor t and conversion facilities to popular rival products. However, it is the international standard, Office Document Architecture (ODA) which will allow the preparation, filing, retrieval, transmission, viewing, printing and publishing of complex documents to be accomplished with ease.

The PODA-2 Project has achieved both the promotion of ODA by means of multi-vendor demonstrations and the advancement of the ODA standard through the specification of the user and technical requirements in a number of key office applications. The results of the product are being and will be exploited in product development.

ICL intends to introduce its first ODA products supporting Level 2 ODA within ICl's integrated office information system, OFFICE- POWER, during 1990. OFFICEPOWER users are already able to create, manipulate, file and retri- eve documents containing graphical content and character text; ODA opens up worldwide communication of such documents. It is ICL's inten- tion to upgrade its strategic document storage database POWERFILE, which runs on VME and UNIX, from its current support of an intercept of ODA to full support of ODA.

Bull ODA products will appear as part of the Bull Distributed Office Automation offering during 1991. ODA documents will be used with mail, filing, multimedia and other office applications. Converters will be available to migrate documents from Bull current document formats including DSA 101, to ODA documents.

Siemens and Nixdorf supported the standardization of ODA and had already gained practical experience with ODA implementations before they joined together to form Siemens Nixdorf Infor- mationssysteme AG (SNI) in October 1990. The first ODA converter, SICODA (SNI Converter for ODA), for the wordprocessor HIT was released in the last quarter of 1990. In 1991, further level 2 ODA converters will be available for the following components of the SNI Office System OCIS

(Office Communicat ion&Information Services): ComfoTex, OASE and TargonWord. They provide document interchange between the operating systems SINIX T M *, MS-DOS and BS2000, and also outside to other systems which support this level of ODA.

IBM have stated that their Integrated Informa- tion Architecture (IIA) forms a functional super- set of ODA.

In addition to the product plans of the PODA-2 partners DEC have made a press release announc- ing a programme for a CDA-ODA converter (product availability to be announced later in 1990) and Apple have made public their 'WOPODA' interface which will be maintained and enhanced by Apple computer and which is compatible with the Ql12 DAP.

An industrial consortium named ODAC (ODA Consortium) is expected to be formed by early 1991. The sponsoring companies include PODA-2 partners as well as other large organisations. The Consortium aims to develop a toolkit and APIs to support applications to meet requirements for US GOSIP and European E N s / E N V s and to be ex- tensible. The PODA results and experience in the use of the PODA toolkit will be available for ODAC to exploit.

5. Conclusion

This paper has described how the PODA Pro- ject is playing a leading role in developing and promoting the ODA standard.

The public demonstration of ODA interworking at the Hanover Fairs, most recently in con- junction with EurOSInet at CeBIT'90, has proved to be a most effective way of promoting the standard with both users and suppliers. The development and increased usage of the ODA toolkit coupled with the generation of strong support for an Applications Program Interface, which will offer a common applications environment for the development of the tool set, is providing a technology base for ODA product development.

A number of new application areas beyond document interchange are being developed in the

* SINIX is the UNIX T M of SNI. UNIX is a registered trademark of UNIX Systems Laboratories Inc.


Project. These include hypermedia, security, data in documents, structure editing, graphics and colour, communication requirements and partial documents.

There is clearly a worldwide commitment to the use of ODA for document interchange. The standard is well established with the standards bodies and a number of ODA product announcements have been made, clearly exploiting the results of the work on the Project. ODA is being increas- ingly widely recognised as the kernel from which a global integrated information architecture may be expected to be derived. The potential for ODA to evolve into this global integrated information architecture is building year by year and the consequent opportunities are enormous.

References

[1] E. Koether et al., ODA - from theory to real life, E T W '88.

[2] J. Nelson et al., ODA - the standard solution to document interchange, ETW'89.

[3] ODA Document Application Profile Ql12 - Processable and formatted documents - extended mixed mode, Pr ENV 41 510, EWOS, Paris, 1989.

[4] E.P. Gross, Proc. Sixteenth Iternet Engineering Task Force, Florida State University (February 6-9 1990) CRNI, Re- ston, VA.

[5] J. Conklin, Hypertext: introduction and survey, Computer (1EEE) (Sept. 87).

[6] M. Mabrouk and F. Richard, User requirements for an ODA hypermedia document base, Internal Technical Re- port to the ESPRIT 2374 project, 1989.

[7] ISO/IEC 10031 (Draft Final Text) Information technology - Text and office systems, Distributed-office-application-model (DOAM), 190-08-07.

[8] ISO/IEC DIS 10166 Information processing - Text Com- munication, Document Filing and Retrieval (DFR), May 1989.

[9] G. Kr6nert, Wird O D A / O D I F Bfirosysteme ver~indern, lnformationstechnik it 31 (3) (1990) 194-202.

[10] P. Kaijser, Draft addendum on security addendum, ISO/IEC JTC I / S C 1 8 / W G 3 N1586, February 1990.

[11] R.L. Rivest et al., A method for obtaining digital signatures and public-key cryptosystems; Commun. A C M 12 (February 1978) 120-126.

[12] Data Encryption Standard, FIPS PUD 46, NIST, Gaithersburg, 1977.

[13] R.L. Rivest, The MD4 Message Digest Algorithm (RSA DATA Security Inc., Redwood City CA, 1989).

[14] Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1) DAD1; ASN.I Extensions, IS 8825, ISO, 1988. (0X)IX