OpenDoc Technology: Basic Concepts

by Robert Tycast

The last issue of The Developer Connection News introduced the set of technologies called OpenDoc Technology. This article focuses on this core technology that lets us create compound documents.

Electronic Document Evolution
Electronic documents began with the first set of punched cards produced for the first card reader/printer combo. The data formats were limited to what a Hollerith code could contain, and editing meant getting to a card punch and repunching the text - line by line. And let's not forget the special features - like when the deck was dropped on the floor and instantly an aleatoric document was produced!

Then came the teletype with paper tape reader/punch. But, it was hardly a breakthrough. Data formats were greatly limited and editing was cumbersome. The only real improvement was that the confetti produced by the punching process was round, and hence lacked the sharp edges produced by the card punches!

Enter hardcopy terminals. Yes, they truly allowed real editing of a document but at the expense of yards of paper - and acres of trees. The editing process was cumbersome, requiring frequent printing of the document to verify if the entered commands had improved or munged the document.

Screen-based editors heralded in the modern age of word-processors. Data formats were improved. It became possible to create documents with large character sets, with diacritical marks (like accents and cedillas), and special effects like sub- and superscripting. Still, you had to print out the document to see the end result. And, artwork had to be manually produced, cut with a razor, and pasted with adhesive into place for the final step in production.

Today's word processors allow electronic cutting and pasting of text and artwork in formats understood by the word processor. The layout and fonts produced on the screen can match the final printed output creating a WYSIWYG application.

Though a modern word processor can handle a large variety of data formats they are still limited to the formats built-in at the time the product was produced. And often the support for non-native formats results in a loss of fidelity to the original. Of course a format that was not anticipated requires the purchase of a new product that supports it.

Possibly most irritating are the hoops you must jump through when editing a section of a document that contains data foreign to the host application. You must invoke the application that created the original data, move to a different screen or window, edit the data, save it, and reinsert it into the document that they are working on. Pretty cumbersome!

Document-Centric Computing - The Future!
Yes, we've come a long way since the days of punched-cards. But even today's environment focuses more on the applications used to create a document and less on the actual content and layout of the document itself. Since the document is the end and the applications are the means, this situation seems backwards.

Document-centric computing aims to put focus back on the content and layout of the document. You start with an empty document shell. The document grows as parts of various types and formats are added. During this growing process, the document designer can move and resize the parts until the desired layout is achieved. Changes to the parts can be made in place, without leaving the document and without having to stop and think about which application created the original.

Stationery
OpenDoc code will be delivered not as discreet applications to run, but rather as electronic stationery that is used to assemble a particular application or document. Stationery might be represented on the desktop as a pad or stack to communicate the metaphor graphically. For each type of part that is available in the system, a corresponding pad of stationery will exist representing that part-type. To add a different parts to the document, simply "tear-off" a piece of that stationery, and drop it into the document.

A Peek Under the Covers
The only executable in the system is the document shell. It provides four functions: layout management, storage, event handling routines, and the window used by the document itself.

Layout Management
Each part in a document will be given its own area, called a frame. Into that frame the part is free to render itself in its own particular way. As the user adds parts to the document, the shell is responsible for negotiating with the new part for the position and size (geometry) of the frame. A part has to be prepared to be flexible because it can't make any assumptions about the geometry of the frame it's going to get. Additionally, the situation is dynamic as you can either move and resize a frame manually, or the addition of a new part might generate a size or position change as another round of negotiation is triggered by the need to fit another frame into the document.

Storage
Storage can exist in a number of ways. There is persistent storage, which basically means the form of the document when it is written out to a disk (or other form of retrievable storage), there is in-memory storage for objects, and finally there is storage for clipboard use.

Bento technology is the architecture used by OpenDoc technology for all of these storage methods.

Event handling
The document shell is responsible for receiving all events for the document and delivering them to the appropriate part. There are two sorts of events handled: UI and semantic.

A UI event is generated by an interaction between the user and the windowing system. Some UI events are mouse movements, button clicks, and keyboard input.

A semantic event is associated with the actions that the user specified explicitly or implicitly. Some semantic events are OPEN, CLOSE, MOVE, PRINT, and DELETE.

Thus when a user clicks on a menu bar, a UI event is generated that results in the appearance of the menu pull-down. When the user selects "PRINT", for example, a semantic event "PRINT" is generated.

The semantic event mechanism is part of the OSA (Open Scripting Architecture) that lets programmers build script support into their parts.

Window
The document shell is responsible for providing the code that implements the simple window that represents a blank document. This is the only window associated with the document. Each frame is a region or area within the main document window, and is not a window by itself.

Part Handlers
The shell isn't very interesting without some parts to put into it. The unit of deliverable code in OpenDoc technology is a part handler. The part handler implements the specific behavior of the stationery it represents. Thus, a text part has word-processing abilities, while a spreadsheet part excels at producing rows and columns of numbers to be totaled.

Part handlers will come in two flavors: part editors and part viewers. A part editor is a full-function implementation that lets a user create or modify a part. A part viewer, on the other hand, is a light-weight version that only knows how to render the part, and cannot create new parts or modify existing parts.

It is expected that part editors will be produced as products to be sold, while part viewers will be freely distributed. This will allow two users to share a document. The first user, the author of the document, will naturally have licenses for all of the parts placed into the document. But the second user need only have the part viewer to view and print the document.

Ready for a Test Drive?
Volume 3 of The Developer Connection for OS/2 CD-ROM contains preliminary OpenDoc alpha kit.

Footnotes:

 * 1) aleatoric music, also called chance music, was produced by John Cage who had a penchant for dropping glass vases on stage creating a random, but hopefully, musical effect. Aleatoric documents, lines in random order, seldom produce a pleasing effect in their owners.
 * 2) MUNG is derived from the command used to invoke TECO macros a popular editor in the days of hardcopy terminals. The term was coined because the complexity of the TECO commands were such that they had a tendency to destroy or "mung" the documents to which they were applied.)

About the Author
Robert Tycast is an Advisory Programmer in the OS/2 Development group. Over the last 15 years, Robert has had project experience in X11, AI Technology (LISP and OPS5 support), and technical workstations (VMS and ULTRIX).