Document preparation systems might be now the most commonly used computer systems, ranging from stand-alone text processing individual machines to highly sophisticated systems running on mainframe computers. All of those systems internally use a more or less formal system for representing documents. Document representation formalisms are very different according to their goals. Some of them define the interface with the printing device, they are oriented towards a precise geometric description of the contents of each page in a document. Others are used internally in systems as a memory representation. Yet others have to be learned by users; they are symbolic languages used to control document processing.

The trouble is that there are today nearly as many representation formalisms as document preparation systems. This makes it nearly impossible, first to interchange documents among heterogeneous systems, second to have standard programming interfaces for developping systems. Standardization organizations and large companies are now trying to establish standards in the field in order to stop proliferation of formalisms and facilitate document interchange.

This paper focuses in the last sections on three document representation formalisms often called 'revisable formats', namely SGML [SGML], ODA [ODA], and Interscript [Ayers & al.], [Joloboff & al.]. In order to better understand what is a revisable format, the paper starts with a look at the evolution of the architecture of document preparation systems.

Document preparation systems have appeared as soon as computer printing devices were able to output typewriter-like quality documents. Although the evolution of printing technology have been the major one, several factors have influenced the architecture of document preparation systems: low cost computing power, distributed systems, and the simple maturation of ideas in the field. The evolution of printing technology has lead to the digital representation of documents ready to be printed, called final form representation. The evolution of software techniques has principally lead to representations capturing the logical structure, the structure that is perceived by the author when the document is revised, i.e. constructed or modified.

SGML stands for Standard Generalized Markup Language. It is essentially a declarative markup language, which has inherited mainly from its ancestor GML. However it includes a lot of new interesting features.

A first difference with its predecessors is that markup is defined rigorously. It is possible from the SGML standard definition to build a general syntactic parser that will not arise ambiguities. According to this rigorous syntax, SGML documents may be processed very much like programs by a compiler. A document may be parsed to build an abstract syntactic tree together with its attributes.

Semantics of that tree may be evaluated by semantic functions according to the attributes values. Thus, SGML can be used for other tasks than formatting ones. Semantics of markup tags and attributes might be used for machine translation, automatic indexing or any other process needing parsing of documents.

A markup sign in SGML is named a tag. Any element which needs to be tagged starts with a start-tag and ends with an end-tag. Any tag is delimited by the characters < and >. A tag is defined by an identifier, which appears first in the start-tag. An end-tag repeats the same identifier preceded by /. Note that all of these mark characters are redefinable for each document.

End tags may also be omitted under conditions specified in the standard. For example, a paragraph will appear as:

A property of SGML is that tags are themselves described trough a formal language: the SGML meta-language, which may be used within SGML documents to dynamically define new symbols. Syntax to introduce a meta-language construct simply follows < by !.

The SGML meta language allows for the definition of complex constructs, named elements. An element declaration defines of a class of objects, i.e. an element type. Subsequent objects in the document may be tagged with the element name. Elements may have a hierarchical structure, and each element in the hierarchy may have its own attributes. Element types may be used either to facilitate the interactive creation of documents, to control the validity of a document structure, or to associate a layout style to a particular document type.

For example, one might define a document type for a conference paper as follows:

This document type declaration specifies that a paper has a title, an abstract, and a body. The title consists of characters, the abstract is one paragraph and the body one or more paragraphs. A paper has a language attribute to indicate in which language it is written. More complex combina-tions can be designed to define document types that have some commonality.

The facility to define new elements brings troubles when laying out those elements, because the formating system then does not know how to format such constructs. SGML provide two ways for handling that situation. The first one is naturally to add to the SGML system a procedure to take care of the new tags. This requires a good knowledge of the system and prohibits further interchange of documents with such tags to systems which do not have this procedure. The second one is to use a LINK tag. A LINK tag says to the system that a construct should be handled as another one, presumably known from the system, with possible attributes modifications. For example, if one says <!LINK abstract paragaph indent=5>, it means an abstract has to be formatted like a paragraph, however using a different indentation value.

It is often required in a document to be able to refer to other parts of the document. Some binding mechanism is needed in the formalism to attach a value to some identifier, which resembles to progamming language variables. Binding is achieved in SGML trhough entity declaration and entity references. An entity (a value, a character string or any valid SGML constituent) may be bound to a name by the notation <!ENTITY name entity value>. From now on, that entity may later be referenced by its name either to set an attribute value, or to be included into the running text. Entities also provide means to handle non character data. An external entity is declared <!ENTITY name SYSTEM system information>. Then it is known that this entity is not in the document stream. The processing system will find in the system information how to access that content.

