Document Definitions

DocumentDefinitions is a simple set of reference definitions (associated with the document-based model for UserInterfaces) for use in other pages that reference this one, without introducing a page-per-definition (since WikiIsNotaDictionary). This page gives reasonably precise working-definitions to several words associated with documents, interfaces, and features associated with them that might otherwise be too fuzzy for distinction.

You are not expected to agree with the following definitions, only to understand them in their context and resist pointless LaynesLaw battles. That said, the definitions do attempt to remain reasonably consistent with the common use of words.

document: a presentation of information and options designed for consumption by humans, with a default bias towards two-dimensional static visual presentations of text and graphics. The 'document' concept extends in general to the auditory and temporal dimensions (as per: sounds, animations, music, video) designed for consumption by humans, and could presumably be extended to other senses. Documents tend to be composable and decomposable, and as a consequence the boundaries between them are arbitrary and are often chosen for convenience to the discussion at hand. Sensors, actuators, commands, queries, processes, and protocols are examples of things that are not documents, though information about these things can be presented in documents.

active: A document is active if it presents input options to a human operator. Traditional input options include push-buttons, knobs, sliders, toggles and radio-buttons, text-fields, menus, and drawing canvases. These options are designed largely around the common input devices - mouse and keyboard. However, one can provide activity in other ways: gestures, drag-and-drop, context menus, focus, hooking joysticks and microphones and cameras, command-lines, etc. Degree-of-activeness can be measured in terms of spatial properties (e.g. percentage of document supporting user input) and logic costs (fraction of document definition associated with presenting or providing input options, but not to processing the actual inputs).

live: A document may be live, in which case it automatically reflects updates to external systems - specifically excluding user input - over time. Example features include dials, gauges, lights, rolling text, progress bars, alert-icons, changing text, pop-ups. Examples of live documents include RSS feeds, web cameras, stock tickers, etc. Liveness can be measured in degrees in terms of reactivity (e.g. latency between an update to a system and its corresponding update in the document), spatial properties (percentage of document subject to update).

static: A document that is neither live nor active is static. Static documents might still be subject to update, but said updates won't be seen automatically. Static documents can still be temporal in nature (such as sounds, movie clips, and animations). A bit stronger than 'static' document is a dead document, which will never see updates. Documents tend to become dead through neglect, completion, or versioning.

interactive: A document is interactive if it is active and there is a causal feedback loop such that activities cause changes to the document. Interactive documents don't need to be live (as evidenced by simple calculators, simple video-games, etc.).

interface: A document is an interface if it is active and the activity causes a command to an external system. Doesn't imply live feedback as part of the document. Interfaces without feedback are often applied usefully when the external system being controlled is within visual or auditory range of the operator. The degree to which a document is an interface is determined both by how active it is and how many activity options influence the external system as opposed to modifying the presentation of the document.

live interface: an interactive interface document such that at least one bit live feedback is causally influenced by external systems that are causally influenced by activities. I.e. there exists a causal interactive loop via influence on external systems, as opposed to 'document local' feedback loops.

document definition: A complete, serialized representation for a document. Document definitions are immutable, but that fact does not hinder liveness (which may be achieved through keeping a document definition up-to-date relative to its source document-object or through the document composing external data-sources such as other document-objects).

document object: A service that, upon request, provides a document definition. The traditional example of a document-object is a file, but documents can just as easily be requested from live systems, and it isn't unreasonable to even treat queries to databases as 'document objects'. 'Document object' in the purest sense should be understood as possessing 'universal identity', such that two distinct requests for the document object without any intermediate updates to the object can be guaranteed to return the same document definition. (Caching and other practices relax this purity in order to improve performance, but understanding 'uniqueness' of document objects still remains important to understanding the document-based UserInterface model.) Document objects give identity to documents. For example, concepts such as create, update, delete, history, versioning, difference, DataDeltaIsolation, and subscription are not relevant for document definitions but are meaningful when applied to a document objects.

