document model

Most early developers and users of desktop computing sys-tems thought in terms of application programs rather than focusing on the documents or other products being cre-ated with them. From the application point of view, files are opened or created, content (text or graphics) is created, and the file is then saved. There is no connection between the files except in the mind of the user. The dominant word processors of the 1980s (such as WordStar and WordPer-fect) were designed as replacements for the typewriter and emphasized the efficient creation of text (see word pro-cessing). Users who wanted to work with other types of information had to run completely separate applications, such as dBase for databases or Lotus 1-2-3 for spreadsheets. Working with graphics images (to the extent it was possible with early PCs) required still other programs.

This “application-centric” way of thinking suited pro-gram developers at a time when most computer systems (such as those running MS-DOS) could run only one pro-gram at a time. But increasing processor power, memory, and graphics display capabilities during the late 1980s made it possible to create an operating system such as Micro-soft Windows that could display text fonts and formatting, graphics and other content in the same window, and run several different program windows at the same time (see multitasking). In turn, this made it possible to present a model that was more in keeping with the way people had worked in the precomputer era.

In the new “document model,” instead of thinking in terms of individual application programs working with files, users could think in terms of creating documents. A document (such as a brochure or report) could contain formatted text, graphics, and data brought in from database or spreadsheet programs. This meant that in the course of working with a document users would actually be invoking the services of several programs: a word processor, graphics editor, database, spreadsheet, and perhaps others. To the user, however, the focus would be on a screen “desktop” on which would be arranged documents (or projects), not on the process of running individual programs and loading files.

Implementing the Document Model

There are two basic approaches to maintaining documents. One is to create large programs that provide all of the fea-tures needed, including word processing, graphics, and data management (see application suite). While such tight integration can (ideally at least) create a seamless work-ing environment with a consistent user interface, it lacks flexibility. If a user needs capabilities not included in the suite (such as, perhaps the ability to create an HTML ver-sion of the document for the Web), one of two cumbersome procedures would have to be followed. Either the operating system’s “cut and paste” facilities might be used to copy data from another application into the document (possibly with formatting or other information lost in the process), or possibly the document could be saved in a file format that could be read by the program that was to provide the additional functionality (again with the possibility of losing something in the translation).

Linking and Embedding

A more sophisticated approach is to create a protocol that applications could use to call upon one another’s services. The Windows COM (Component Object Model) uses a tech-nology formerly called OLE (Object Linking and Embed-ding). Using this facility, someone working on a document in Microsoft Word could “embed” another object such as an Excel spreadsheet or an Access database into the cur-rent document (which becomes the container). When the user double-clicks on the embedded object, the appropriate application is launched automatically, and the user sees the screen menus and controls from that application instead of those in Word. (One can also think of Word in this example being the client and Excel or Access as the server—see cli-ent-server computing). All work done with the embedded object is automatically updated by the server application and everything is stored in the same document file. Alter-natively, an application may be linked rather than embed-ded. In that case, the container document simply contains a pointer to the file in the other application. Whenever that file is changed, all documents that are linked to it are updated. Object embedding thus preserves a document-cen-tric approach but works with any applications that support that facility, regardless of vendor. The Macintosh operating system offers a similar facility. Apple and IBM attempted unsuccessfully to create a competing standard called Open-Doc. This should not be confused with the more recent Open Document standard from the popular open-source application Open Office. Meanwhile Microsoft’s COM, grad-ually introduced during the later 1990s, has been largely superseded by .NET (see Microsoft .NET). This reflects a shift in emphasis from a document model (within a sin-gle computer) to a more comprehensive “network object model.”

Document and object models are also increasingly important for working on the Web. This can be seen in the increasing use of XML documents and the Document Object Model (see xml and dom). This involves the use of a consistent programming interface (see api) by which many applications can create or process XML documents for data communication or display.