Objects are basic content packets of an arbitrary, user and developer extensible nature. Types of elementary objects could contain text, graphics, equations, tables, spreadsheets, canned-images, video, sound, code elements, etc.

Documents are a coherent entity made up of an arbitrary mix of elementary objects bundled within a common "envelope" to be stored, transmitted, read, printed, or otherwise be operated on.

the MIME specification is an example of a document definition based on a higher level collection of elementary objects.

Objects and the documents made out of them are shareable among members of a networked community: they may be simultaneously viewable, manipulable, and changeable according to rules appropriate to their nature and supported in access permissions and restrictions contained in their definitions.

Each creation or modification of an object automatically results in the creation of a stamp containing information concerning the date, time, date, and user identification associated with that modification.

Users can filter and control the portrayal of this information and their associated content objects.

Users can affix personal signatures to a document, or a specified collections of objects within the document, using private signature keys. Users can verify that the signature is authentic and that no bit of the signed document or document segment has been altered since it was signed. Signed document segments can be copied or moved in full without interfering with later signature verification.

Objects comprising a document can be arranged in an explicit structure. A hierarchy is but one example of such a structure; others could include more complex cross-linked structures. Compound-object substructures may be explicitly addressed for access and manipulation.

Documents, a user defined knowledge package of structured objects, are shareable, subject to access or privacy provisions, across the entire global domain in which any online collaborative working relationships are established in potentially ever-changing and evolving ways. This is the most fundamental requirement of an OHS.

Access controls can include, for example, allowing or disallowing a range of access types.

Every object that someone might validly want/need to cite or otherwise access should have an unambiguous address, capable of being portrayed in a human readable and interpretable manner. Most common existing spreadsheet programs have provisions similar to this for cell addressibility.

It should be possible to display and specify the complete link address of any object in the global domain of the OHS. This human-readable description of the "address path" leading to the cited object should permit a transparent possibility for human understanding of the path including the possibility of reading, interpretation, and conceptually following the specification.

Embedded objects called links can point to any arbitrary object within the document, or within another document in a specified domain of documents. Links can be actuated by a user or an automatic process to "go see what is at the other end," or "bring the other-end object to this location," or "execute the process identified at the other end." These executable processes may control peripheral devices such as CD ROM, video-disk players, etc.

Information about other objects pointing to a specific object in a document is available.

Hyperdocuments in personal, group, and library files can have access restrictions down to the object level based on individual identity or organizational role.

Access controls can include, for example, allowing or disallowing a range of access types such as read, write, or knowledge about existence.

Objects may be displayed differently depending on user or application control or the nature of the portrayal device.

A structured, mixed-object document may be displayed in a window according to a flexible choice of viewing options. These could include selective level clipping (e.g., outline views), but also filtering by content, truncation or some algorithmic view that provides other portrayals of structure and/or object content perhaps incorporating new sequences or groupings of objects residing in other documents. Editing on structure or object content directly from such special views would be allowed whenever appropriate.

People reading documents online, or offline from hardcopy portrayals of a time snapshot of a document, are able to follow link citations though human visible and interpretable addresses.

An integrated, general-purpose mail service enables a hyperdocument of any size to be disseminated to anyone in the knowledge community. Any embedded links are also faithfully transmitted and any recipient can then follow those links to their designated targets that may be in other mail items, in common-access files, or in "library" items subject, of course, to access controls.

A Journal is an integrated library-like system into which a hyperdocument message or document can be submitted.

An automated "clerk" assigns each Journal document a unique, permanent catalog number, stores the item, notifies designated recipients (if any) with a link for easy retrieval, notifies of supercessions, catalogs it for future searching, and manages document collections.

Access to Journal documents is guaranteed when referenced by its catalog number, or "jumped to" with an appropriate link. Links within newly submitted hyperdocuments can cite any passages within prior documents. The back-link facility lets an online reader of a document detect and examine subsequent documents containing links citing that document.

