Text Workbench

A Computer-Assisted Work Environment

The Text Workbench is a personal work environment for text-intensive work such as software development, engineering and scholar research. It integrates seamlessly with a Text Server, profiting from its text storage, navigation and transformation facilities. The application provides a presentation layer that can render the text queries and accept input from the user in several formats: as a common word processor document, a spreadsheet, a list or tree. Specialised rendering units can support generating images, sound and video.

Last update on Sun Jun 5, 2011.

Frames

The user interface consists of some windows that contain frames. A frame is a rectangular area that can be resized and fixed at one border of the window. The contact line between frames can be moved, resizing all adjacent frames.

Frame sources

Each frame shows an editable page. So far this is like a common text editor. But instead of being a single file or a directory, a page renders text bound to a text selector.

For example, supposing one would work on the document documents.=new-project. A sidebar on the left side could be bound to documents.=new-project.:t, being t the base type for all document titles, thus showing a list of the document's chapters and sections. The main frame could be bound to documents.=new-project.:prose, thus showing not only the titles but also the paragraphs.

The formula defining the text source can be viewed and edited, perhaps at some place in the window such as the source formula cell of a spreadsheet or on a separate tab register, frame or floating window. If the user edits the formula the frame shows the new contents immediately.

Formulas defining sources are kept as parsed text in the text repository too, they can be called by name or in general by a text selector. A text selector is a text query that returns some text units. The simplest text selector retrieves a single text unit by name. A complex text selector can be a script that transforms some text units and returns a generated text.

Frame dependencies

The source of the main window can be controlled by the sidebar. When navigating on the sidebar, the user can assign the current node as source of the main window. For example, if one clicks on the main title, the whole document is shown in prose form at the main window. If one clicks at the sidebar on the second chapter, just the second chapter is shown at the main window. One can also get a single paragraph and even a single sentence on the main window.

Frame dependencies are not restricted to sidebar and main window, in general frames can be bound to other frames. For example a right sidebar could show lexical information about the current word in the main window borrowed from a dictionary (being the dictionary itself parsed text in the repository, too). One could have a horitzontal frame at the bottom showing related passages of some other document, for example context of citations. The more Ted Nelson's ideas about deep electronic literature get implemented here, the better.

Style

Each frame has each time a particular style. The sidebar could present information as a tree and each title could be expanded and collapsed. The main document could present the prose in the usual form for a word processor.

Style Units

The style is defined by a text structure similar to the current CSS style sheets, but parsed as text in the repository and bound to some units. Through styling one can define the main layout form (prose, list, table, tree, form, s. Presentation) and also the font family, color, margins, borders etc. of the contained elements depending on their names, roles or types.

Text Structure

The Universal Text structure (unit, roles and types names, parent-child relationship) can be expressed in many ways in a frame. For example, in formal UTL prose syntax:

~role =unit :type data

One can also get graphical emphasis on the structure, just changing the style. For example, role names could be green, type names brown and unit names blue. Or, when representing a book, the whole line that represents a chapter could be rendered with a larger font size. One could also omit completely the explicit unit names, i.e. chapter names would be shown as in a book, with graphical emphasis and without ~chapter marks. The roles or the names could also be shown in a narrow column at the left side of the prose.

The user can change the representation at any time. For example, hide unit names, then show them in UTL, then change to show them in a separate column, then in a tooltip, etc. One can change colors or font sizes, etc. Style changes can be done through the graphical user interface or editing the style definition in another frame.

The whole structural information needs not to be unambiguously shown in every representation. For example in a book representation one can hide the unit names. But it is always possible for the user to recall every structural information just changing the style.

Style Swap

When viewing any unit the user can change easily its presentation mode to one of the available styles bound to it either directly or through its parent, role or type units. For example, the table of contents of a book can be edited in prose or tree layout.

Presentation Engine

The user interface has a modular structure, being an autonomous presentation engine responsible for rendering a particular text unit on a frame and managing user actions on it.

These presentation engines are included in the base installation of the Text Workbench:

• Prose Presentation Engine — It presents rich formatted text in flow layout as a current word processor
• Table Presentation Engine — It presents text in tabular layout as a current spreadsheet
• Tree Presentation Engine — It presents text as a tree with expandable nodes

Extensions can add they own presentation engines, too.

Implementation

A presentation engine is a text unit saved in the repository that includes executable code. Its layout and behavior can be parametrized through text types. A user can instantiate such a type and set some values, then invoke the presentation engine with it. These types are called ”Style Units“ (s. Style). Such a type has a similar function to a CSS style sheet today on the web.

Binding

A presentation engine is bound to a particular unit and can be loaded in the Workbench. On each ocurrence of such unit (or its descendants, its type or role instances) it can be activated and it assumes input and output.

Data Access

Access to the text data on the server uses cursors.

Loading On Demand

If a large view is to be presented at a window, it is not full loaded, just the minimal amount of it is retrieved from the text server to present a full window. The user can scroll the window or go to a particular position, but only what is effectively seen at a time is kept in memory. This way one can render huge documents without performance limits.

Updates

If the user edits the binary contents of some unit in any frame, the update is commited to the text repository. One can also delete units and add new ones.

Programmer's Workbench

The Programmer's Workbench is an extension of the Text Workbench to support software development.

Presentation Engine

It includes a presentation engine adapted for programming languages. It provides syntax coloring and common navigation such as ”goto Definition.“ It provides a parser for the supported languages, too. Entering say C source code does not store strings in the text repository, but parsed units that instantiate the C semantic units.

Compiler

A compiler is a text transformation operation that generates executable code. Note that the source code in the repository is already parsed, the compiler just generates assembly units. The compiler opens a text cursor for a particular selector and generates units with assembly semantic accordingly. The assembly units are processed by an assembler transformation that generates executable machine code that is stored in the repository as binary data. This executable code can be bound to particular units and be implicitly run by the text-engine when needed.

If one works in a traditional file-based operating system and needs executable files, one can export the binary executable code at the repository as file. If one needs to use a legacy compiler that processes files, one can generate plain text files as an interstage and pass them to the external compiler.