Opening Up OpenDoc
Volume Number: 11
Issue Number: 1
Column Tag: New Apple Technology
Opening Up OpenDoc™ 
Creating focused, intuitive, easy to use software,
while leaving room to add features.
By Jens Peter Alfke & Jordan Mattson, Apple Computer, Inc.
The Software Problem
As authors of software, we are faced with competing demands from our customers. On
the one hand, our users want applications that are easy to understand and use. On the
other hand, they also want them to be feature rich and up-to-date with the latest
system software releases from Apple.
In addressing users’ second demand - for feature-rich software (which is, after
all, more useful to them) - we often end up creating big, difficult-to-understand, and
difficult-to-use applications. Hence, in our quest to make our applications more
useful, we have (in reality) made them less useful. In addition, our big, monolithic,
all-in-one applications are difficult to maintain, so it’s difficult to add features and
adapt new technologies from Apple.
What we need to solve this dilemma is a new way to create applications that
allows developers to create focused, intuitive, and easy-to-use software, while at the
same time allowing them to easily add new features.
The OpenDoc Solution
Apple offers OpenDoc as the solution to these problems. OpenDoc provides an
architecture for applications that allows developers to create applications that are, in
reality, a collection of components. OpenDoc’s features enable developers and users to
create applications that meet their needs.
Component Architecture
In the OpenDoc world, applications are no longer large monoliths. Rather, they
are collections of interconnected components. The components that make up an
“application” in the OpenDoc world may or may not be from a single developer. In
fact, they may have been turned into an “application” or custom solution by
knowledgeable users, rather than the application developer.
In many ways, OpenDoc components can be mixed and matched to create custom
solutions, much as Open Scripting Architecture compliant and AppleEvent aware
applications can be crafted into custom solution. Of course, OpenDoc parts will have a
much finer granularity than today’s scriptable applications.
Compound Document Support
One of the direct benefits of the OpenDoc component architecture is that
components - or parts as they are referred to in the OpenDoc world - from different
developers are able to transparently work together to produce a single document for
the end user.
The benefit of compound documents for end users should not be underestimated.
In fact, during OpenDoc user testing, many users remarked, “you fixed the bugs”,
because they now could easily move from creating and editing one data type to another
in a single document.
Customizability
A second major feature of OpenDoc is that parts are scriptable. This allows end
users to customize their applications to meet their specific needs. This feature along
with the component architecture of OpenDoc also allows for easy combination of parts
from different sources into custom solutions.
Collaboration
The first version of OpenDoc implements a “draft” capability which allows you
to easily track versions of a particular document and revert to an earlier version of
need be. The OpenDoc architecture allows for authentication, digital signatures, store
& forward messaging, and simultaneous access to documents. These features will
appear in future versions of OpenDoc.
In response to the need to deploy the same application on multiple platforms,
OpenDoc was designed from the ground up as a cross-platform application
architecture. To this end, Component Integration Laboratories (also known as CILabs)
is releasing OpenDoc as a reference specification and implementations. Individual
vendors will then implement it on specific platforms. Various vendors have committed
to implementing OpenDoc on Mac OS, Windows, OS/2, and AIX. Additional commitments
are expected in the near future.
Replaceability
Because OpenDoc is designed to be a cross-platform architecture, it was
imperative that the major sub-systems of OpenDoc be replaceable. This would allow
for ease of adoption on various platforms, by allowing platform implementors to use
technology present on their platform to implement OpenDoc by adhering to the OpenDoc
reference specification.
Parsimony
Trying to address the plethora of issues involved in creating a cross platform
programming environment (e.g. drawing systems, coordinate systems, etc.) is
daunting. For this reason, the OpenDoc team has avoided addressing platform specific
issues (for example, OpenDoc does not deal with QuickDraw or QuickDraw GX), and has
instead focused on creating a human focused application architecture.
By creating a “light weight” architecture, the OpenDoc team has created a system
to can more easily be ported to various platforms.
For those who want a full featured framework that deals with the platform
specific issues which OpenDoc intentionally avoids addressing, Apple is developing OPF
- the OpenDoc Parts Framework. OPF, which is based on the Bedrock application
framework foundation, provides a complete cross-platform framework for the
implementation of OpenDoc parts.
OpenDoc Architecture Overview
Documents
In the OpenDoc world, we make a shift from an application-centric world to a
document-centric world. Along with this shift comes a change in the definition of the
word document.
Before the advent of OpenDoc, to quote the OpenDoc Technical Summary, “a
document has a type which is used to choose the application which will help the user
edit, view, and print the document.” With this starting point, we were quickly led to a
world defined and dominated by monolithic applications like Microsoft Word and Aldus
PageMaker.
In an OpenDoc world, our definition of document changes radically. A document
now is a collection of parts.
Parts
As we said above, each and every document in the OpenDoc world is a collection of
OpenDoc parts. A part can be defined as, once again quoting the OpenDoc Technical
Summary, “the boundaries in the document where one kind of content ends and
another begins.” Therefore, each document is a collection of various pieces of content.
It is this attribute of the OpenDoc architecture that makes compound documents
natural.
OpenDoc parts can be embedded within any other part, and all parts are rooted
directly or indirectly within the root part. This attribute of OpenDoc parts allows for
the creation of extremely rich compound documents as you mix and match content.
Part Handlers
While OpenDoc parts contain the content within documents, they do not provide
any way to display or manipulate this content. These tasks are left to the part
handlers. Part handlers are responsible for displaying (both on the screen and in
printed form) the part; editing the part; and management of persistent and runtime
storage for the part.
Editors & Viewers - Part handlers are further broken down into two classes: editors
and viewers. Editors and viewers are exactly what their names imply. A part editor
provides the facilities to display, edit, and store a part, while a part viewer provides
all of this functionality, except the ability to edit a part.
If you are implementing OpenDoc part handlers, for every editor that you create,
you should also create a viewer. This will allow users who have purchased your part
editor to create documents using those parts that can then be viewed by other users
who have not purchased your part editor.
Of Parts, Part Handlers, and Objects
In getting a conceptual handle on parts and part handlers, it is often helpful to
map them to the more familiar world of programmatic objects. Taken together parts
and part handlers provide all of the features found in an object.
Parts provide the state information or field portion of an object, while part
handlers provide the behaviors or methods of an object.
With this conceptual mapping in hand, it should be clear that one can implement
within the OpenDoc application architecture any system that can be implemented using
object oriented programming techniques.
The Document Shell & Containers
The document shell provides the system specific facilities that manage the
interaction between the user and OpenDoc. The document shell is the container for all
of the OpenDoc parts for a specific document.
It’s possible to retrofit an non-OpenDoc application, so that it can embed OpenDoc
parts. Any application that has been so modified is called a container and acts in place
of the document shell for the parts that it embeds. The process of turning an existing
application into an OpenDoc container is called “containerizing”. Containerizing an
application is discussed later in this article.
OpenDoc Foundations
OpenDoc delivers its functionality by building on top of a number of technologies from
Apple and others.
Apple Events & the Open Scripting Architecture (OSA)
One of the key features of OpenDoc is customizability. If OpenDoc is to be
customizable, OpenDoc parts must be scriptable. Scriptability is brought to OpenDoc
through the use of AppleEvents and the Open Scripting Architecture. This means that
every OpenDoc part is fully scriptable, recordable, and attachable. Therefore, it is
possible to easily combine a collection of OpenDoc parts into a custom solution.
Bento™ Storage
Bento, a high performance storage system, which has been available on the
Macintosh for sometime provides the foundation for the OpenDoc storage system. By
adopting Bento, the OpenDoc team is providing authors of OpenDoc parts with a flexible
and high performance storage system.
Drag and Drop Manager
The Drag and Drop Manager is being used in Apple’s implementation of OpenDoc to
provide direct manipulation in the user interface of OpenDoc for Macintosh. With
OpenDoc for Macintosh’s dependence on OSA and the Drag and Drop Manager, you could
say that System 7.5 is OpenDoc ready and awaiting the release of OpenDoc for
Macintosh later this year.
SOM
Cleanly managing the dynamic linking of objects in the OpenDoc world is handled
by IBM’s SOM (System Object Model). The details of SOM and why it is important to
OpenDoc is discussed by Jens in another article (“Learning to Love SOM”) in this
issue.
As you can see from perusing this list of technologies, the OpenDoc team is
building on some of the best technology available to create OpenDoc.
OpenDoc Myths
There are a number of myths circulating that do a disservice to developers trying to
evaluate OpenDoc’s suitability to meet their needs. We’ll take this opportunity to
explode these myths.
OpenDoc is a Compound Document Architecture
The first myth that you encounter - and one which is unfortunately reinforced by
OpenDoc’s name - is that OpenDoc is solely a compound document architecture. As we
said above, it is true that OpenDoc supports compound documents, but as a component
application architecture, it is much more than a compound document architecture.
It is either OpenDoc or OLE
Another myth that confronts developers considering OpenDoc is that they must
either choose between OpenDoc or Microsoft’s OLE (Object Linking and Embedding).
This is simply not true. In fact, OpenDoc is a superset of OLE and fully interoperable
with OLE. This means that if you write an OpenDoc part editor, it is also a first class
OLE object. In fact, a number of highly experienced authors of OLE objects have
commented that the easiest way to implement an OLE object is to write an OpenDoc part
editor.
OpenDoc is incompatible with existing applications
Because of your ability to “ramp up” into OpenDoc - see our discussion of the
steps to OpenDoc below - developers can immediately take advantage of OpenDoc with
minimal work and more fully embrace the OpenDoc application architecture as
resources and product requirements warrant.
OpenDoc is Mac-centric
This myth could not be further from the truth. As we discussed before, OpenDoc
was designed from the ground-up as a cross-platform application architecture. The
designers of OpenDoc looked at all of the personal computer and workstation operating
systems during the OpenDoc design process. The result is a standard that is being fully
implemented on a number of platforms.
OpenDoc is hard
Moving to any new software architecture involves some work, but in comparison
to OLE 2.0, implementing OpenDoc parts is straight-forward. And when you consider
that, by implementing an OpenDoc part you also implement an OLE object, the extra