Documents not integrated into an above online and interactive environment (e.g., hard-copy documents and other records otherwise external to the OHS) can be managed by employing the same "catalog system" used for hyperdocument libraries with a back-link service to indicate citations to these "offline" records from hyperdocument (and other) data bases. OHS users can find out what is being said about these "External Document" (XDoc) records in the hyperdocument world as well as access instructions.

A knowledge environment in an OHS includes Shared Files, Throw-Away Email, Journal/Library, and External Documents (XDOC). Documents in each of these four areas can have hyperlinks among themselves as appropriate to the retention level implied by their definition. (Thus citations to Journal items will always be valid while citations to Throw-Away Email are not guaranteed.)

Within a collaborating knowledge worker domain, there will be a population with a range of capability and experience performing an evolving and expanding array of functionality on varied hardware and software devices from an assortment of developers. These workers will have to be able to learn, discuss, and perform similar activities in this heterogeneous, interconnected system.

An formal abstraction of the user interface for the tools within the workshop permits collaboration while allowing differences between commercial offerings. This abstraction in the form of a Command Meta Language describes users' available operations (verbs) on classes of objects (nouns) in grammatical descriptions of tools.

A Command Language Interpreter (CLI) interprets user actions, based upon the contents of the currently attached grammar file, and executes appropriate actions via remote procedure calls to a common application program interface of the "open system environment."

This architectural approach, with its abstraction of user interface issues, is a practical way to support and control the evolving global "workshop vocabulary" effectively integrating distributed groupware services on wide ranging platforms.

Knowledge workers will have a range of preferences for interaction style based on previous experience, hardware device capability, and esthetic desires.

A computer-human interaction "look-and-feel interface" software module based upon the same Command-Language Interpreter (CLI) architecture mentioned above could offer modules for preferred interaction characteristics.

When working interactively, no matter what particular look-and-feel style is being used, a user can have a particular mental model in mind for the significance of every type of command interaction. They can learn from other co-workers who may have vastly differing personal interaction preferences.

Besides relaxing the troublesome need to make people conform to a standard look and feel, this approach has a very positive potential outcome in permitting evolution of interaction styles and expanded functionality while maintaining access to past functionality. So far, the evolution of popular graphical user interfaces has been heavily affected by the "easy to use" dictum. This has served well to facilitate wide acceptance, but it is quite unlikely that the road to truly high performance can effectively be traveled by people who are stuck with vehicular controls designed to be easy to use by a past generation.

As important classes of users develop larger and larger workshop vocabularies, and exercise greater process skills in employing them, they will undoubtedly begin to benefit from significant changes in look and feel. The above approach will provide open opportunity for that important aspect of our evolution toward truly high performance.

Remote distributed workers can view and manipulate the workplace environment of collaborators, as if they are sitting side-by-side, to review, draft, or modify a document, provide coaching or consulting, support meetings, and so on. Control of the application program (residing in the "showing" worker's environment) can be passed around freely among the participants.

A range of tools for teleconferencing, "chatting," and facilitating group decision making may be available in media ranging from text through audio and video. There should be provision for capturing these interactions for later examination and annotation and inclusion in the permanent knowledge workshop Journal.

The OHS must contain the ability to access and comment on data in tools and systems outside of its immediate scope.

For example, a CAD system's data base can have links from annotations/comments associated with a design object that point to relevant specifications, requirements, discussions, etc., in an associated OHS. Hyperdocuments in turn may point to objects within the CAD bases. During later study of some object within the CAD model, the back-link service could inform the CAD worker which hyperdocument passages cited that object.

Objects manipulation tools can be configured into larger applications or modifications of existing application features. These components can be traded as part of an application exchange and can foster the evolution of the system.

Shared authoring, linked commentary, shared files, group indexes, shared-window teleconferencing across applications, workflow ...

Automated capture, indexing and cross-referencing, integrated email, journal/library, intelligence collections; utilities for repository management

Dynamic portrayal, precision browsing, filtering, integrated editor, object-level addressibility, linkability, traceability, annotated index, accommodation for disabled...

Open Hyperdocument Systems represent a clear departure from prevailing information system: