In many books and articles, including this one, you'll find references to other books and articles. These references identify the sources of particular information that either elaborates or reinforces the ideas presented in a book. Usually a book will quote from or present a short summary of the external information and then include a reference to the source.
Writers make references for two reasons. First, lawyers and copyright laws prevent wholesale duplication and plagiarism of another author's work—so you can't simply copy text from someone else's book and take credit for it yourself. The second reason is sheer efficiency. I've read books in which every 30-page chapter has 50 to 70 references to other works—a "Notes" section at the end of a book can take up more than a quarter of the book's total page count. If we didn't have references, writers would have to copy text from other sources into their own text, probably increasing the size of a book by a few orders of magnitude. Without references, books would be too large to hold, too expensive to print, too expensive to buy. Yes, references are a good thing.
Creating a compound document is much like writing a nonfiction book. While writing, authors pull in material from other sources as direct quotations (within the limits of fair use laws), embedding that text in the book itself. This is quite similar to creating an embedded content object in a document, as we've seen in the last three chapters. However, you will have already realized that embedding large amounts of data, especially large graphics and such, will rapidly increase the size of the compound document. There comes a point at which it might be too large to handle, just like an enormously thick book. In addition, maintaining a separate copy of data isn't always what you want in a document—for example, when you want a document that shows current sales data from a central database.
Authors have a similar need. In this book, I refer to the OLE Programmer's Reference as the source for the most up-to-date information on specific interfaces and API functions. Instead of quoting from a specific version of the documentation, I can simply refer to whatever the current version is. So in writing, references allow an author not only to keep book size smaller but also to refer to current information, whatever that might be. The external information is specifically named by the stylistic standards of the citation—title, author, periodical, page, publisher, and so on. The citation is thus a link to the information.
In OLE Documents, linking is the ability to store in a compound document a mere reference to external information. We call this reference a linked content object. In the "Analogy of the Cookie Jar" (Chapters 9 and 17), a linked object is a note or a treasure map inside the cookie jar that tells you where to find the cookies. As we know from Chapter 9, OLE's intelligent treasure map is a moniker. The citation or link from a compound document to the linked object is simply a moniker that names the location of the linked object's persistent data or the process to retrieve it. That moniker, instead of the object's data, is then stored persistently in the compound document, thus reducing the size of the compound document itself. In linking scenarios, the default handler generally provides the appropriate interfaces to what the container sees as the linked object. When asked to activate the linked object, the default handler asks the moniker to bind itself through the same mechanisms we saw in Chapter 9. Once activated, the user can work with the object in its own user interface, the same as for embedded objects.
In this chapter, we'll see the architecture involved in creating and managing linked objects, which includes additional OLE interfaces and more user interface. Much of the user interface concerns the standard Links dialog box (part of the OLE UI Library), which allows a user to update, break, or repair links to external data. This is necessary because currently it is patently difficult to have a compound document automatically track the movements of data to which it maintains links, just as it is difficult to automatically change citations in a book when the title of another book changes. We'll see, however, that there is a promising future for automatic link tracking on the computer.
This chapter looks at linking containers, as we add these capabilities to Patron. Chapter 21 looks at both linking servers and other link sources in the context of Cosmo as well as at support for what is called linking to embeddings, which we'll demonstrate with Patron. A link to an embedded object in another compound document is like a reference to one author's quotation that appears in another author's book. This is necessary in OLE Documents when the embedded object is the only source for the data, just as in writing it is necessary when you have no other source information for that particular quotation. You simply make the best reference you can.