About SGMLISUG PubsBookstoreChaptersDeveloping SGMLJoin ISUG

Using Management Information Within an Editorial Context

Management information and Text information

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.

Context

The analysis we present is particularly relevant to situations in which the following elements are present.

  1. The target of the system is to create a document or a set of documents. In the latter case, relations between these documents is of importance. The creation of this document(s) requires the participation of different operators who work in a standalone manner. Few means are available that allow them to communicate. This situation can occur when the operators do not know each other.
  2. Even if the work is done in a standalone manner, the information contained in the document presents a high degree of homogeneity. As a result of this homogeneity, the operators at the end of the work-flow have a real need to know which specific choices were made upstream in the production cycle.

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.

Integration requirements

Examples of text management information

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.

A proofreader's work

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:

[Next Section]   [Previous Section]

Contact Robin Cover with corrections and updates, or to submit contributions to the ISUG online document database.

ISUG 
logo
Copyright © 1998 International SGML Users' Group