








We are in the habit of classifying applications according to the kind of information that they handle. Consequently, we find management applications to manipulate management information and editorial applications to handle text information. Of course, there are other types of applications, but we will restrict comment only to the interactions between management applications and editorial applications.
Within a management system, the essential characteristic of the information handled is that it is very structured and very rigid. To define its structure:
Concurrently, we define access methods to the data.
Control over these information systems was acquired a long time ago. There are few domains of human activity that these kinds of information systems have not covered.
In the case of editorial applications, the nature of the information is quite different. Whereas the concept of sequence plays a subordinate role in the case of management information, for text information it acquires immense importance. For management information the links between the objects are identified at the conception of the system. Whereas, for the text information different forms of relations can be established at any given moment.
The tools available to treat the problems linked to information handling are listed in the following table:
Management Information Text
Information
Research SQL No standard
mechanisms available
Model Relational model SGML
Access tools ODBC (Open Database No standard
Connectivity) available
Generally speaking, management information is information that talks about something. In this context a marker showing a modification to a text is management information, even if it appears inside the text. In fact this information is a new form of information. It does not correspond to traditional management information, neither is it text information because it does not belong to the text of the document. This information will be called text management information.
The analysis we present is particularly relevant to situations in which the following elements are present.
Behind these organizational aspects, we are assuming that the information handled has an SGML representation. The handling can be the result of tools or of operators.
We shall present two kinds of text management information that can be found in a document.
In these two examples, the location of information is important. In one case we shall try to record the work of a proofreader, and in the other we shall analyse the presence of information produced automatically by a tool.
Validation of electronic (SGML) documents can sometimes happen in a context in which it is necessary, from an organizational point of view, to keep track of all the interventions by the proofreader.
For different reasons, it could be necessary to store:
In this case, the error and its correction make up one management object. This object has two textual contents. We shall analyse how to keep track of this information in an SGML context.
One possible implementation is to use marked sections, i.e., IGNORE or INCLUDE. According to the value of a parameter entity, we can include or ignore either the erroneous text part or the corrected text part. This solution allows the cohabitation of information (4) and (5). It also allows us to keep track of embedded mistakes and corrections. However, this solution does not allow us to keep management attributes such as (1), (2), (3), (6), and (7), any more than it made both (4) and (5) available at the same time.
Another implementation consists in using a concurrent DTD, specifically used to indicate the start and the end of the correction, i.e., the scope of the correction. In this case the erroneous text (4) can be stored inside an ENTITY attribute. The other management information (1), (2), (3), (6), and (7) can be kept as attributes, whereas the correction (5) is placed between the error's start and end-tags. These elements are defined as EMPTY, and ID and IDREF attributes are used to establish the connection.
A third implementation consists of storing the error as a separate SGML instance and keeping the link to the error within the corrected SGML instance. This separate document should conform to a specific DTD and use another concrete syntax to redefine the STAGO, TAGC, and ETAGO delimiters.
As can be seen, different implementations are available in SGML. Others can be envisaged. The choice between these implementations depends upon:
As far as we are concerned, we think that a concurrent DTD is very beneficial insofar as it offers:
Contact Robin Cover with corrections and updates, or to submit contributions to the ISUG online document database.
