Method for delivering separate design and content in a multimedia publishing system6199082Abstract A multimedia publishing system where the format and content can be separated and uploaded to a server by a publisher. Usually, the format used by publishers remains reasonably constant over time, contrasted with the content which changes on a regular basis. As content changes on a regular basis, the publisher uploads only the new content to the server. When clients or customers access the server's content, the server downloads the format and content to the user's computer. Subsequent downloads of content transmits only the content since the format is cached on the customer's computer after the first download. If the publisher desires to change the format at a subsequent time, the next download of content by the customer downloads both the new layout format and the new content. This publication scheme minimizes the transmission of data in bandwidth limited environments. Claims We claim: Description BACKGROUND OF THE INVENTION
AVI - Advanced Video Imaging.
BBS - Bulletin Board System.
MPML - Multimedia Publishing Markup Language
CF - Component Forms
COS - Caching Object Store
DBM - Database Management System
DLL - Dynamic-link Library
GUID - Globally Unique Identifier
HTML - HyperText Markup Language
ICP - Independent Content Provider
IM - Information Magnet
IP - Information Provider
LAN - Local Area Network
MP - Multimedia Publishing
MPC - Microsoft Network Procedure Call
MPS - Multimedia Publishing System
MFC - Microsoft Foundation Class
MSN - Microsoft Network
OCX - OLE Control
OFS - Object File System
OLE - Object Linking and Embedding
PDA - Personal Digital Assistant
RPC - Remote Procedure Call
RTF - Rich Text Format
SGML - Standard Generalized Markup Language
VBA - Visual Basic for Applications
WAN - Wide Area Network
WWW - World-Wide Web
II. ADVANTAGES OF THE MULTIMEDIA PUBLICATION SYSTEM The present invention can perhaps provide the most benefit by using an on-line network. Therefore, this and the following sections present background information on a preferred on-line publication system which is a foundation upon which the present invention can reside. To enable a new generation of on-line, multimedia applications, an end-to-end system has been invented for developing and using applications and services. The system, called the Multimedia Publishing System (MPS or MP system), preferably uses the Microsoft Network. As an open, turnkey system, the MPS includes components for design, authoring, distribution, viewing, search, personalization, and billing of on-line services and multimedia applications. The MP system allows content providers to offer rich, interactive multimedia applications and services, providing users a compelling and exciting on-line experience. The MP system provides the key to overcoming the previously described hurdles facing the on-line industry. The Microsoft Network removes the primary barriers to on-line service use. These barriers include cost, difficult user interfaces and lack of inertia. Access to The Microsoft Network is provided by Windows 95, the most recent version of the Microsoft Windows operating system thereby making it accessible to millions of customers. The Microsoft Network is designed to make accessing electronic information easy and inexpensive for any user of Windows 95. In the MP system, Independent Content Providers (ICPs), also known as publishers, supply the system with stories, publications, newspapers, sounds, graphics movies and much more. The MP system is designed to take projects (e.g. stories, publications, and so forth) produced by the publishers and make them accessible to millions of users on the Microsoft Network. Thus, the basic components of the MP system are a project designer component, a public distribution site, and a viewer component. These components of the MP system are described in detail below. One unique concept that permeates the MP system is the clean separation of content and design. In this context, content is defined as the actual data that is to be displayed to the user. The design of a project is how that information gets displayed to the user (e.g., its format on the computer screen). An illustrative example would be an electronic newspaper, wherein the content is the text and graphics of the stories, while the design is the layout and style of that data. The design of the electronic newspaper is what makes it look like a newspaper on a computer monitor, whereas the content is the data that makes up the designed screens. In the MP system, the content and the design are stored as separate objects in the public distribution site so that many different pieces of content can be viewed with the same appearance. An object can be defined as a discrete data item or data structure which can be stored in persistent storage or in memory. The object may include computer instructions for manipulating the data. Once a designer using the project designer component at the publisher site has created a particular page layout that is attractive, many pieces of content can be viewed from within that layout because of the separation of content from design in the MP system. The system keeps track of links between a piece of content and its associated page layout, but does not actually format the data in the content with a particular style. As will be discussed in more detail below, the designer creates projects with design and content information for a particular publisher. Continuing the example from above, a project could correspond to an entity that owned a series of newspapers and other media businesses. Within each project, one or more titles would correspond to the actual newspaper. Each title has one or more sections, and can be thought of as similar to the sections in a standard, printed daily newspaper or other periodical such as a magazine. Within each section are pages that define the information that is displayed to a single screen on the customer's computer visual display. When viewing a particular title, the customer will normally look at only one page of information at a time. On each page are controls which contain instructions for gathering, formatting and displaying the linked content onto the page. When a customer looks at information on a page that is provided by a publisher, the customer is really looking at content that has been formatted within pre-defined control regions on the page. One important facet of this invention is the concept of viewing the same content objects in many different ways. As discussed above, content objects are viewed after being formatted by a particular linked control. The control knows how to format a particular piece of content by looking at the style that has been defined for that content by the designer and then comparing that style to a linked style sheet. Because each control on a page can have a different associated style sheet, different controls on the same page can each display the same linked content in varying formats. In one control, the title might be displayed using a 14 point font and bold emphasis, whereas the same piece of content in a different control on the page can be displayed in a 12 point font and italic emphasis. The ability of each control on a page to have its own associated style sheet is a powerful tool for the designer to use to format attractive content on a page. Unlike prior publishing systems, content (such as text or graphics) in the MP system is never reformatted into the marked style. The content is only displayed to the user in the chosen style. Therefore, should the designer choose to change a particular style, only the style sheet property of that style needs to be altered. The next time that the content is displayed using the altered style sheet, the content will be displayed with the properties of the new style. Other advantages and benefits of the MP system are discussed in detail below. To provide more detail on the advantages of the MP system, the following section presents an overview of the Multimedia Publishing system. III. MULTIMEDIA PUBLISHING SYSTEM OVERVIEW This section presents an overview of the configuration and major components of the preferred Multimedia Publication System. Beginning with a description of the important concept of separating design (or title layout) and content, this section continues by discussing the major components and configuration of the MP system. In addition, a description of the container hierarchy is discussed in conjunction with FIGS. 1-4. The objects utilized by the MP System include a project; title; content folder and, optionally, subfolder; section and, optionally, subsection; window; page; control; style sheet; and various content objects (such as stories, images, audio, so forth). These objects will be explained in more detail below in reference to FIGS. 1-7. It is important to realize that these objects need to be stored in a non-volatile computer memory such as a hard disk drive. The natural way of storing related and ordered objects is in a data structure, such as an acyclic graph. The presently preferred way of storing the MP system objects is called a caching object store (COS). In the presently preferred MPS, each title corresponds to a COS. There is least one COS at the publisher workstation and in each MPS server at the publication storage and distribution center (FIG. 2). Each customer workstation also has a COS so that the customer can store and retrieve MP system objects when assembling content into controls on pages. A title may be broadly defined to encompass a publication (e.g., newspaper), service (e.g., stock quotations) or application (e.g., multimedia encyclopedia). When a title is viewed, the viewer opens a title file which represents the title. This title file is a COS file. Typically in the on-line scenario, this would be a skeleton title. A skeleton title is a COS file which contains only a root moniker and no actual objects. A moniker is an object used in the implementation of the COS and contains identification and status information about COS objects. A superCOS is a COS file which contains more than one subordinate COS, known as a subCOS. For example, a superCOS at the customer workstation is used to cache objects which have been remotely retrieved from the host data center. As long as these cached objects are not out of date or flushed, the viewer will be able to quickly provide that object the next time it is requested rather than retrieving it from the data center again. This gives the MP system a tremendous speed advantage over other on-line systems. A top level system flow diagram is presented in conjunction with FIG. 5 and exemplary Viewer screen displays that could be seen during the processes of the system flow diagram are described in conjunction with FIGS. 6 and 7. An example of the rendering process and a query that are used to display the title to a customer are presented in conjunction with FIGS. 8 and 9. Finally, a top level software executable and API/DLL view of the system is presented in conjunction with FIG. 10. A. Separation of Design and Content in the Multimedia Publishing System As discussed above, the MPS architecture maintains a clean separation between design information and the content to which that design will be applied. A publisher's collection of page layouts is in the form of one or more titles. A title is a collection of page layouts, in a particular sequence which relates to the order in which pages will be viewed. The page layouts describe how the client area of a window will appear when a page is rendered. Rendering refers to the creation of a bitmap of a display screen in memory prior to displaying the screen. A complete page layout is created by placing controls on a blank page layout, where each control delineates an area where some piece of content should be displayed. Settings on each control determine the proper place to look for the content to be displayed in that control. The content takes the form of discrete objects, each of which compose one unit of information, e.g., a story or a picture. These content objects are of well-known and public data formats, and may be created using any tool that supports these data formats. Content objects generally do not have formatting information encoded within them. When the publisher has created the title (with its page layouts) and the content objects, the title and content are published together to the public distribution point. Consumers download the title and content objects to their personal computer, where the MPS viewer software uses the page layouts in the title to compose the content in the visually rich form designed by the publisher. B. System Configuration Referring now to FIG. 1, the basic system configuration of the multimedia publishing system (MPS) 100, which is a preferred embodiment of the system 100, will now be described. By convention, the term title is used to describe the overall plan or instructions for assembling the complete on-line MPS application on a customer's computer. Much of the power of the MP system 100 resides in its ability to fully separate design and content, unlike existing on-line and multimedia publishing tools which require a publisher or content provider, such as a first publisher 102, a second publisher 104, or a publisher M 106 to integrate design and content. In the MP system, titles, such as a title A 140, title B 142, or title P 144 can be divided into two parts: the content (148, 152, 156)--the information such as bitmaps, video clips, audio, animation, or stories that make up a title--and the title layout, also termed the design (146, 150, 154)--the overall look and feel of a title. To separate content and design using the MPS rather than placing content directly on a page, a publisher can place the content, such as a set of content objects 112, 114, or 118, in one or more containers of a title and then create sections or subsections having pages with special controls, such as a set of title layout objects 110 or 116, that dynamically find and display the content at runtime. Using this technique a publisher can change a title on an ongoing basis by merely updating the content 112, 114, 116 which has been placed into various folders or containers within the master title. When a page is displayed, it shows the updated content. This is called dynamic title synthesis or dynamic synthesis, and allows content to be continually updated without any need to modify and update the title design consisting of the individual pages, controls and hand-placed content used to display the content. When publishers use dynamic synthesis they are creating titles which contain placeholders that will be filled-in by the changing content. When dynamic synthesis is utilized, a title is used as a template and a pressing is the displayed, filled-in title. Each time the publisher updates the content in a title and makes it available for customers (also known as end-users or client end-users), such as a first customer 160, a second customer 162 or a customer N 164, the publisher is creating a new release of that title. When the customer starts to view that release, a "pressing" is made which contains part or all of the content in the release. A major advantage of this approach is flexibility. Some parts of a title may be created by hand-placing content directly on a page, and other parts may be created using dynamic synthesis. Notice, however, that content hand-placed directly on pages is static--it changes only when the people involved in creating the title update the pages. Returning to the creation of title layouts and content by the publisher, after creation, the title layouts 110, 116 and content 112, 114, 118 are released and stored in a publication storage 120. The storage 120 can be implemented in many forms, such as a network 122, CD-ROM 124, and other means of storage, such as bulletin boards, magnetic media, cable television and so forth. The presently preferred network 122 is the Microsoft Network (MSN), which can be accessed, for example, by Microsoft Windows 95. Of course, the MPS is designed to be portable so that it can be used on any on-line network including but not limited to, Internet, America On-Line, Compuserve and Prodigy. In the presently preferred embodiment of the storage 122 as the MSN, many customers will use a MSN Explorer tool to acquire and activate MPS applications. The MSN Explorer is the integrated navigation tool within Windows 95 that is also used to browse the MSN hierarchy. Sophisticated customers may use other more advanced MPS features, such as search, scheduling, and automatic delivery, assuming these features have been activated by the publisher. Besides browsing via the Explorer or scheduling automatic home delivery, there are several additional ways customers can obtain MPS applications. For example, an individual application may be distributed via floppy disk or CD-ROM 124, it may be distributed through E-mail or bulletin boards, or the application may be directly accessible via a link in other applications (such as the Microsoft Network yellow pages system). In each of these situations, the MP system 100 acquires an application for the customer. C. System Components Referring now to FIG. 2, the preferred basic components of the MP system 100 will now be described. The system 100 includes a set of tools for designing, developing and viewing multimedia on-line applications. A publisher, such as the publisher 102, utilizes a publisher workstation (also known as a computer or machine) 182 and a Designer software environment 194 to create and publish the title layouts 110 and content 112. In the system 100, a publisher could possibly just create content and use the title layouts of another publisher. The title layouts and/or content are preferably stored in a network 122 that includes a high-performance server for hosting on-line applications. The preferred network 122 will be further described in conjunction with FIG. 3. A customer, such as customer 162, utilizes a customer workstation 182 and a runtime Viewer software component 202 to find and activate MPS titles, stored on the network 122, on a visual display at a workstation 182. The Designer 194 is an extensible design and development environment that includes several preferred software components. These include a project editor 184 to manage tiles, containers, and objects; a page editor 186 to create and layout pages; a style sheet editor 187 to edit style sheets; a search object editor 189 to create search objects; a word processor, such as a MPS Document Editor 188, for creating content optimized for the MP system 100; and optional third-party tools, such as a sound editor 190, an image editor 192, and another media object editor 193 to create and modify sound, image, video, animation and other content objects. For authoring textual content, the preferred document editor is an enhanced version of the Microsoft Words.RTM.6.0 word processing program for creating tagged, hypertext documents. Together, these programs form the Designer Component 194. The project editor 184 is used to invoke a style sheet editor 187 that is used to create and edit style sheets. The style sheet editor 187, and portions of the project editor 184 and page editor 186 will be described in detail in subsequent sections of this discussion. The MPS Designer 194 is a page or forms-based development system similar to Visual Basic. The development environment is graphical and easy to use. Controls, which represent the components of a MPS application that will appear on-screen, are laid out within MPS pages. MPS pages and controls are preferably based on Object Linking and Embedding 198 (in FIG. 2) (OLE), Microsoft's component software technology. OLE, which presently is at version 2, is further described in Inside OLE 2 and OLE 2, Programmer's Reference, Volumes 1 and 2, all of which are published by Microsoft Press. In addition, the System Overview chapter of Class Library User's Guide for the MFC Class Library, Microsoft corp., 1993, provides further relevant information. However, other compound document architectures such as OpenDoc could be used as well. A major feature of OLE is interoperability, the basis for integration between applications. This integration brings with it the need to have multiple applications write information to the same file on the underlying file system. OLE defines a model called OLE Structured Storage for treating a single file system entity as a structured collection of two types of objects; storages and streams. These objects act like directories and files, respectively. The OLE Structured Storage model generally implements these objects; applications rarely, if ever, need to implement them. These objects, like all others in OLE, implement interfaces: IStream for stream objects, IStorage for storage objects. A stream object is the conceptual equivalent of a single disk file. Streams are the basic file system component in which data lives; each stream has access rights and a single seek pointer. Through its IStream interface, a stream can be told to read, write, seek, and perform a few other operations on its underlying data. Streams are named by using a text string; they can contain any internal structure because they are simply a flat stream of bytes. In addition, the functions in the IStream interface map nearly one-to-one with standard file-handle-based functions such as those in the ANSI C/C++ run-time library. A storage object is the conceptual equivalent of a directory. Each storage, like a directory, can contain any number of substorages (subdirectories) and any number of streams (files). Furthermore, each storage has its own access rights. The IStorage interface describes the capabilities of a storage object, such as enumerate elements (dir), move, copy, rename, create, and destroy. A storage object itself cannot store application-defined data except that it implicitly stores the names of the elements (storages and streams) contained within it. The OLE Structured Storage technology solves problems associated with previous flat file systems through the extra level of indirection of a file system within a file. With OLE, a particular application can create a structured hierarchy where the root file itself has many substorages. Each substorage can have substorages within it, and so on. This structure solves the problem of expanding information in one of the objects: The object itself expands the streams in its control, and the implementation of storage determines where to store all the information in the stream. The MP system 100 includes a number of pre-packaged controls such as navigation controls, rich-text controls, multimedia controls, and other special controls specifically designed to support the creation of MPS applications. Because the MPS is based on OLE, third parties can also design their own controls for use within the MPS (using the Microsoft OLE Control Development Kit that is bundled with Microsoft Visual C++ 2.0). In this way, the MPS development environment is fully extensible so that customers can add new capabilities to their MPS applications by purchasing additional controls from third parties or by creating their own controls. The MPS development environment also includes a Visual Basic for Applications (VBA) scripting and debugging system. While content is displayed within controls that have been laid out on MPS pages in the MPS Designer 194, content can be authored in any number of existing Microsoft and third-party tools. One such tool for authoring hypertext is the MPS Document Editor 188 that supports special MPS features for creating and tagging MPS text. Other existing tools for creating bitmaps, complex drawings, and other multimedia content can be used to create the content displayed within any particular OLE Control. In addition, most existing OLE Controls (.ocx executable programs) will work in the MPS environment although they may not be optimized for on-line applications. For example, a standard AVI OLE Control could be placed in an MPS application. The controls that are part of the MP system 100 are optimized for low bandwidth on-line delivery of data. However, the use of high bandwidth data delivery is within the scope of the present invention. The MPS 100 is designed to operate with information that can change from minute to minute, daily, or monthly. So while the MPS can be used for creating static titles that are hand-crafted and cannot be easily updated on an ongoing basis, the main focus of the MP system 100 is to provide an efficient, cost-effective mechanism to manage the creation and management of dynamic, continually changing on-line applications. At the same time, as an open development environment, many of the tools commonly used for creating static multimedia content can easily be incorporated into the MP system 100. When activated by the customer, the Viewer 202 examines the components of a selected title to see if any of the information required to display the pressed title needs to be acquired. It then acquires this information from publication storage 120 or local storage at customer workstation 182 and organizes it so that it can be displayed to the customer 162. Thus a pressed title captures the set of information that is displayed to the customer at a given point in time. In other words, some titles might produce a new pressing every day, or more frequently, as the content changes. On the other hand, other titles may be static; when a static title is activated there is no need to do another pressing, since the content has not changed. While pressing a static title may seem unnecessary, the process of organizing and displaying the pressing can take into account customer preferences and display device characteristics. For example, suppose a customer activates a static title on a laptop when using the laptop screen and then later activates the same title when the computer is attached to a larger display. The second activation will result in another pressing to take into account the much larger screen area, if the publisher has enabled such an option. When the title is activated, the MPS Viewer 202 determines if the title is out of date; acquires any needed. information; and then, if necessary, creates and possibly personalizes the pressing. The MPS Viewer 202 enables customers to perform the following actions within the limits defined by content providers: select and personalize the information a title acquires, modify the overall structural properties of titles, personalize the look and feel of titles, manage and archive the content customers acquire, and view billing and pricing information. The requirement for the preferred publisher workstation 180 is a Windows 95 workstation with the minimum hardware configuration necessary to run the MSN sysop tools and to store and display the titles under development. The preferred Windows 95 workstation has, at a minimum, an Intel 486 processor running at 33 MHz or better with eight Megabytes of memory. A 9600 baud or faster modem is required to run the MSN sysop tools. For multimedia titles, this includes a MPC2 compliant (multimedia configured) workstation. The MPS Viewer 202 should be installed on the customer workstation 182 before an MPS title is activated. The presently preferred customer workstation is capable of running Windows 95. To make this installation easy, the Viewer 202 is automatically installed onto the customer workstation 182 the first time the customer connects to MSN and the MP system 100 is enabled. MPS titles may include resources such as fonts, Dynamic Link Libraries (DLLs), and OLE controls that are placed into the resource container or folder of MPS titles. Before customers can view such titles, these resources are installed on their workstation 182. D. Network Storage Referring to FIG. 3, an exemplary network storage subsystem 122 will be described. FIG. 3 is a high level diagram illustrating the basic components of an on-line network 122 in accordance with one embodiment of the invention. Multiple publisher workstations 102, 104, 106 and customer workstations 160, 164 are connected to a host data center 242 by a wide area network (WAN) 240. The publisher workstations preferably have high speed connections to the WAN 240. The wide area network 240 includes WAN lines 244 which are provided by one or more telecommunications providers, and which allow end users (i.e., publishers and customers) over a wide geographic area to access the host data center 242 via modem. The WAN lines 244 preferably include both X.25 lines and ISDN (Integrated Service Digital Network) lines. The host data center 242 comprises a plurality of application servers 246 connected to a high speed local area network (LAN) 248 (which may include multiple LANs). Each application server 246 has a unique server ID. As shown in FIG. 3, three of the servers 246 are MP System servers (246a, 246b and 246c). Also connected to the LAN 248 are multiple Gateway computers 250 also referred to as Gateways, which link incoming calls from end users to the application servers 246. It is envisioned that the host data center 242 may advantageously have on the order of one hundred Gateways 250, and between several hundred to several thousand application servers 246. A host data center of this type will be able to handle tens of thousands of simultaneous user logon sessions. As described below, the server side of each on-line service is preferably implemented using one of the following: (1) a single application server 246, (2) a set of "replicated" application servers (i.e., application servers which run the same service application or applications) that provide access to replicated (and locally-stored) copies of service "content" data (i.e., data provided to end user's of the service), or (3) a set of replicated application servers that provide access to server-specific (non-replicated) service content data. The host data center 104 also includes multiple Arbiter computers 252 that monitor, record and process certain types of transactions to ensure consistency among replicated application servers. The host data center 104 also includes one or more custom Gateway computers 254 which link the host data center 104 to one or more external service providers 256, such as a credit card service that validates and executes credit card transactions. The host data center 104 also includes a number of administrative servers 258. The administrative servers 258 perform administrative functions such as accounting, billing, network management, backup, system security, performance analysis, and server-to-service allocation. To route user service requests to the appropriate servers 246, the Gateways 250 must have some way of determining the unique IDs of the servers that are currently handling the requested services. This is accomplished by means of a service map (not shown), which contains information about every service and server 246 in the host data center 242. The service map is preferably generated by a service map dispatcher 260, which may be implemented on a single computer. In addition to generating a service map, the service map dispatcher 260 maintains a central repository of information referred to as the "global registry" 262. The global registry 262 contains various information about the present configuration of the host data center 242. For example, for each service group, the global registry 262 indicates the IDs of the servers 246 of a service group, and the identity of the Arbiter computer 252 (if any) which is assigned to the service group. Further disclosure of the preferred network 122 is provided in a copending application also assigned to the assignee of the present application, Microsoft Corporation, entitled "Architecture for LAN-Based On-Line Services Network", U.S. Ser. No. 08/503,307, filed on Jun. 7, 1995. E. Container Hierarchy Referring now to FIG. 4, the high level hierarchy of containers for a plurality of publishers using the MP system 100 will be described. In the presently preferred embodiment, the MP system 100 utilizes a specific directory structure with the MSN directory tree. This structure is rooted at a specific folder (specified via the MSN global registry 262) known as a container of publishers 280. Every publisher 102, 104, 106 will have at least one container or folder called a project. For example, the publisher 102 has a folder called Project A 282, the publisher 104 has two folders called Project B 284 and Project C 286, and the publisher 106 has two folders called Project N-1 288 and Project N 290. Content folders and/or titles are dropped into the folder of the publisher. Allowing for multiple projects satisfies the needs of a large publisher. For instance, a project could be assigned to one magazine (e.g., gardening) and another project could be assigned to another magazine (e.g., motorcycling). Thus, each month's issue could be archived as a title according to volume and number in its respective project. As an example of how projects could be configured, Project A 282 only has a content folder 292; Project B has a title folder 294, and two content folders 296 and 298, along with a link to the content folder 292 of publisher A 102; Project C has two title folders 300 and 302 that could share a content folder 304; Project N-1 has a title folder 306 and a content folder 308; and Project N has a title folder 310 and shares content folder 308 with Project N-1. Publisher 102, for example, could be a provider of raw statistics in content folder 292 but does not want to generate title layouts. The publisher 102 may have an agreement with the publisher 104 for the publisher 104 to allow access and use of the content in the content folder 292. The publisher 106 has two projects 288 and 290 that share the content folder 308, for example, due to the common subject matter of titles in title folders 306 and 310. As illustrated in FIG. 4, a project, such as the project 286, may contain multiple titles folders. F. Operational Description Including Top Level Flow Diagram Referring now to FIG. 5, a top level flow diagram of the processes performed using the MP system 100 will now be described. The flow diagram and this description introduce the process 320 a publisher 102 or information content provider (ICP) would use to design and distribute MPS titles. As previously stated, a title is a publication, application, or service created using the MP system 100. For example, the publication may be a monthly magazine, wherein each issue of the magazine is a new title. A title consolidates the set of instructions for assembling the information that is displayed to the customer 160. Customers see titles as icons on the Microsoft Network, on CD-ROMs, or in a file system. By double-clicking (activating) on the title, name or icon, the customer can interact with the title. 1. People and Tasks involved in Title Creation The MP system 100 is designed to support large teams creating complex on-line applications, as well as small teams creating individual works (and anywhere in between). This section, however, discusses only the more complex, high-end operations. In simpler scenarios, one person could perform more than one of the roles described below, and the amount of materials (stories, artwork, advertisements, and so on) would be more limited than the materials described here. The process of creating and publishing a MPS title can be broken into a title-design phase and a release-creation phase. The process is set up so that all of the content and layout that is common across releases can be performed once in the preparatory design phase, and then left alone. This allows for a smaller team and faster turnaround in producing each release. a. Title Design The process of creating a new title begins with the editor. Assisted by business development staff, the editor decides on a target customer base, and on a concept for the title that will appeal to that base. This design team then develops that concept into a proposed organization for the contents of the title. Before content can be put in place, a framework for the title must be created. This involves: .circle-solid. Creating a section hierarchy within the title. .circle-solid. Creating content folders to store stories, advertisements, and other pieces of content. .circle-solid. Creating search objects in each section of the title that draw content from the appropriate content folders using specified criteria. In some organizations, this work will be done by the editorial staff. In others, it may be done by the production staff. Once the basic framework is in place, the art department can create artwork to fill in the title's common elements. This includes: .circle-solid. A style sheet describing font usage and text layout. .circle-solid. Page layouts for sections that dynamically gather their content. .circle-solid. Page layouts for sections that are always the same (cover, title pages, mastheads, and so on) .circle-solid. Logos. Optionally, organizations may want to include developers in the title design process. For example, the particular application being designed may benefit from the use of custom designed OLE Controls. These controls could be purchased, or developed in-house using the Microsoft Visual C++ development system. Additionally, the advanced features of the Blackbird system, including accessing the API or scripting controls to respond to events or automatically perform actions at runtime would require some development work, either in the high level scripting language (VBA), or in a lower-level language such as C++. b. Authoring and Title Release Once the framework is created, the staff can now turn their attention to creating individual releases. All of the work done in the conceptual phase above is potentially re-usable for every release. In fact, for a title with little need for detailed artwork, the rest of this process could merely be a matter of dropping edited content (including advertisements) into content folders. For dynamic titles, most (and potentially all) of the work is done within the Content Authoring environment. For static titles, it could all be done within the Title Design environment. In practice, most releases will involve some work in both of these environments. i) Writers Provide Tagged Content Content authors--including editors, writers, reporters, and forum managers--generate content, including structured stories, using the content authoring environment. Writers compose the textual content that appears in a title (or a release of a title). They hand their materials off to the editorial staff. The editorial staff is in charge of the overall content of the title. For multimedia titles, this role is very similar to the director of a motion picture or television program. The content authoring environment supports a variety of tools, such as, for example, a MPS document editor. The MP system 100 also supplies tools to specify and manage links and to specify story properties. Third-party tools may also be added to the content authoring environment. From a content author's perspective, creating structured stories can be as simple as typing them in the MPS document editor and applying certain styles. More sophisticated content can be created though a variety of means, such as including links to graphics or placing special properties on a story. For content providers that do not want to expend much effort creating tagged content, the MP system 100 includes MPS document editor templates that handle most of the tagging for the author. ii) Editorial Staff Chooses Content Once the editorial staff has chosen the stories they wish to include in a release and are satisfied with the content of those stories, they pass them on to the art department to select and insert appropriate artwork, and to the production staff to place in content folders. iii) Art Department Supplies Specific Art The artistic staff is responsible for designing the more graphical aspects of the title. In the early conceptual phase, graphic artists work with the editor to design a distinctive look and layout. This includes font styles, colors, titles, logos, and page layout templates. The term "art department" is used in the broadest sense here. In the multimedia world, the role of an art department goes beyond traditional print-based artwork. The art department in many cases inserts the artwork into the stories and tags that artwork so that it will presented appropriately (placed inline in the story text, as a wrap, or as a pop-up). They then pass the stories on to the production staff to be placed in content folders. In the case of static titles, the art department designs new pages and gives them to the production staff to be placed in the title framework. iv) Advertising Department Supplies Copy The advertising sales staff sells advertising space in each release. The advertising sales department collects copy from advertisers who have bought space in the release, and delivers the copy to the production staff to be placed in content folders. v) Production Department Does "Paste-up", Proofing and Release The production staff does the fundamental tasks, such as paste-up, necessary to put a title or release together. Once the production staff has everything that goes into the release, they "paste up" the release by placing everything in its appropriate place and performing a "test-pressing" to make sure that nothing is missing. The editors, art staff, production staff, and advertising staff review the test-pressing to make sure that everything looks and works correctly. Once everyone is satisfied, the production staff places everything on the publisher's server and releases it to be copied to additional servers at the Microsoft Network data center. 2. Top Level Flow The process 320 begins at a start state 322 and continues at a state 324 wherein the publisher 102 uses the MPS project editor 184 (FIG. 2) to create a project on their workstation 180. A project, such as project C 286 (FIG. 4) contains all the information needed to build and distribute one or more titles and any associated content. Moving to state 326, within the project, the publisher 102 creates titles and content folders, such as title 300 and content folder 302 (FIG. 4). A title consists of nested sections that contain MPS objects such as pages or search objects. Folders typically contain MPS content objects such as stories or pictures. To make the process of managing titles, folders, and MPS objects easy to understand and use, the preferred MPS project editor 184 (FIG. 2) looks and works like the Windows 95 Explorer. Proceeding to state 328, the publisher 102 uses the MPS project editor 184, page editor 186, style sheet editor 187, and search object editor 189 (FIG. 2) to create the MPS layout objects such as pages, styles, and search objects. The page editor 186 is also used to place controls (each control is a program responsible for handling a displayable region) on a page. Moving to state 330, the publisher 102 creates content objects using the MPS Document Editor 188, or the publisher can use third-party tools, such as the sound editor 190 or the image editor 192, that produce formats that the MP system 100 can interpret. The authoring and processing of content objects is further disclosed in a copending application also assigned to Microsoft Corporation, entitled "Structured Documents in a Publishing System", U.S. Ser. No. 08/503,307, filed concurrently herewith. The creation of content objects could also be done prior to any of states 324, 326, or 328. After the content objects are created at state 330, the publisher invokes the page editor 186. If not previously done at state 328, the publisher lays out each page with at least one control. Selecting a control on a page lets the publisher bring up a context menu, of which one item is a Properties selection. Choosing the Properties selection brings up a control's property sheet. Among the property sheet pages are a story page and a picture page. The story page allows the publisher to choose a story content object that is to be displayed in a story control. The publisher could enter a path name to the desired content object. Alternatively, pressing a ". . ." button brings up a Content Browser dialog which allows for browsing within the project to find a desired story content object. The picture page is used for choosing a picture object to display in a control. The publisher could enter a path name to the desired content object. Alternatively, a Content Browser dialog allows the publisher to choose a picture content object from within the project. Other types of content objects are associated with a layout object in a similar way. Further descriptions of the property sheet pages are provided below in conjunction with a discussion of controls. Proceeding to state 332, the publisher 102 releases the project. In the presently preferred embodiment, releasing a project makes the titles, stories, and other MPS objects available on the Microsoft Network 122. The MP system 100 automatically connects to the network 122 and makes the titles in the project available to the customers 160, 162, and 164 (FIG. 1). Alternatively, the MP system 100 can release the title to CD-ROM 124 or other storage/communications media. Continuing at state 334, the customer 160 uses the MPS Viewer 202 (FIG. 2) to read and page through (also termed navigation in an electronic publication) the released titles. As parts of the title are accessed, they are cached on the customer's computer 182 for fast access. The viewer 202 organizes and composes the objects it has collected and displays them to the customer 160. Over time, the publisher 102 can update the project and the MP System automatically tracks the changes. Decision state 336 determines if the publisher desires to update the project. If the publisher does not wish to update the project, process 320 completes at end state 338. However, if decision state 336 is true, that is, the publisher desires to update the project, the process 320 moves to a decision state 340 to determine if the publisher 102 desires to modify the layout in the project. If so, the process 320 moves to state 342 wherein the publisher modifies one or more existing layout objects or adds one or more new layout objects. If the decision state 340 evaluates to be false, or at the completion of state 342, the process 320 moves to state 344 wherein the publisher modifies or adds one or more content objects. At the completion of state 344, process 320 proceeds to state 332 wherein the project is released again. Releasing the updated project ensures that the proper set of layout and content objects are made available to the customer 160 (FIGS. 1 and 2). G. Exemplary Screen Display of Title Referring now to FIG. 6, an exemplary screen display 360 of a page of a title as displayed by the Viewer 202 on the visual display at the customer workstation 182 (FIG. 2) will now be described. The screen display 360 corresponds to a World News section of a MSNLive title using a page layout which has been named NewsFront by the designer. A tabbed horizontal bar 362 near the top of the screen 360 is handled by a caption button control and shows the major sections of the title. By selecting a section name (by use of a pointer device like a mouse, not shown, but which is a part of or connected to the workstation 182), the customer 102 can navigate directly, through a link, to the selected section. Below the bar 362 of screen 360 are two headlines 370 and 372 which are the result of an outline control that can be used as links to corresponding stories on another screen of the title. Block 373 in this example contains an advertisement resulting from a picture control. Block 374 contains a graphic and text resulting from a picture button control that provides a link to a weather screen. Areas 380 and 384 display headlines for corresponding abstracts 382 and 386, respectively, and are the result of an outline control. By selecting the headline 380 or 384, the customer can navigate to the body of the corresponding story on another page of the title. Areas 390 and 392 display picture objects corresponding to the headlines 380 and 384, respectively, and are the result of picture controls. The objects and placement of the objects on the displayed page 360 are determined by the publisher 102. Of course, other objects or placements of objects could be utilized by the publisher 102. H. Exemplary Screen Display of Project Editor Window Referring now to FIG. 7, an exemplary screen display 400 of the parts of the content and layout for the example title displayed in FIG. 6 will be described. The Project Editor window 400 is the main interface for the Designer 194 (FIG. 2). The window 400 is intended to closely mimic the Microsoft Windows 95 Explorer. Using this window 400, the publisher can open, edit and save a project, as well as release the contents of that project to the MSN Data Center 242 (FIG. 3). An approximately left one-third of screen 400 is a display area 402, also known as a left pane, that shows the hierarchy of containers of one project for a publisher and allows the user to navigate through it. The left pane shows only containers (folders, titles, and sections). An approximately right two-thirds of the window 400 is a right pane 404 that shows the contents of a container selected in the area 402 by the user of the project editor 184 (FIG. 2). Referring to the left pane 402 of the window 400, the top level of the hierarchy of containers is the project "MSNLive" 406. Just below the project is the title "MSNLive" 408, which in this example has the same name as the project 406. In another example, the project could have a plurality of titles, such as a January issue of a magazine "X", a February issue of magazine "X", and so forth. Below the title in the example hierarchy are two sections: "News" 410 and "Sports" 414. Also at this level in the hierarchy is a content folder 418 labelled "Graphics", which holds the picture objects used by the project 406. Below the sections 410 and 414 is a set of subsections 412 for the "News" section 410 and a set of subsections 416 for the "Sports" section 414. The "News" section container 410 has been selected by the user, which is evidenced by the highlighting of the section label "News" and the opened section icon to the immediate left of the "News" label. Referring to the right pane 404, the layout objects and content objects directly contained within the selected container in the left pane 402 are shown, e.g., the objects of the "News" section container are displayed in this example. The left pane 404 uses standard Explorer views, as well as a special view built for the window 400, which sorts according to a user-defined order and allows the user to change the order by dragging and dropping each objects' icon. The objects are preferably grouped by type of object, such as, for example, subsection objects 412, page layouts 420 and content objects 422. The order of the pages and content objects is significant. The title maintains a sequence ordering of the sections, pages, and search objects, as this is important in determining how the title is displayed. Within a section, the pages have a sequence that determines the order in which they are used to press content and the order in which they are displayed when the user browses sequentially. In a static section, pages are displayed in the order shown in the project editor window 400. A dynamic section uses the dynamic story control (FIG. 8) to display stories within a section. The stories are sorted according to rules specified on the section's property sheet and then are concatenated or linked together. The stories are then filled into the dynamic story controls on each page in the section, in the order in which the pages are arranged in the section. If there are more stories than there are pages, the last page is re-used repeatedly until all content has been pressed. For instance, in FIG. 7, the Backpage in pages 420 would be reused. Toolbar buttons and corresponding menu commands allow the publisher to quickly add new objects to the titles and folders within the project 406. Clicking a button will add a corresponding object to the container selected in the left pane 402. Only those objects that are allowed to be in the selected container have their corresponding toolbar buttons and menu items enabled. I. Example of Rendering Process Referring now to FIG. 8, the interaction of page layouts, having controls, and objects at the Viewer 202 (FIG. 2) of the customer's workstation 182 to render pages will now be described. The Viewer 202 supports the display of information through windows. The placement, organization, and number of windows is under the control of the publisher 102. Viewer windows are Windows 95 frame windows. These windows are completely under the control of the designer. The designer controls the Viewer 202 by creating a title. The title sets the size and standard elements (title bar, Min/Max buttons, caption, border, menu bar) of the various windows displayed by the Viewer 202. The entire client area of a viewer window is used to display a series of pages. Each page contains a set of controls that are used to display content, to navigate through the title, and to gather information from the customer. In response to customers actions or other events, the page that is displayed may change during the course of running the title. This behavior is determined by the publisher 102. A title may have more than one window visible at any given time, and popup windows may be modal or modeless. Only one title may be displayed within a Viewer window at any given time. FIG. 8 presents a diagram of a front page section 430 and a business section 432 for a title, such as a newspaper. 1. The Front Page Section The front page section 430 contains a page 434 which has a picture control 436, and a set of static story controls: a first story control 438, a second story control 440, and a third story control 442. Each static story control or picture control is linked at publication time to just one object. Each of the controls on the page 434 references a style sheet 443 to provide formatting instructions on how the content is to be displayed. As shown in FIG. 8, a picture object 460 is linked to the picture control 436, so that upon rendering, the picture object 460 is displayed on the page 434 at a position determined by the control 436. Similarly, a story object 462 is linked to the static story control 438 and rendered into the position of the control 438 on the page 434. Note that since the control 438 is a static story control, any area not used by the story object 462 in the area identified by the control will be blank. As shown, a story object 464 is linked to the story control 44080 that it is rendered in the area identified by the static story is control 440 on the page 434. In this example, for instance, only the first paragraph of the story object 464 will be rendered on the page 434 due to the size of the control 440 (as selected by the designer). In this manner, the designer can choose to only display a portion of a linked story within a static story control by adjusting or sizing the control to only hold one paragraph, or other desired portion, of the story content. Normally, a static story control will allow scrolling of a story so that ultimately the entire story will be displayed. Finally, a story object 466 is linked to the story control 442 so that it is rendered in the area identified by the static story control 442 on page 434. In this example, the entire story object 466 is rendered onto page 434. It is important to note that each of these story objects makes reference to the style sheet 443 before being rendered on the page 434. When story objects are authored, they are given formatting tags that represent specific styles. As the story objects are rendered, they reference the style sheet that is linked to the appropriate control to retrieve formatting information. This formatting information includes properties of the paragraphs, fonts and embedded objects in the story that format the content as it was originally designed. Due to the separation of design and content in the MP system, the story objects themselves only have formatting tags, but do not contain a description of the particular format that corresponds to each tag. The descriptions of those tags is found in the style sheet that is linked to the control into which the story object becomes rendered. This process will be explained in more detail below with respect to FIGS. 9-15. 2. The Business Section As also shown in FIG. 8, the business section 432 contains a first page 444 and a second page 446. The page 444 has a single static story control 448, a single picture control 450, and a first dynamic story control 452. The second page 446 has two dynamic story controls, 454 and 456. In addition, a style sheet X 457 and a style sheet Y 459 are referenced by the different controls on pages 444 and 446. The pages in the business section 432 differ from the page 434 in the front page section 430 because they rely on a search object 468 to retrieve particular stories. On the page 434, the static controls were each linked to a particular story which was then displayed upon rendering. The search object 468 is affiliated with the dynamic story controls in the section 432. As shown in this example, the static story control 448 and the picture control 450 on the page 444 reference or link to the story object 464 and the picture object 460, respectively, and display these objects as shown on the rendered page 444. The story object 464 is thereby shared between different sections, pages and controls in the title. The entire story object 464 is displayed on the page 444, whereas only the first paragraph was displayed on the page 434. By using a similar process, a designer can choose to display just the first paragraph of a story on the first page of a title, but include the entire story on another page within the same title. As shown in FIG. 8, the picture object 460 is also shared between the control 436 and the control 450. This sharing of content between separate sections and pages is an important feature of the MP system 100. 3. Dynamic Story Controls The dynamic story control 452 uses the results of a query performed by the title to retrieve stories matching search criteria set by the publisher (as defined by the search object 468). The search object 468 locates story objects having specific properties. In the example of FIG. 8, the search object 468 returned many story objects 470, 472 and 474 corresponding to story objects 1 through N, respectively (where N.times.4 in this example). All of the retrieved story objects are concatenated together by the dynamic story controls and poured into the appropriate regions on the pages. The order that the stories become rendered into the control regions starts with the first dynamic story control on the page in the section and continues to other dynamic story controls contained within the section. If enough pages to display all the located stories are not defined in the section, the last page used is repeated until all stories are rendered. Thus, the first located story 470 is poured into the area defined by the dynamic story control 452. Since it does not completely fit in that area, the located story 470 continues across the page boundary onto page 446 into the area defined by the dynamic story control 454. The located story object 472 then begins after the located story object 1 470 ends. The next located story object (located story object 3) begins after the story object. 472 ends, continuing into the next control 456 on page 446, as shown in this example. The last located story object 474 retrieved by the search object 468 in this example is then rendered into the dynamic story control 456 within page 446. As explained above, the dynamic story controls in the section 432 use the search object 468 to display the results of queries made for specific information. For example, the search object 468 may return content that contains the word "Microsoft". Each of the stories found by the search object 468 will be displayed in the areas defined by the dynamic story controls in the format designated by the style sheet 457 or the style sheet 459. For example, if the dynamic story control 454 is linked to the style sheet 457, then all of the stories displayed by the dynamic story control 454 will appear in the format designated by the style sheet 457. However, the stories rendered by the dynamic story control 456, when this story control is linked to a different style sheet (for example, the style sheet 459), would appear differently than the formatted display corresponding to the dynamic story control 454. In this example, if the controls 454 and 456 use different style sheets, the located story 3 would be displayed using two formats when the transition from the area defined by the control 454 to the control 456 was made. J. Style Sheet Overview Style sheets and the style objects they collect are created by the designer (i.e., the person at the publisher workstation 180 shown in FIG. 2) using the Project Editor and the Style Sheet Editor. Once the style sheet has been created, it is stored in the cached object store (COS) along with the other objects in the project as described above in reference to FIG. 2. The style sheet objects support OLE serialization and are therefore based on the Microsoft Foundation Class (MFC) Cobject class. These class definitions are publicly available from the assignee. As described at the beginning of the detailed description section, a different style sheet may be linked to each control region on a page. However, in all likelihood, style sheets will be shared among more than one control. As is known in the present software technology, a globally unique identifier (GUID) can be used in OLE object-oriented environments to identify an object with a unique string of characters. Normally, unique GUIDs are produced by concatenating the time, date and network card serial number of the computer at the time that the object is created. By using this method, it is virtually impossible for two objects to receive the same GUID. In the MP system 100, each control keeps a record of a GUID associated with its linked style sheet. This is how a particular control can reference its linked style sheet. More than one control can refer to the same GUID, and therefore share style sheets. When a control needs access to its associated style sheet, the control requests the style sheet from the title. If the style sheet has not already been loaded into volatile memory, the title object handles loading it from the COS. K. Customer Query Referring now to FIG. 9, a query path from a "Find" dialog through title searches to the content database at the publication storage 120 will be described. The query components for both publishers 102 and end-user customers 160 are defined as follows: a MPS Document Editor Summary Information dialog--for tagging content with keywords to aid in retrieval; a Search Object Editor--for title designers to create and modify search objects (also known as information magnets); and a Find dialog 510--a customer interface for ad-hoc and saved searches. Content, such as stories 502, 504 and 506, is tagged using the MPS Document Editor's Summary Information dialog and is placed in the MPS content database in the publication storage 120. Search objects gather stories which match a particular criteria (as defined in the Search Object Editor) and "flow" them into the appointed sections of a title in the Viewer 202 (FIG. 2). The Search Object Editor is the query tool which designers use to retrieve and locate relevant stories within the title. The customer 160 uses the Find Dialog 510 within the MPS Viewer 202 to issue one or more queries 512 against all the stories in a particular title (i.e., those stories the title has retrieved using one or more search objects). The queries 512 issued by the customer 160 in the Find dialog 510 are joined with the criteria of the title's searches due to the search object(s) and then the aggregate is queried against the content database in the publication storage 120. Result GUIDs 514 (representative of stories matching the queries and search objects) are transmitted back to the customer and appear in a results pane 516 of the Find dialog 510. By combining the query 512 with the search object queries restricts the results to be within the title structure rather than from any arbitrary source in the content database. L. API/DLL View of System Referring now to FIG. 10, the major software components or modules used by the presently preferred implementation of the MP system 100 will be described. The modules are located at the publisher location 102 (also shown in FIGS. 1 and 2), at the network storage location 122 and at the customer location 160. The modules at the publisher location 102 include a publisher executable 530, a set of publisher DLLs 532, a set of publisher OLE custom controls 534, a publisher COS 544 with a client object broker service and client publisher interface 546, OLE 198 and MFC 562. The modules at the customer location 160 include a viewer executable 538, the set of common publisher DLLs 532, the set of common publisher OLE custom controls 534, a viewer COS 548 with a client object broker service 550, OLE 198 and MFC 562. The modules at the storage location 122 include a server executable 536, and a server superCOS 540 with a server object broker service and server publisher interface 542. The publisher executable 530 (also known as BBDESIGN.EXE) is an application which provides a mechanism for generating a design-time view of a project. It is utilized in the creation of objects within a project, and for establishing the relationships between the objects of a project. The set of publisher DLLs 532 includes a forms DLL (FORMS3.DLL) that provides the implementation of the OLE Control Container class and supplies the data for the page object in a project. Also included is a view DLL (VIEWDLL.DLL) that provides a set of MPS Object definitions and the viewer engine for synthesizing the run-time view of a title. The MPS Objects include: CProject, CTitle, CSection, CFolder, CContentFolder, CRootContentFolder, CProxyTable, CContent, CFrame, CBForm, CVForm, CStyleSheet, and CMagnet. The set of publisher OLE custom controls 534 (also known as BBCTL.OCX) is a DLL which provides the code for implementing instances of the OLE custom controls which are standard for the MP system 100. The viewer executable 538 (also known as BBVIEW.EXE) is an application which provides a mechanism for initiating the run-time view of a title. It uses the publisher OLE custom controls 534 and the publisher DLLs 532, especially the viewer engine for synthesizing the run-time view of a title. Each of the publisher 102, customer 160 and network storage 122 locations has a COS implemented by using a DLL (COS.DLL). The COS DLL provides a persistent storage mechanism for objects used by the MP system 100. The COS DLL uses OLE Storage technology to store sets of objects in a compound document file. Each object placed into a COS is given a unique identity, referred to as a GUID. Each object identified by a GUID can be located independent of a path name in a file system. The server executable 536 (also known as MSNSERVER.EXE) is an application which provides a mechanism for managing the network server, which includes the COS. In addition to the COS DLL, the server has a DLL for COS access and object binding (OBSV.DLL), a MPS server service (BBOBSVC.DLL) and a memory management service (DFARBSV.DLL). Each of the publisher 102, customer 160 and network storage 122 locations has an object broker service DLL (OBJBRK.DLL). The object broker service attempts to locate an object given its unique identity (GUID). By default, the object broker first looks in its local object store (referred to as a superCOS), which is either the publisher COS 544, the server COS 540 or the viewer COS 548. If the object is not located at the COS wherein the request was made, and if the object broker resides on a client machine (either the publisher or customer workstation), it will attempt to remotely retrieve the object from the server COS 540 at the MSN Data Center 242 (FIG. 3). In another embodiment, other object stores may register with a given object broker as a source of objects, which the object broker will search in between the local and remote retrieval cases. Associated with the object broker 546 at the publisher is the client side of the publisher interface, and associated with the object broker 542 at the network server is the server side of the publisher interface. The publisher interface is used to manage the publication of new, deleted, and modified objects. The capabilities of the object broker allow a publisher to test layouts or content that are shared with a different publisher. As an example, publisher A has a title layout A and publisher B has content that publisher B has agreed to share with publisher A. To test title layout A together with the content, publisher A could retrieve content provided by publisher B that is stored in the COS 540 by use of the object broker service. A MPC Wrapper DLL (MWRAP.DLL) uses the Microsoft Network Procedure Call (MPC) protocol to communicate with the network storage 122, i.e., the MSN Data Center 242 in the presently preferred embodiment, and the MPS services, such as the object broker and COS. This wrapper specifically isolates the COS/Object Broker subsystem from the specific MPC protocol so that the MP system 100 can be easily ported to use other protocols in other embodiments. IV. DESIGNER ENVIRONMENT This section of the detailed description will describe the designer environment at the publisher site. The concepts of sharing content among titles and of separation of design and content will be more fully described. This section begins with a discussion of the presently preferred authoring subsystem used by the MP system 100. Then, a title designer subsystem will be described, which includes the objects available to the title designer; the project, page, style sheet and search object editors used to create and revise the layouts; and the controls used to define the layout of a page. Next, the architectural structures used by the system to enable the creation, revision, and storage of design layouts and content will be described. Finally, the operation of the designer process and release process will be discussed. A. Authoring Subsystem Content is separated from design in the MP system 100. In the Viewer 202 (FIG. 2), content and design are brought together by controls to display a title as specified by the designer. As a result, these controls need to identify different elements in the structure of the content so they may format it correctly. This is done by creating structured content. The MPS authoring environment provides a way for authors to create structured documents. The MPS authoring environment includes the MPS Document Editor 188, which supports the creation of structured documents, insertion of links and the application of properties to these documents for content retrieval. The MP system 100 uses SGML (Standard Generalized Markup Language) to define the scheme for creating structured documents. SGML is a standard for defining a markup language--a set of tags and attributes used to identify the structure of a document called a DTD (Document Type Descriptor). The MPS Document Editor 188 will support saving documents in a format which conforms to the MPS DTD (MPML--Multimedia Publishing Markup Language). This DTD will be published for use with other SGML authoring systems. As part of this environment, the MPS provides a pair of Document Editor converters for reading/writing MPML files, a template defining styles and macros used to create MPML files along with some OLE controls used to insert links and apply properties to these files. To create content for the MP system 100 in the MPS Document Editor 188, an author creates a document based on the MPS template. This template provides a set of predefined styles along with supporting macros. The author applies these styles to the text to identify the different elements of the document (headline, abstract, body text, and so forth). Only the predefined styles should be used. When the document is saved in MPML format, these styles are mapped to SGML tags by the MPML output converter. The result is a tagged document which can later be parsed by the Viewer 202. The MPML converters for the Document Editor 188 support mapping styles applied to the text to MPML tags. In addition, it will support graphics inserted with the "Insert Picture" command of the Document Editor 188. This will support both linked and embedded graphics and tag them appropriately. The converters also provide support for the MPS OLE controls provided to insert links and apply properties to the documents. An important aspect of the authoring environment is that it is only to be used to generate tagged content. The author should not expect that the style definitions made or formatting applied in the Document Editor 188 will carry over to the Viewer 202 when the document is displayed. As part of the authoring environment, several OLE controls are provided which interact with the MPS environment to help the author insert links and apply properties to documents. These controls are normal OLE objects which are extended to support rendering their data in MPML format. The MPML converters will be able to recognize OLE controls embedded in the Document Editor document and ask them for their MPML representation using a well-defined interface. When the converters encounter an OLE object, they will attempt to retrieve a MPML representation from them using this interface and insert it into the output MPML stream. OLE controls which do not support this interface will be ignored. The use of the interface allows extending the authoring environment with new OLE controls as needed. 1. Story Editor A MPS story editor, which is part of the MPS Document Editor 188, is the main tool designers and authors use to create MPS story objects. A MPS story object consist of a stream of text with embedded objects such as links or pictures. MPS stories can also be tagged with Find properties so that the MPS Find system can easily and accurate locate stories. The main tasks involved in the creation and delivery of a story are: author the story; set structural properties for the story; optionally, place pictures into the story; optionally, create links to other stories, and set summary properties (including Find matching criteria) for the story. In addition to using the MPS Document Editor 188 to create stories, publishers can create MPS stories with other tools or with an automated process. For example, stock ticker stories probably will be created automatically. MPS stories are structured, which means that the elements that make up the story are logically identified. This is useful because the MP system 100 can take advantage of this logical description to help present the information to users. The Document Editor 188 makes this easy, wherein authors merely apply the Document Editor styles. This process may also be performed automatically using filtering software that is supplied by Microsoft or by third parties. The MP system 100 supports three main file formats. These are: (1) the MPS data file format, (2) MPML, and (3) the HyperText Markup Language or HTML. The MPS data file format is the native MPS story format. It is a standard OLE doc file with separate streams for text and the various objects contained within the text stream. The MPML format is available to make it easy to import and export MPS stories. A MPML file is an ordinary text file that conforms to SGML. Because this file format is a simple text file, it is easy for publishers to automate the process of creating MPML files. Most publishers will not need to use MPML because the MPS tools automate the process. The MPML file format is only important because it can be easily converted to other formats, which ensures an easy migration path for publishers. The MP system 100 can also import and export HTML text files. However, because HTML is fairly limited many advanced MPS features can not be represented in HTML. The HTML and the MPML converters are constructed as a separate program that enables publishers to make batch translations of files. Stories are usually linked to other appropriate content, and MPS Find properties are added to the story so the story can be found by the query subsystem. These steps can be performed using MPS or third-party authoring tools. If a publisher uses third-party tools to produce content, the results must conform to the MPS file formats to ensure that the Viewer 202 can interpret the content. 2. Links MPS stories typically have links to other stories or other information. The MP system 100 supports these hyperlinks through a link editor. The link editor is integrated into the Document Editor 188 and is accessible from the toolbar buttons or from an Insert.backslash.Hyperlink menu. A content selector is used to select the target of links and to select pictures to embed in MPS stories. 3. Find Properties To help customers find stories that might be interesting, the MPS supports the specification of keyword or keyphrase matching criteria through the file summary information option. A standard File.backslash.Summary Info dialog of the MPS Document Editor 188 is used to tag a story with retrieval attributes for search to find. Each field may be individually searched by the search editor. The Find dialog may search the title field uniquely, but the rest of the fields (subject, author, keywords, comments) are searched as a whole when the `Summary` box in the dialog is selected. B. Title Designer Subsystem 1. Overview This section describes the MPS title design environment, with emphasis on the Project Editor tool 184 (FIG. 2). The Project Editor 184 is the tool that provides a view into a project, and allows the designer to edit the contents of that project. A Source is a collection of MPS story objects stored on the MSN 122. In the presently preferred embodiment, each content folder is a separate source. In another embodiment, a single source may contain multiple content folders. 2. Objects The Title Designer may interact with an open and extensible set of objects that are placed within a project (either in a folder or in a title). Objects appear in the Title Designer just as documents appear in the Windows 95 Explorer: as icons in the right pane. Objects respond to clicks, double-clicks, right-clicks (which display a context menu), and drag-drop operations as means to manipulate them. Nearly all objects in the system have a property sheet. This is a standard-format dialog which allows for setting values associated with that object. It is accessed by selecting Properties . . . from the File menu, or from the context-menu of the object. A property sheet consists of one or more tabbed pages, which the user may flip through by clicking on the tabs. At the bottom of the page are three buttons: OK, Cancel, and Apply. OK saves any edits that were made and dismisses the dialog; Cancel discards any changes and dismisses the dialog. Apply saves any edits that were made, but does not dismiss the dialog. Switching between tabs does NOT save changes that were made to the previous page. a. Project A project is a collection of titles and content folders. Titles and content folders are collected so they can be edited simultaneously and then released in the preferred embodiment to a MPS server 246 (FIG. 3) together. A project object represents the entire contents of the project, and is the container of things that get released together. As such, it has properties representing where the project's contents are released to, and statistics about the release process. b. Title A title is a collection of pages and supporting objects organized into a hierarchy of sections. The title itself, as well as each section, acts like a folder in that it can be expanded to show its contents within the Title Designer. It is important to note, however, that the items within a title have a hierarchical structure that is defined by the designer and is essential to how the title is displayed. A title also has a Resources folder that contains any additional objects that need to be distributed with the title; for example, fonts and OLE controls. A title may have a price associated with it, which is set using the MSN sysop tools. A title object is a container for sections and pages. A title may also contain supporting objects, including style sheets, content objects, window objects, and resources that need to be installed. A title object has a context menu with common commands, and a property sheet for setting all of its detailed settings. When a new title is first created, it is populated with the following objects: a resources folder having a default style sheet and a default window, and a blank page (directly under the title object), named "Front Page". A title object contains pages and search objects organized into sections and subsections, as well as a collection of supporting objects (style sheets, fonts, OLE controls, and so forth). Pages and search objects may be contained directly underneath the title, or they may be organized into a sequence of sections. Windows and style sheets are placement-independent; they may also be stored within sections, or they may be kept in generic folders within the title. Fonts and OLE controls must be kept in the resources folder. The title maintains a sequence ordering of the sections, pages, and search objects, as this is important in determining how the title is displayed. The views supported by the project designer window allow the publisher to re-order these objects. The title object is the section which represents the entire title. From this root section the hierarchy of sections, search objects, pages and style sheets are added. The title object inherits from the section object and as such, it contains all the properties and attributes of sections. From a COS perspective, the title object is the root object in an object store. The title has a reference to all first level sections, that is, it is the root section. Like all COS objects, a smart pointer (CTitleSPtr) object is defined to access the methods of a CTitle object. The CTitle object (like other COS objects) does not have knowledge of the COS which contains it. This information is kept in the smart pointer and all access should be through a CTitleSPtr object. C. Section Like the title object, a section object behaves much like a folder. It, along with its contents, can be dragged and dropped. The only visible difference is that its contents has a sequence that can be user-defined. Sections having Dynamic story controls may set whether the Viewer 202 begins each story on a new page, or runs the stories together. For sections having static story controls, this setting is disabled. The content gathered into a section is sorted at pressing time before it is displayed. The designer may specify the sort order that will be used at that time. Available sort orders include: Priority, wherein the author or editor may tag each piece of content with a priority, (a number from 1 to 5, where priority 1 is the highest priority), and Date/Time. The designer may choose a specific page to use when the viewer jumps to a story out of sequence. This allows the system 100 to quickly compose the story without needing to compose all pages in between the current position and the desired story. Without the ability to do this, navigating to specific stories within a section would be painfully slow. The sequence of pages and search objects in a section help to determine how the section will be pressed. However, the rules are different for static and dynamic sections, as described below. A static section has all of its content hand-placed on pages. It does not use dynamic story controls to display content. In a static section, the pages are presented to the end-user in the order in which they appear in the section. A dynamic section uses the Dynamic Story control to display stories within a section. The stories are sorted according to rules specified on the section's property sheet and then are concatenated or linked together. The stories are then filled into the dynamic story controls on each page in the section, in the order in which the pages are arranged in the section. If there are more stories than there are pages, the last page is re-used repeatedly until all content has been pressed. When in "home delivery" mode, all of the stories are pressed at once; otherwise the system presses pages on demand. In the "on demand" mode, if the user chooses to jump to a story out-of-sequence, the MP system 100 must choose a particular page in the sequence to start displaying that story. Because the MP system 100 has not had an opportunity to press all of the stories before the one that is jumped to, it does not know which page would be used if the user read the stories in sequence. The designer may mark a particular page to be the "out-of-sequence" page, which is then used for these cases. Search objects are activated in the sequence in which they appear in a section. Because of this, the ordering of search objects in a section has a subtle influence on the final ordering of contents. The sorting specified by the section is done as a "stable sort". For example, if two stories, gathered by different search objects, sort to the same place, the one whose search object was listed first in the section will be listed first. The sequence of pages and the sequence of search objects have no relationship to each other. They may appear interleaved in the section container with no unusual effects. The section object provides the hierarchical structure of a title. It can be thought of as a folder which can contain other sections (sub-sections), search objects, style sheets, pages, and content. The different objects are managed in separate lists and because of this there are similar but distinct API's to access each of the object types. There is no single homogeneous list containing all the objects that are part of a section. Sections provide logical breaks in a publication. For example, the different parts of a newspaper can be represented by sections: Front page, Sports, Lifestyles, and so forth. Sections also play an important role in the composing and navigation features of the MPS as follows: i) Dynamic navigation to sections via information maps ii) Direct navigation to sections via action controls iii) The first story of the section is always composed on the first page of a section. iv) Pages from previous sections do not propagate to subsequent sections. Each section contains the pages which are to be used to compose it's stories. v) The search objects contained in the section define the content that will be displayed there. Ordering of objects in a section is important. The title is composed top to bottom, with sections at the top being composed before sections further down. Similarly, pages are used in the order they appear in the section, and dynamic stories appear in the order of the search objects in a section. A smart pointer (CSectionSPtr) object is defined to access the methods of a CSection object. The CSectionSPtr will instantiate the CSection object from the COS and through it's overloaded arrow operator, allow access to the section methods. d. Window A window is a place a page can be displayed. A window may have a fixed size, or the height and width may be changed at runtime to match the page being displayed in the window. A window object may reside within a section in a title, or it may be contained within the generic resource folder in the title. The designer makes the decision about where the window object is to be contained. The window object acts as an OLE frame object and client site for an embedded page. The page object (or any compound document server) and the window object interact solely through the OLE Compound Document interfaces. The window object and page object together provide a full in-place capable OLE container. The window object implements the IOleInPlaceUIWindow for its document and the IOleInPlaceFrame interfaces for its frame. It provides the object window (in the Windows sense of the word "window") and it also provides menu bar handling. By breaking up an OLE in-place container into two parts (window object and page object) using IOleInPlaceUlWindow::SetActiveObject, the page object can be attached and detached from a given window object at run-time. This approach saves time by not having to destroy and re-create a Windows window every time a new page is needed to display data. This is useful within the MP system 100 because it is very common to use two pages (e.g., SectionFront and SectionDetail) to display a particular portion of content. e. Page A page is the representation of the layout of the client area of a window. The layout within that page is represented by control objects. A page is a container for controls. In the presently preferred embodiment, a Component Forms development environment for pages operates like Microsoft Visual Basic or Microsoft Publisher in that designers place objects (controls) on a page by selecting and placing them. When opened, a page presents itself in "design mode" in which the user can lay out the page with controls. Properties of the objects are available through property browsers or a context menu. Pages are contained within sections. Within a section, the pages have a sequence that determines the order in which they are used to press content and the order in which they are displayed when the user browses sequentially. A page may be used in more than one section; this is accomplished by making a shortcut to the page in another section. A shortcut to a page has a place in the sequence of pages just as the real page does. A page object is an implementation of an OLE compound document server. The page object can contain any arbitrary OLE control to create any type of Windows application. The page object supports OLE controls fully and is a full compound document server that also supports in-place activation with the IOleClientSite, IOleInPlaceSite, and IAdviseSink interfaces on its site objects. Unlike most OLE implementations, the page object requires a window object to become an OLE container. The window object wraps a page object and displays it in a top-level window or child window. To work properly with controls, the page object also implements an IDispatch interface for ambient properties and an IDispatch interface for control events on its sites, along with a new IControlSite interface that serves as a notification sink for changes in a control's mnemonics. f. Search Search objects describe how to collect stories to be pressed into a dynamic story control. Only sections with pages having dynamic story controls take advantage of search objects. A section with one or more dynamic story controls may have zero or more search objects collecting stories. If two search objects collect the same story into a section, then only one instance of that story is actually collected and displayed in outline controls and in the dynamic story controls. g. Style Sheet The style sheet object encapsulates a mapping of style-names to formatting instructions. The style names are a fixed set that authors can apply to their stories. In this way, authors do not need to concern themselves with formatting their content; they simply use a standard set of styles, and the formatting is automatically applied at pressing (using the style sheet that was designed into the title). Since outline, static story, and dynamic story controls rely on separate content, they use style sheets as the basis for their formatting. Opening a Style Sheet shows a list of the styles available. The publisher may select a style and edit its properties by pressing the Modify . . . button. This displays a tabbed property sheet that lists all of the formatting settings. There are three types of styles: character, paragraph and wrap. Character styles may be applied to a selected set of characters. They include only those settings that can be applied to an arbitrary set. Paragraph styles (displayed in bold in the list) are applied to the entire paragraph. They include extra settings that affect how the entire paragraph is laid out. Wrap styles (displayed in italics) classify wraps as to their functional use, so that they can be fitted to a particular area of the outline, static story, or dynamic story control. h. Extensibility The designer may extend the design environment by adding new OLE controls. These controls may support a wide range of functionality. They may provide generic display capabilities (e.g. video, audio, sprites), or they may utilize the MPS Information Map interfaces to provide new means of navigation. OLE controls may also add additional actions to a list of available actions. i. Content Folder A content folder is a container of story objects. It may contain story objects, and other folders. When a project is released, the contents of each content folder in that project are copied to their respective source on MSN 122. Search objects are set to look for content within a specific source. Through the Project window, the publisher may place stories within these content folders so the search objects can find them when the stories are released to the source on MSN 122. Content folders are containers for titles and for story objects. They appear as top-level items underneath the Project, and may have further sub-folders. Search objects use Content Folders to identify the scope of their query. Content objects are represented by a generic document object within the designer. There are two kinds of content objects: Stories and Pictures. Stories represent MPS stories while pictures represent wavelet or metafile pictures. When the New Content command is used to load in a new picture, the picture is automatically converted to a wavelet, unless it is a Windows metafile (in which case it is left unconverted). Pictures which are saved as wavelets also have a property page which allows for controlling the amount of compression that is done on the image prior to sending it to the viewer for display. Objects may be drag-dropped from the desktop or the file system into a content folder. These objects will then be released to the Data Center 242 when the Release command is selected. When objects are brought into the system 100, the project stores a path to the original file that was copied in. J. Resource Folder Titles may need additional resources, such as fonts and OLE controls. The designer adds these items into a project by drag-dropping (or copy-and-pasting) them into a title. Each title has a Resources folder directly underneath the title object, with subfolders named Fonts and Controls. The designer adds new items to the title by dropping them into those subfolders. The designer may also place window and style sheet objects within those folders, which are not necessarily associated with any particular section. This allows for managing the supporting resources separately, or for keeping them with the sections that use them. The MP system 100 assumes that all of the OLE controls and fonts in the Resources folder need to be installed on the customer workstation 182 to run the title. k. Shortcuts Just as in the Windows 95 Explorer interface, shortcut objects may be created and used through the project in place of the objects to which they refer. For instance, if the designer wished to use the same page in five different sections, then the designer can create the page in one location and place shortcuts to that page in the other four locations. Since none of the object's properties are duplicated, changing the original will change its use in all the places where shortcuts to it exist. Shortcuts are sequenced exactly as their referenced objects would be sequenced. For example, a section can contain a mixture of pages and shortcuts to pages, and the two could have a single, potentially intermixed, sequence. The "Go to specific page" action takes as a parameter any page or shortcut to a page. Shortcuts must point within a title or content folder. Shortcuts may not point between titles or content folders. 3. Project Editor The Project Editor 184 provides the user environment and editing facilities for creating and editing MPS projects and titles. The Project Editor 184 limits itself to defining the structure and organization of the title, leaving the page layout and content definition to other parts of the MP system 100. The publisher interacts with objects in the title through the Explorer-like UI provided by the project editor. The left pane of the editor contains the title structure elements (e.g., sections) and the right pane contains the objects contained in that section (e.g., search objects, pages, and so forth). Through the project editor, the publisher adds the sections, search objects, style sheets and pages which define the structure of a title. The project editor uses a drag-drop metaphor for moving and copying objects within, and between, titles. The project editor is the central editing point in design mode, and as such it interacts with the search object, stylesheet, and page editors to configure and set properties on the title objects. In most instances these editors are invoked by double clicking on an object in the project window. The project editor also supports the idea of styles where the properties of an object, say of a search object or section, are based on an existing search object or section. i) Interfaces The project editor provides two types of interfaces: 1) standard MFC C++ interfaces to integrate into the framework, and 2) an ITitleEditor interface to support the command architecture. Specifically, this interface is used to add, remove and modify objects in the project editor. Typically, these are invoked through menus or other UI components, but they could also be called via automation. The following services are require | ||||||