document server: A service that, upon request, provides or creates+provides a document object. That might sound incredibly generic, but this definition is meant to be interpreted in a rather literal sense: (a) the provides "or" creates+provides MUST be a decision that can (at least potentially, unhindered by protocol and semantics) be made "upon request", (b) it provides a "document object", as opposed to returning a document definition, which means the return value from this request is an identifier for a document object (generally a URI). With that clarification it might sound too narrow, but it is acceptable to view "returning a document definition with an implicit order to 'clone' with a new 'self' identity" to be a mechanism for creating+providing a document object, at least so long as said document object arguably has independent identity. Under this definition of document server, a traditional FileSystem or FTP server doesn't qualify as a document server (since FileSystems are traditionally not supposed to create documents upon request), but any modern WebServer certainly qualifies (with Dynamic HTML and forms being 'new documents' - TiddlyWiki is an extreme example of how such divergence can occur). This definition for 'document server' makes distinctions that are irrelevant until considering multi-user environments, the possibility of shared forms, and issues of divergence that are more significant than merely being out-of-date with the source.

shell: a framework and LayerOfIndirection that mediates between an application and an application platform to produce a UserInterface. Part of the application model of UserInterfaces. While "shell" in common vernacular refers to the CommandLineInterface, shells may also be graphical in nature (Windows Shell, Gnome, KDE). The indirection enables a great number of features, such as consistency and stylizations and multiplexing of some user input.

application: a program that produces a usually interactive UserInterface via interaction with a shell. Applications are often distinguished based on the frameworks against which they were written, such as 'command line application' vs. 'Win32 application' vs. 'MFC application'. However, application is mentioned here to distinguish the application model for UserInterface from the document model for UserInterface. An overview of the most relevant differences (and the reasons for their relevance) is at the bottom of the page.

application platform: the platform atop which application programs are built. Usually refers to an OperatingSystem, a VirtualMachine, or a WebBrowser.

browser: a browser is a UserInterface service that provides meaningful interaction and navigation within a system of objects. A 'document browser' would be a browser that is targeted to interact with document objects, but there are other sorts of browsers (ObjectBrowser, FileSystem browser). Assuming a document browser, the primary "meaningful interactions" would include display of documents, keeping said display up-to-date, zooming, navigation between documents, support a multi-tasking user by allowing multiple documents to be displayed simultaneously, multiplexing user inputs for activity between and within documents, and sending appropriate command-messages as a consequence of said activity based on object definitions.

In the 'pure' sense, a mere 'document browser' should not have any responsibility for maintaining or hosting document objects.

However, a typical WebBrowser also shoulders this responsibility due to Dynamic HTML and forms. Hosting document objects introduces a significant amount of complexity. As two examples, one now needs a document object model, there are 'concerns' for such issues as persistence and recovery that simply don't exist if all document objects are hosted externally, and so on. Introducing this extra responsibility essentially to a document browser essentially forces the browser to serve a dual role as an application platform.

document object model: A language for selectively identifying parts of a document definition. A necessary prerequisite for allowing a language to manipulate parts of a document definition. A document object model (or more than one) is used in DataDeltaIsolation and for allowing browsers to act as application platforms (host documents and accept commands to update said document). The 'trivial' document object model is simply to treat each document as the sequence of bits used to serialize the document definition, but this model is rather difficult to program against. 'DocumentObjectModel' with capital letters refers more specifically to the W3C standardized DocumentObjectModel for XHTML and XML.

Comparison between Application and Document models.

Application Model for UserInterface

Entities

shell: instance of running interaction with shell framework
application: program that interacts with shell to produce UI and with platform to provide other service
platform: instance of OperatingSystem/VirtualMachine/WebBrowser on a particular computer

Relationships:

shell---application (1 to M, with rare exceptions)
shell---platform (N to M)
application---platform (N to 1)
application---protocol---application (N to K to M (K usually 1), e.g. RTP, database, filesystem)
platform---protocol---platform (N to K to M (K usually small), e.g. TCP/IP, filesystems)

Properties:

No shell---shell relationships. E.g. no linking, embedding, inheritance, or other composition of UI between applications.
Composition of applications and platforms occurs indirectly through protocol stacks, of which there are a great many. Protocols allow hooking applications together when you can figure out their name (capability) and you happen to support common protocols. Name distribution is a challenge. Arbitrary composition of applications is also a big challenge due to the common need for one of the two applications to be upgraded with new protocols. (PluginArchitecture can help greatly with this protocol management.)
Retained-mode GUI by default. In particular, the current set of relationships between the shell and the application generally cannot be regenerated and may contain information important to the logic of the program. E.g. whether an alert-box is displayed can be based on a prior event. Retained-mode makes testing, UI rewind and DVR capabilities, etc. a great challenge. It also makes it almost impossible to turn the shell 'off' then turn it back 'on' later and get it to a proper state; instead, the shell needs to be on all the time, which is severely problematic for scalability and ZoomableUserInterface. Applications can be made immediate-mode, but it takes SelfDiscipline.
Retained-mode composition of applications, by default. That is, applications can't simply be disconnected by the OS then regenerate their connections on the fly as needed. Instead, most connections must remain live all the time.
Composition of applications is indistinguishable from composition of servers. This prevents some automated optimizations that involve running just the server portion, though this can still be done by hand (and often is done by hand).
Applications are associated with a specific platform. Distribution and sharing occur only to the degree that the platform can be distributed and shared (or at least virtualized, as per VirtualNetworkComputing). Currently, that degree is pretty small.
Input to application comes from two sources: platform, and platform via shell. This means the shells cannot intelligently multiplex all user-input to applications, cannot prevent misinterpretation of inputs based on immediate user focus, and in general couldn't properly map all user-inputs to the application even if shells did happen to be composable.
No clean relationships to inject caching.

Document Model for UserInterface (pure, rejecting browser-as-application-platform)

Elements:

document browser: displays document definitions, keeps them up-to-date with document object
document object: provides temporal identity, sharing, and subscription model for document definitions;
document server: any object that creates+provides document objects on request
other objects: accept commands, cause behaviors.

Relationships:

document browser---document object (N to M, browsing and subscriptions, subject to caching)
document object---document object (N to M, via embedding, linking, sharing)
document object---document server (N to M, via a request commands plus a primitive navigate command)
document object---other objects (N to M, via issuing commands, often unidirectional)
other relationships between objects outside model (generally object---object is N to M)

Properties:

Fundamentally a RestArchitecturalStyle (representational state distribution) + PublishSubscribeModel (to maintain state).
Browsers are far more independent of one another than are typical applications. They do not compose, connect, or even know about one another.
Browsers only need document definitions, not the full document object. This allows caching on the interaction between browsers and document objects. Such caching may improve performance and reduce bandwidth costs, and would certainly improve robustness after network failure. Subscriptions may also be cached, allowing many subscriptions to be reduced to one subscription at each network boundary (for up to exponential savings in total bandwidth).
All user-driven inputs to documents go through a browser, which offers much more control to the browser for remapping inputs and multiplexing inputs.
All things other than browsers shared and distributed and composable by default. This sharing has a simple semantics: make everyone 'see' the same document at the same time (plus latency). With shared forms, for example, everyone would (eventually) see the same checkboxes marked and the same text in the text fields. With streaming music or video, everyone would be at the same place in the stream at the same time. Sharing by default is sensible for composition (esp. by embedding and inheritance), since composition of objects implies sharing of objects. To avoid sharing requires creating new documents.
New documents are always introduced by command (requests to document servers), never by composition or linking. This allows composition to have consistent semantics, and the consistency in turn simplifies many optimizations. Compare HTML, where a (conceptually) 'new form' or 'new browser-application object' or 'new plugin object' can be introduced by use of plain-old-links, composed into iframes or <object></object> field, such that after 'composition' of documents what is actually available is a mishmash of old and new documents where the 'new' components cannot be faithfully shared, recomposed, or regenerated.
ImmediateModeGui for both browser and document composition. This allows the browser to disable and regenerate displays on the fly, as well as recover after a power failure or network disruption, making for a very robust display system. Subscriptions may be disabled and enabled on-demand without fear of missing 'events' and falling out of synch, and may do so without special consideration or design within the documents or servers. The ability to disable subscriptions and display and regenerate them at need is important for scalability and ZoomableUserInterface.

HtmlDomJsCss and WPF might be considered hybrid models of Application UI and Document UIs.