If the document is to be interchanged among different computers with different operating systems, this system information is specific to each system. SGML provides an IGNORE/INCLUDE mechanism for that purpose. Information relative to some particular system, let say osx, has to be encoded within the magic declaration <![osx;[<?commands for osx system>]]>. Then a user only needs to turn a switch at the beginning of the document to the local system for the document to be processed correctly.

We mentioned previously Interscript is a representation formalism from a new generation. Interscript, which was originally designed at Xerox PARC, starts from the idea that a document representation should be suited to be processed by computers, not by the humans who manipulate documents.

Such things as traversing trees, evaluating expressions, searching values of variables within contexts are among what computers can easily do. Thus, a fundamental notion in Interscript is to rely on a formal language to describe document constructs, not only a document logical structure, but all formal constructs that could be necessary into a document representation. These abstract constructs may be data structures such as paragraphs, fonts, geometric shapes, but may also represent computations, like setting a context or evaluating expressions within some context.

The Intescript approach is very much like the approach used in software engineering: general programming languages are used by people to build abstract constructs and procedures to solve their particular problem. A document representation problem should be solved using the a document representation language. The Interscript base language is simple (around 25 grammar rules) and powerful. Its semantics are well defined but its syntax rapidly leads to document that cannot be managed by humans.

A document encoded in the Interscript base language is called a script. A script is very much like a program. The processing paradigm (figure 2) is that a script should be first internalized by a system. Internalizing a script implies execution of computations, which are dictated only by Intercript base language semantics, and result in the construction of another representation available for the client process. This simply means that one translates a standard disk representation into a non standard memory representation, while achieving computations.

Computations are necessary in the internalizing process because the base language includes a binding mechanism and the evaluation of expressions within hierarchical contexts. For example, evaluating the expression:

We will not in this paper enters into the details of the internalizing process, which looks like the evaluation of any interpreted programming language, to focus on the central concepts of node and tag.

A script is a hierarchy of nodes. Nodes have contents and tags. The authors have compared an Interscript node to a bottle of wine. The contents of the bottle is qualified by several tags on the bottle: a price tag, a product number tag. Interscript tags similarly qualifies the node contents. To some extent an Interscript tag is similar to an sgml tag, it introduces an element, it has attributes, it denotes structural properties of the contents.

The difference is that, first a Interscript node may have simultaneous tags, second attributes of a tag may be bound to an expression which must be evaluated. For example, a figure caption could be affixed with both a CAPTION and a PARAGRAPH tag. The paragraph tag says that the caption text has to be laid out as a parapragph, the caption tag restricts the placement of that paragraph relatively to the figure picture. The leftmargin attribute of the paragraph might be set to be equal to the margin of some object X. Then the node hierarchy is searched for that X.

Interscript syntax denotes nodes between curly braces. Tags are character strings followed by a dollar sign. A typical node is:

Office Document Architecture is a standard elaborated within ISO to introduce a standard in the data structures used for the digital representation of documents. The most particular property of ODA is that it does not fit in the traditional architecture schema: ODA defines simultaneously the logical structure and the layout structure of a document, i.e. it is both a logical and a page description format.

The argument in favour of that unique representation seems to be that most editing systems have to manage both structures. The standard says (part 2 - page 75)

This issue is discussed in the conclusion. This section only tries to present the ODA formalism. Figure 5 shows the main constituents of a document. It has six parts, a document profile, a document style, a generic and a specific logical structure, a generic and a specific layout structure.

A document may actually contain only one of the structure. This is indicated when transmitting in the document profile. The document profile also contain data related to the whole document: creation date, last alteration date, originators, status, etc.

Generic and specific are to be interpreted respectively as class and instance. For example a generic structure named conference paper will describe the general structure and properties of a conference paper, as shown in the SGML section. A particular instance of a conference paper will be described by its specific structure. Attributes defined in the generic will be valued in the specific structure, possibly to a default value specified in the generic part. The specific structure should be consistent with the generic one, and will probaly inherit properties from the generic structure. Specific logical and layout structure are trees whose leaf nodes are named basic objects and other nodes composite objects. Any node may carry attributes.

The specific logical structure expresses the structure of the document in, e.g. paragraphs, chapters, titles, etc. The specific layout structure is a tree of page sets (a set of pages identified as a single entity), pages, frames and blocks. Blocks and frames are rectangular areas located within frames and pages.

Blocks and basic logical objects both refer to the document content. This content is divided in content portions. A content portion is governed by a content architecture, which basically defines the content type (characters, images, graphics) and its encoding mechanism.

The logical and layout structure are clearly not independent, they refer to the same document content and they may have reciprocal pointers.

Figure 6 (reproduced from the standard) shows the coexistence of the two structures implies particular constraints. A paragraph which spans over two pages has to be split into two content portions.

Styles simply are a named set of attributes, which can be referenced from other components in the document. They divide in layout style and presentation style. A presentation style is attached to a basic object and depends upon the nature of that objects. For characters, it would indicate font information, for images it would probably indicate colors or half-toning. Layout style defines global style information. It can be referenced only from logical objects.

