All digital document systems share a fundamental document lifecycle: the application is loaded, the document is read in and internal data structures are built for it, the document is formatted, then it is painted on the screen, at which point the system waits for the user do something. To open this to arbitrary new behaviors, the process is reified into sharply segregated protocols: restore behaviors, build document tree, format document tree, paint document tree, low-level events (such as from the mouse and keyboard), semantic events (described next section). During the build protocol, say, all interested behaviors have the opportunity to build on the document tree data structure, modifying the work of other behaviors.
The system is a framework where the system is in charge of the overall flow of control. Frameworks contrast with systems in which the developer's program defines the flow of control, sometimes passing through libraries. For every protocol in the framework, the system will pass through relevant behaviors, briefly handing off the flow of control to a behavior to perform all of its work for that protocol only. Behaviors may not have any work to perform in a particular protocol, but while in one protocol it is illegal to work on another protocol.
Most protocols have before and after phases: the before phase of the protocol is executed in its entirety, then the after phase. With arbitrary behaviors active at any point in the document lifecycle and with potential dependencies on other behaviors, the division of protocols into phases helps sequence behaviors. The rule of thumb is that behaviors that build structures do so in before, so that all such activity is known to be completed by after, which can modify it or cancel it. For example, during build before, one behavior can load in the main body of a document, so that it will be available for annotations to hook into during build after. A behavior can short-circuit from before to after phases thus bypassing lower priority behaviors, or from after to end the protocol.
As appropriate to their intrinsic nature, protocols are either round robin or tree based. Round robin protocols flow through the before phase of all active behaviors from highest priority to lowest, then the after phase in reverse order. Thus the highest priority behavior is called first and last, getting the first word and the last say, as it were. The round robin protocols are Restore, Build (at the start of which the tree does not exist), Semantic Events (such as openDocument and newBrowserInstance), and Save.
Tree-based protocols proceed through a depth-first tree walk, during which tree nodes can also affect control flow. Behaviors interested in a structural portion of the tree register interest (programmatically, add themselves as observers) to the node at the head of the subtree, and during the tree walk the before methods of the observers are called before the node and its children are traversed, and the after methods of the observers are called after the node is done. Behaviors can short-circuit from before to after, thus bypassing that subtree; and after can short-circuit to cancel the remainder of the tree walk. The tree-based protocols are Format, Paint, and Low-level Events.
Below are described the low-level protocols: those performance-intensive protocols concerning construction and display of the document, and system input.
| Core Format and Paint Properties |
|---|
| foreground and background colors |
| font family, style, size |
| underline, overstrike |
| elide |
| justify |
| spaceabove/below |
| horizontal and vertical alignment |
| float side |
| margins, padding, border |
| signals |
All nodes, whether heavily medium-dependent leaves or largely medium-independent internal nodes, must respect a core set of properties during Format and Paint protocols, the full set of which is given in the table at right. Behaviors rely on a this guaranteed level of functionality across media types. For instance, the selection and the highlighting annotation rely on setting the background of a word to a given color. Most media types can simply draw the word over the colored background, but scanned paper must identify the white pixel in its image and convert it to transparent before drawing the image of that word.
All painting is performed under a clipping region, which at largest is the size of the visible screen. During the tree walk, only nodes that lie within the clipping region are pursued; thus, when an internal node lies outside of the clipping region, its entire subtree is ignored, and the system is able to quickly paint, with just a small amount of wasted effort, that part of a potentially long document that is visible on the screen. Lenses operate by setting the clip to just their bounds, or their intersected bounds, and repainting the entire document with certain properties set. This process is so rapid that the entire screen can be repainted in full continuously during scrolling. This is as opposed to a "bitblt" which copies that part of the document that remains onscreen but at a different location; bitblt-based scrolling is problematic in Multivalent because notes and lenses can be fixed to a point on the screen and so don't scroll with the rest of the document.
The Move-To behavior accomplishes this by using a tree node function to determine the lowest node in the tree common to both start and end points, and registers interest on that node. At this time it computes the coordinates of the start and end points of the arrow relative to the common node, to be used in any number of future paintings. Now for all protocols the behavior receives notification of activity on the node; in this case, after the content of the subtree has been painted, which is to say in the after phase, the behavior draws the arrow using the precomputed coordinates. Since the lowest common node frequently extends beyond the visible screen, parts of the arrow are at times painted uselessly, but the total amount of wasted work is contained within a relatively small portion of the document. During interactive setting of the arrow, the behavior quickly unregisters from the last lowest common node, computes the new node, registers on that, computes coordinates, and repaints the screen.
As a high level action, semantic events are relatively infrequent and thus not performance critical. They are sent to all behaviors, with before and after phases. A semantic event consists of a message, such as openDocument, and three fields labeled argument, in, and out, whose exact content types depend on the message, though the rule of thumb is that argument corresponds to the most commonly needed auxiliary data, in holds the sender of the event, and out collects results from participating behaviors.
Semantic events are most often sent to request action and to announce state. Even when a behavior could directly invoke itself, it is often better to request the action and give other behaviors a chance to modify or cancel the request. Other semantic events announce potentially interesting state. Semantic events are most often acted upon by behaviors to implement a requested action, to modify the event, or to update state in response to an annoucement event.
For example, when a document has been loaded, surviving potential 404 File Not Found's and redirections, the system announces openedDocument (note past tense), and the forward/backward behavior adds it to history list. The search behavior announces its results in a searchHits semantic event, which is caught by the scrollbar visualization behavior. Media adaptors for HTML, directory listings, and Zip archive listings all send the table sort behavior, with sortTable as the message, and node and direction in fields. The table sorting behavior catches the event, inspects table to determine the data type of the requested column, sorts, and rearranges the document tree to reflect the sort order.
The Multivalent DVI media adaptor supports specials without modification of the parser-renderer with the same mechanism as used in the rest of the system, the behavior. The parser announces specials as semantic events, passing the special string, and geometric and logical (document tree) positions in fields. Behaviors implementing specials listen for the relevant messages, and have enough information in the fields to accomplish their work. The HyperTeX hypertext and PageSize specials are currently supported, and image and color will be.
Some of the more important semantic events that are defined by built-in behaviors include the following. See Document.java, Browser.java, and others in API.