[_CD6_]<interscript>1.0>Interdoc-1.4.bravo!1

Page Numbers: Yes X: 530 Y: 10.5" First Page: 6
Columns: 1 Edge Margin: .6" Between Columns: .4"
Margins: Top: 1.3" Bottom: 1" Binding: -5
Line Numbers: No Modulus: 5 Page-relative
Odd Heading:

The present document focusses almost exclusively on Layers 0 and 1, although some of the examples illustrate properties and attributes likely to be defined in Layer 2.

Transcription fidelity requires that any document prepared by any editor can be transcribed as an Interdoc script that will be rendered back into the editor’s private representation without loss of information. Ease of rendition requires that the Interdoc base language contain only relatively few (and simple) constructs. We resolve this apparent paradox by including within the base language a simple, yet powerful, mechanism for abbreviation and extension.

An Interdoc script may be considered to be a "program" that could be "compiled" to render the document in the private representation of a particular editor, ready for further editing. The Interdoc language has been designed so that renditions into typical editors’ representations can be performed in a single pass over the script by maintaining a few simple data structures.

Most editors deal with both the content of a document (or piece of a document), and its form. The former is thought of as "what" is in the document, the latter as "how" it is to be viewed. (E.g., "ABC" has a sequence of character codes as its contents; its format may include font and position information.) Interdoc maintains this distinction.

Another useful distinction is between the value and the structure of either form or content within a document. When viewing a document, only the value is of concern, but the structure that leads to that value may be essential to convenient editing. An example of structure in content is the grouping of text into paragraphs; in form, associating a named "style" with a paragraph.

Content: Text and graphics are common special cases. Interdoc’s treatment of these has been largely modelled on that of Interpress. Other kinds of content may be represented by structures built from character strings, numbers, Booleans, and identifiers.

Form: Interdoc provides for open-ended sets of properties and attributes. Properties are associated with content by means of tags. Attributes are name-value pairs that apply throughout a scope, and are placed in the environment by means of bindings. Contents are not always present to be simply displayed as text. The way the contents of a document are to be "viewed" is determined by its properties; Interdoc makes it straightforward to determine what these properties are without having to understand them.

Structure: Most editors structure the content of a document somehow—into words, sentences, paragraphs, sections, chapters; or lines, pages, signatures; or . . . . This assists in obtaining private efficiency, but, more importantly, provides a conceptual structure for the user.

Full transcription fidelity requires that the Interdoc language be adequate to record any structure that is maintained by any editor for either form or content. Of course, some editors provide many different structures. A general structure, of which all the editors we know use special cases, is the labelled directed graph. Interdoc provides this structure, without restricting the purposes for which it may be used. There are also two specializations of general graphs that occur so frequently that Interdoc treats them specially:

Sequences: The most important, and most frequent, relationship between values is logical adjacency (sequentiality), which is represented by simply putting them one after another in the script.

Ordered trees: Most editors that structure contents have a "dominant" hierarchy that maps well into trees whose arcs are implicitly labelled by order. (Different editors use these trees to represent different hierarchies). Interdoc provides a simple linear notation for such trees, delimiting node values by braces ("{" and "}"). If an editor maintains multiple hierarchies, the dominant one is the one transcribed into the tree structure and used to control the inheritance of attributes.

Content structure beyond that contained in the dominant hierarchy is represented by explicit links in the script; any node may be labelled as the source and/or the target of any number of links. A link whose target is a single node uniquely identifies that node; links with multiple targets may be used to represent sets of nodes.

Typical structures recorded for form are expressions (indicating intended relations among attribute values) and sharing (representable by indirection). Interdoc allows expressions to be composed of literals, identifiers, operators, and function applications, and permits the use of identifiers to represent expressions.

We expect definitions to be used by sophisticated editors for such things as styles. Some scripts will come with a prefix containing non-standard property and attribute definitions that are global to the document. There may be standard libraries containing definitions that allow complex documents to be edited in terms of properties and attributes understood by simpler editors.

Null denotes the "empty" environment, containing bindings for no attributes. The (implicit) outermost environment binds each identifier id to the corresponding universal name ID (written with all capital letters).

Each piece of content in a document has its own environment. Editors will use relevant attributes from that environment to control its form. Attributes may also be used in scripts for two purposes:

abbreviation: an identifier may be bound to a quoted expression; within the scope of the binding, the use of the identifier is equivalent to the use of the full expression;

indirection: reference through an identifier permits information (such as styles) to be defined in one place and shared throughout its scope; this is an example of structure (which must be preserved) in the form of a document.

The dominant hierarchy of a document is represented by grouping its pieces within nodes, which are the most obvious form of content structuring. They also control the scope of bindings.

The environment of a node is initially inherited from its containing node (except for the outermost node, which inherits it from the editor), and may be modified by bindings. A binding takes effect at the point where it appears, and its scope extends to the end of the innermost node containing it, with two exceptions:

any binding except a definition may be superseded by a (textually) later binding (if the later binding is in a nested node, the outer binding’s scope will resume at the end of the inner node), and

a persistent binding may only occur in the scope of a var binding for that attribute and extends as far as the var binding would have (so the binding may persist beyond the end of the node that contains it).

Attributes are inherited only via environments following the dominant structure. Thus the choice of a dominant structure to represent scripts from a particular editor will be strongly influenced by expectations about inheritance.

Attributes are "relevant" to a node if they are assumed by any of its tags. In general, a node’s environment will also contain bindings for many "latent" attributes that are either relevant to its ancestors (and inherited by default) or are potentially relevant to its descendants.

The interior of each node is implicitly prefixed by Sub, which will generally be bound in the containing environment to a quoted expression performing some bindings, applying some labels, and/or supplying some repeated content.

Expressions involving the four infix ops (+, −, *, /) are evaluated right-to-left (a la APL); since we expect expressions to be short, we have not imposed precedence rules.

Parentheses are used to delimit vector values. Square brackets are used to delimit the argument list of an operator application and to denote environment constructors, which behave much like records.

This is consistent with our principles of using balanced brackets for compound constructions and avoiding syntactically reserved words; the true part and false part may each contain an arbitrary number of items (including none).

A tag is written as a universal name followed by ‘‘$’’. Tags label the nodes that contain them with their associated properties and also indirectly reference the component of the environment with the same name. Properties are either present in a node or absent, whereas attributes have values that apply throughout a scope.

Layer 2 of the standard will be primarily concerned with the definition of a small set of standard properties that are expected to be shared among all conforming editors. For each standard property, it will describe

the assumptions it implies about the contents (values that must/may be present and their intended intepretation, invariant relations that are to be maintained, etc.),

A label L! on a node makes that node a target of the link L (and its prefixes); a label L@ makes it a source. The "main" identifier of a link must be introduced (using id@!) at the root of a subtree containing all its sources and targets, and textually preceding them. Each link represents a set of directed arcs, one from each of its sources to each of its targets. Multiple target labels make a node the target of multiple links. Labels provide a very general mechanism for recording structure, such as cross-references, not captured by linear order or the dominant hierarchy.

The Interdoc standard applies to interchange among editors with widely varying capabilities. Just as the Interpress standard did for printers, it will be important to define some structure to the space of possibilities. Dimensions in which we foresee reasonable variations in fidelity of rendition are:

The private representations of low-capability editors are not generally adequate to provide a full-fidelity rendition of every Interdoc script that results from transcribing a document prepared by a high-capability editor. Thus, when rendering a script, some information may be lost. The Interdoc language has been designed to simplify value-faithful rendition, even if structure is lost, and content-faithful rendition, even if form is lost—or the conversion of form to additional content to allow it to be examined (and perhaps even edited) by a low capability-editor. The standard provides some simple conditions under which a low-capability editor can safely modify parts of a document that it understands fully, without thereby destroying the value or structure of parts that it is not prepared to deal with.

As each structure is recognized in the script, represent the corresponding structure in the editor’s representation, if possible; if not, use the semantics of Interdoc to compute the value to be rendered.

Transfer the values of all attributes relevant to each piece of content from the current environment to the editor’s representation, if possible; if not, apply an invertible function to convert the attribute-value binding into additional content.

Determine the properties of each node from its tags; this list will be complete at the end of the node. A node is viewable if any of its tags denotes a property in the set of those the editor is prepared to display; it is understood if they are all in the set of those the editor is prepared to edit.

Record the sources and targets of all links; for any link, these lists will be complete at the end of the node in which its main identifier was introduced. Translate each link to the corresponding editor structure, according to the properties of the node that introduces it.