The standard is somewhat fuzzy about generic structures. There is no clause devoted to the description of generic structures, while there is one for each specific structure. It says that object class description are used by the editing process to construct a specific logical structure but it does not say much about such descriptions. Part 3 of the standard, which describes the layout process, indicates how the generic layout structure should be used, hence give a clearer idea.

The generic layout structure contains common content portions, for example logos or headings that should be used in many places in the document. It also serves as a guide for the layout process.

We have focused in this paper on three representation formalisms considered as revisable form representations, namely SGML, ODA and Interscript. On these three formalisms, SGML and ODA have reached the status of ISO draft proposal, which means they will become definitive standards with very little modifications.

SGML results from experience accumulated since more than ten years by current practice in the field of markup languages. The standard has a precise definition, which makes it possible to rigorously parse a document. Document markup tags may induce hierarchical structures expressing the logical content of a document. A simple binding system among entities has been introduced, which allows for cross referencing among entities.

Knowing that SGML has been running on many machines, that high quality text books have been produced through an SGML system, A vendor commercializing a markup document system would probably better take SGML rather than inventing a new formalism.

ODA did not follow the same standardization process as SGML. ODA is an attempt by an ISO working group, consisting mostly of text processing system vendors representatives, to define a standard before there are hundred of representation formalisms around the world that would not be compatible. Hence there is no current practice of ODA and it is only expected that most of new systems will use ODA. However there are a few objections to actually using ODA.

The choice of the two coexisting layout and logical structures. might lead to implementation problems. The content portions which have to be split to satisfy layout constraints will have to be recollected when the layout is modified.

Now that most printing device vendors have upgraded their machines to have a procedural page description language, the design of the layout structure in terms of frames and blocks looks old fashioned and contradictory with the fact that ODA claims to be a standard for future systems.

One might fear too with ODA that vendors will actually offer ``ODA subsets''. Particularly it is the case SGML can be considered as such a subset. The standard explicitly states, probabaly for reasons of compatibility among ISO standards, that an SGML document may be transmitted within an ODA document (part5-page 4):

A vendor may actually sell an SGML system as an ODA subset system. If each vendor offers a subset of ODA, it might be the case that all of those systems will be actually incompatible, which is not desirable for an interchange standard. This argument is naturally true for all standards, but ODA design makes it easier to have closed subsets.

For example, it is possible to design an ODA editing system that would not take into consideration all of the layout part and restrict to the logical structures and styles. This editing system will output only documents with logical structures and styles. These documents may be interchanged using the ODA format.

It is possible too, in terms of delimiting an ODA subset, to design a simple word processing machine that would use no logical structure at all to produce office documents with only a layout structure. But both of those ODA systems will not be able to interchange a single document.

Morover, it seems from ODA complexity that a complete ODA system can hardly be implemented on a small word processing workstation. Implementors of these relatively small workstations, who are willing to manage documents with both logical and layout structure, will probably have to define a subset in order to maintain satisfying performance.

Though SGML has been designed so that human beings may enter markup tags into a document, it might well be used as an internal representation for an editor that would not appear to the user as a markup system. Then the structuring possibilities offered by SGML may be used by the implementors to represent complex internal structures, producing equivalent facilities to those of ODA. Documents produced by such an editor could hardly be revised by humans from a standard terminal, but they could still be output with the high quality of an SGML formatting system. Thus a vendor who is willing to implement a document preparation system has to choose among two international standards.

Interscript is not an international standard and it seems it will not become. The reason might be that Interscript design is too much a departure from their existing formalisms to be accepted by most vendors, who are mostly interested in standards. Remember that bitmap displays were developed at Xerox PARC in 1975. In 1985, still very few vendors offer text processing systems with a bitmap display and a pointing device. Interscript was also born at Xerox PARC in 1983 [Ayers & al], as a result of several years of experience with powerful text processing systems running on bitmap displays...

Yet Interscript will not be a standard in the eighties, it has introduced two important ideas, the notions of base language associated with an internalization process, and descriptive layout, which should be retained by people who are participating to the design of a new generation of document preparation systems.

Interscript proves that a base language can be defined which encompasses all abstractions that can be found in the document preparation world. It can describe as well a document logical structure, properties and structure of various kind of entities (font, paragraph, etc), and functional symbolisms like the pouring operation.

A base language considerably simplifies the software development of systems once it is implemented, but all over it gives cleanness to the systems and clarity in concepts. The Interscript base language is certainly not perfect. It can be improved and it might be actually too powerful for its goals.

Similarly, the idea of a layout process formally described and specified by abstract constructs, can be expressed in other terms than the particular Interscript pouring process. But both concepts have opened a direction for present research in the field.