extended Structured Query Language (xSQL)		Table of contents		Indexes		XML Message Switching

The Use of SGML for a Police Information System

Jacques Kasprzak

Software Engineer

SGML Technologies Group 56 Rue Glesener,
Luxembourg L-1630 Luxembourg
Phone: +352 29 21 22
Fax: +352 29 21 20
Email: jka@isea.lu Web: www.sgmltech.com

Biographical notice:

Jacques Kasprzak is a software engineer employed by ISEA in Luxembourg, a member of the SGML Technologies Group. He specializes in the design of information systems. A graduate of computer science, he worked in the Institut de l'Information Scientifique et Technique (INIST), part of the Centre National de Recherche Scientifique (France), to administer the information system and databases. He may be contacted at jka@isea.lu.

ABSTRACT:

Browser-based application
Client/Server

In this paper the objectives of the INGEPOL project are explained. The architecture of the system is then described, this being governed by a number of constraints. Associated problems are highlighted. The role of SGML (Standard Generalized Markup Language) and advantages offered by such an approach are presented within the framework of complex projects.

Introduction

Objectives

INGEPOL is a project being carried out for the Gendarmerie Luxembourgeoise. The aim of the project is to put into place an information system automating the creation, administration, and exploitation of the centralized database. This is for the Gendarmerie (the state police force) and the local police to serve their needs regarding the prevention of crime, searches, investigations carried out, and the prosecution of offenders.

The principal objectives of the INGEPOL project are the following:

to increase the availability of police officers in the field by reducing the amount of administrative work

From information that is input in a standardized manner by the squads and the police stations, the system produces the documents required for case management and ensures their distribution. As far as the local units are concerned, police officers will be relieved of work involving statistics and also combination of data (which is performed automatically at the central level);

to increase the effectiveness of controls of persons and objects by accessing the desired information in a transparent and fast manner.

The central information system permits all police officers of the FO

Note:

^{Forces de l'Ordre, grouping the local police and the state police force.}

to access police information in accordance with their profile (on the basis of simple requests);

to create optimum conditions for investigation work and increase the chances of solving criminal cases.

The information system provides the FO with automated methods of research and comparison of information that allow the speeding up and facilitation of a judicial enquiry;

to make crime prevention more effective

The availability of statistical data periodically and geographical exploitation of criminal information permit an appreciation of variations in delinquency and, as a result, can draw the attention of the FO to the increase in certain types of crime or criminal activities.

So there is immediate sharing of information within local units, and centralization of that local information, integrating information stemming from other systems at the central site. This improves effectiveness of police work in the field, where there is the possibility of querying a complex system of data compiled from many sources in a manner that is transparent to the end-user.

Functions of the INGEPOL System

The INGEPOL system has several functions, of which the management of police information could be considered the most fundamental. This includes not only the management of cases but also managing descriptions of persons and objects be they firearms, jewellery, driving licences, stolen vehicles, banknotes, drugs, or objets d'art, for example.

System exploitation is another important function, one aspect of which is the control of persons and objects (operational control). There is also the consultation of persons including interviews, and information on objects and of cases within the framework relating to a judicial enquiry.

Statistics are exploited and combinations of data play a part within the framework of crime prevention.

The information system has to be administered, which subsumes validation of the information input. Then there is correctness, with regard to consistency of data and respect of legal dispositions.

Distribution of the information and exchanges with distributed systems are important functions where the security of information must be taken into account, including confidentiality, availability, and integrity.

Finally there is the management of users and access rights to information.

The INGEPOL Project

The INGEPOL project consists of several phases, only one of which is the subject of this paper. The phase in question is concerned with the management of the descriptions of persons and objects and their control at an operational level.

Global Architecture

The aim of the INGEPOL system as stated is to communicate with distant partner systems and to centralize and spread information to the different units (squads and police stations). This implies an architecture that hinges on the three-tier client/server notion allowing, on the one hand, better allocation of tasks that fall to each of the parties involved and, on the other hand, improvement of maintenance and even the integration of new components.

Making up the system are:

the client workstations;
a group of servers composed of specialized services whose purpose is to process management rules (security, validation, dispatching, audit, etc);
heterogeneous information systems which give rise to the various problems of accessing resources.

Communication between the various tiers is achieved through XML XML (Extensible Markup Language) messages structured in three layers which are dedicated to:

security,
Note:
^{Encoding and deciphering data transported on the network.}
allowing encoding and deciphering of data transported on the system;
the logic of the message, by specifying the server addressed, the family of messages, the expected processing method, the objects concerned, etc;
the information transmitted, which may be reformatted according to the target systems.

An XML parser processes the message by breaking it down into atomic elements that are likely to be interpreted by a specialized system service.

Problems/Constraints

A global study of the project enabled identification of a set of characteristics and allowed the adoption of an SGML-oriented development strategy.

In order to appreciate the SGML approach to the project, technical considerations had to be taken into account in addition to the initial constraints:

the system must be operational on various target systems

PC - Windows NT,

VT100 - DPX2,

mobile terminals on-board service vehicles (Motorola);
the number of screens that make up the man/machine interface is important (250);
the number of messages to be taken into account is important (800);
the structures of the external databases that are part of the system are different;
the requests issuing from the end-user can generate additional processing actions which are specific to the target systems.

Under those circumstances it was difficult to move towards target-specific developments and the project required a considerable amount of time to be spent on development, testing, and integration.

Why SGML?

Several considerations led to the adoption of an SGML strategy. These included the need to have an standard interface; standardization (as far as possible) of the process for the generation of services for the updating of a database; the actual generation of services for the updating of a database; and the description of the structure of the information systems in a simple and unique way.

Given the constraints previously listed as a starting point, a first report was produced. This highlighted many points:

the structures of the different databases are known and conversion tables allow access to other systems from the central INGEPOL system;
it is possible, owing to the design of the INGEPOL database, to generate a set of primitives that allow them to be checked, added to, and updated;

messages are numerous, but in general they all contain database objects, the logical layer of the message indicating the nature of the transaction (creation or modification of a description), the processing expected, the object(s) concerned, and the reference base;

the look-and-feel must be consistent and whatever the target system it is inconceivable to imagine a specific development for each of the targets, therefore the user interface must be described in a unique way;

the screens are simple and typical for the objects handled;
management rules are of the referential integrity control type;
management of screen flows is classical, navigation being determined following a user-triggered event.

Added to this is the necessity for obtaining a uniform and unique interface, of integrating validation and navigation rules within the specification that describes the interface, and of standardizing as far as possible the processes for generation of services that update the INGEPOL database. These requirements led to the design of an SGML development strategy that splits the INGEPOL system into five sub-systems:

generation of database services;
specification of data/message groups;
a server;
specification of dialogues;
a client terminal.

After these sub-systems have been presented, the advantages of this strategy within the INGEPOL project will be discussed further.

The INGEPOL Sub-systems

Generation of Database Services

Objective

The objective here is to generate automatically a set of PRO*C and C++ services that allow the server to manipulate the database entities by limiting the knowledge of the structure of the database to the methods and the classes generated. The result of this generation is the creation of all the data groups that occur in the messages.

Principle

Modelling tools allow the generation of an SQL database creation file from a physical model. With this file, and other specific files that describe the screens to be used, it is possible to generate a set of services that allow interaction with the database.

The principle is as follows and requires two phases. Firstly, a DTD

Note:

^{Document Type Definition.}

that allows the validation of the structure of the SQL file and the LKD

Note:

^{Link Type Definition.}

that integrates an extended application language, generates an instance for each identified table or screen, and describes, in SGML, the object processed. The grammar associated with the instance describes the data group to be taken into account, and indicates whether this group is optional, mandatory, or whether it occurs at all. It also describes for each of the groups the fields that are associated with it, their type

Note:

^{String, integer, date, boolean, or reference to a nomenclature.}

and data format

Note:

^{The format for the dates can be YYYY, MM/YYYY, DD/MM/YYYYY; in the other cases the length must be indicated.}

as well as a formal description. In short, each table becomes a data group whose name is the name of the table, and each item of the group is one of the columns of the table. The conversion of the different types of data is carried out at that level so as to allow a programming language-oriented interpretation.

Secondly, from each instance previously generated, and based upon skeleton files that describe each of the actions to be taken on the database, a specifically developed parser generates a set of methods (PRO*C, C++) allowing actions such as SELECT, INSERT, UPDATE, and DELETE as well as the C++ classes (*.h and *.cpp) associated with the objects processed.

The generation of data structures and of associated primitives relieves the developer of the tedious task of writing database access routines.

Specification of the Data/Message Groups

Objective

From the data groups used to build the messages that are exchanged between the client terminals and the servers, the objective is to generate

Note:

^{This principle means that the components generated are stable and, by way of a bonus development work easier, thereby reducing development time.}

automatically C++ and Python

Note:

^{Python is a high-level programming language which is object-oriented, belongs to the public domain, and is used in the application to introduce portions of code into the instance.}

structures that can be used directly.

Definition

A message specification is an instance that contains the complete description of all the data groups that can be processed in the messages exchanged between the client and the server. The specification primarily consists of completing the message instances generated previously,

Note:

^{See Generation of Database Services, above.}

by adapting the field descriptions to the client terminal, and by integrating portions of validation codes.

Initial work consisted of defining message instances that reflect the different structures of the databases concerned. This definition allowed the generation of a set of services dedicated to actions such as inserting, selecting, deleting, and updating the databases while respecting the validation rules inserted in the instance. Those same instances are used to define screen layouts by allowing database fields to be mapped to the screen layout.

There are different categories of messages:

interrogation of request - these messages contain sets of search criteria that allow the selection of objects in the various databases that make up the system;
occurrence response - these messages contain elements that allow the indication of the number of occurrences in the database(s) among the objects selected;

list response - these messages contain the characteristic elements of the objects selected, list responses allowing the selection of a precise object and its associated components (for example description, or description documents);

response given - these messages contain all the elements of the object selected, its description, and its components;
data - these messages contain all the elements of the object to be integrated
Note:
^{Create, modify, or delete.}
into the database, its description, and its components.

An example of a message containing a complete object and its description could be:

identification group of the message;
object group (for example firearm);
description group

0 orn insurance groups,

0 orn image groups,

...,
0 orn groups relating to the descriptions;
for each description group, a group of description documents.

All the messages carried across between a client terminal and the server are structured in XML. The message therefore consists of a chain of previously defined groups, whose elements are the name of the group and whose attributes are the names of the fields of the group. A group of messages can obviously contain other groups. The message is generated either at the client level when sending a request, or at the server level when sending a reply.

The messages completely define the client/server communication protocol.

Principle

A DTD allows validation of the structure of the message instance. The LKD that integrates an extended application language generates two things for each data group:

a Python code file that represents the corresponding data structure - this file will be used by the client terminal for operations related to the messages;
the set of C++ classes and the header (.h) files to be integrated into the server on the basis of skeleton files that describe the syntax of the classes.

The introduction of a VALID tag at group level allows the integration of Python code that is in charge of the validation rules. These rules check the presence of data and the consistency not only of data in a group but also of data from one group in relation to another. It is possible, for instance, to check whether the fraud group was input by the user when he indicated a national fraud number at object group level. These controls occur on the client terminal when a message is generated. Other controls are described in the dialogue instance; more specifically they check whether the actions set in motion by the user are justified.

Server

Objective

It is the server's role to handle incoming messages, to process them appropriately by addressing the necessary service(s), and to send back a message containing the answer awaited by the sending client terminal.

Implementation

Implementation of the server is based on a transactional monitor,

Note:

^TUXEDO.

organized in servers. Each server is composed of a set of services. In the INGEPOL project there are several servers that are dedicated to precise functions, for example a server that manages descriptions and objects, and a server that manages the nomenclatures used.

Because the INGEPOL server can communicate with other distant information systems, it is possible to integrate dedicated servers that consist of specific services in charge of establishing the interface

Note:

^{The interface consists of converting data into a format that can be recognized by the distant system, of executing the process desired, and, after conversion, of transferring the information received to the INGEPOL system.}

between the INGEPOL system and the partner system. Adding another information system then consists of creating a corresponding server.

Principle

In short, the server must provide the following functionality:

receive the message and identify the transmitter;
decipher the message;

dispatch the message to the specialized service that is in charge of carrying out the necessary operations according to the process requested (read or create a new object description, etc), and of the information system(s) chosen;

consolidate the return message with information received from the information system(s);
encode the message;
dispatch the message to the sending client terminal.

At the server level, the XML message is regarded as a chain of characters that a specialized parser splits into a data group, thus allowing the supply of the C++ structures derived from the classes previously generated. A set of methods, generated or developed, allows the appropriate server(s) to be activated, depending on the nature of the message and the data groups present.

Specification of the Dialogue

Objective

The objective of the dialogue specification is the generation of a set of files that represent the user interface and that can be interpreted by the client terminal of the target system (Windows NT stations or VT100 screens), where this is dependent on the different targets identified.

Definition

The description in this paper is limited to the generation principle for the Windows terminals, and a brief comparison is made with what can be generated on a VT100 workstation. It is obvious that the specification of dialogues

Note:

^{The term used henceforth is dialogue instance (singular) notwithstanding the fact that there are several instances that describe the application.}

implemented for the project is unique whatever the target systems. Nonetheless, all the modules required for generating the user interface are specific according to the desired target.

A dialogue instance allows the management of screen flows, dynamic management of drop-down menus, the setting of event-driven actions, and inter-area integrity controls.

Such an instance is characterized by a grammar that allows for a set of dialogues

Note:

^{The name of the dialogue is the name of the HTML page or the VT100 screen that will be used following an action by the user.}

composed of one or more dialogue boxes.

A dialogue box can be either a list or a simple screen. Each dialogue box is associated with the name of a message data group that allows mapping of the message data on the HTML page or the VT100 screen.

A dialogue box consists of a set of data or a data group. The type and format of the field are deduced from the corresponding group of message data.
Each dialogue box can be associated with buttons or drop-down menus that are dedicated to event management.
Specific tags allow triggering of precise actions when an HTML page or a VT100 screen is loaded.
Specific tags allow dynamic configuration of the screen depending on the context.

All these functions are possible by integrating Python code sequences into the dedicated tags.

As far as the buttons, drop-down menus, or specific tags are concerned, the associated Python code is simple and allows manipulation of data groups,

Note:

^{Creation, deletion, or updating.}

navigation between the dialogue boxes, primary controls

Note:

^{Profile control depends on the officer connected, checking that an item has been selected in a list, etc.}

that could not be specified at message level, sending and receiving messages by means of elementary macro-instructions.

Note:

^{The macro-instructions are defined in the modules integrated into the client workstation.}

The designer of the interface merely describes the management of screen flows and the events to be taken into account, without having to worry about the technical aspect of the client workstation modules.

This approach is similar to the definition of powerful configuration and encoding languages that are directly accessible to the experienced user rather than to an experienced programmer.

Note:

^{Yves Marcoux, Technologie SGML 1996, Ch�teau Laurier in Ottawa, 27 March 1996.}

Principle

From message instances and dialogue instances generation-parsers allow, depending on the target aimed at (PC, VT100, Motorola), the implementation of standardized and stablized structures in C/C++, Python, and HTML, that are likely to be interpreted by a unique engine that offers the same look-and-feel regardless of the target system.

A DTD allows validation of the structure of the dialogue instance. The LKD that integrates an extended application language generates an HTML template for each listed dialogue containing Javascript code and Java applets, as well as references to Python variables that will be substituted upon execution of the application that displays an entire HTML page. In addition, a Python file of variables is generated that allows display on a screen of the events to be driven as well as the associated code. Upon execution, depending on the screen that is displayed and the event (button or drop-down menu), the client workstation will drive the corresponding portion of the code and will execute the action required.

VT100 Generation

For workstations in character mode, the modules generating the user interface process the same dialogue instance, but adapt certain classical functions for a Windows workstation. Then the buttons or drop-down menus become function keys and the combo-boxes

Note:

^{For fields that refer to nomenclatures.}

become screens that contain the list of all possible values. Scrolling of a screen page is represented by a second screen, etc.

The code inserted into the dialogue instance is executed as it is with the help of a Python library.

For the VT100 or Windows NT stations, the problem therefore is to have a generic module that interprets the dialogue screen without worrying about the application itself or any future applications of the FO.

Client Workstation

Objective

The role of the client workstation is to make a stable, generic tool, that is capable of offering, on the basis of files generated from a formal specification of dialogues,

Note:

^{See Specification of the Dialogue, above.}

a look-and-feel that is similar to that of a specifically developed client workstation.

Definition

For this paper only client workstations that were developed for the Windows NT stations are considered.

The client workstation

Note:

^{The client workstation is written in Visual C++ version 5 (browser-based application).}

is a system based on the Internet Explorer version 4 browser that allows display of HTML pages built from previously generated templates.

The client workstation uses a set of specific modules that are dedicated to the following functions:

initialization of the application, connection to the server, and identification of the first screen to be displayed;
mapping of the message fields with the associated HTML template in order to build an HTML page;
Note:
^{The HTML page is equivalent to the dialogue box described in the dialogue instance}
display of HTML pages (Internet browser);
code
Note:
^{See Specification of the Dialogue, Python variables file.}
execution linked to the page related to a user-driven event;
encoding and deciphering of messages;
Note:
^{Only the VT100 workstations in the distant units.}
sending and receiving messages between client and server.

Principle

Upon execution, the client workstation displays an initial screen that is listed in the initialization module. From this screen, the management of dialogue flows, controls and events to be managed, in short the behaviour of the application, is described in the files resulting from processing the dialogue instance.

The structures generated in Python

Note:

^{See Specification of the Data/Message Groups, above.}

enable building, splitting the incoming or outgoing XML message, and execution of the mapping of the message group data on the HTML page.

Advantages of the SGML Solution

There are two principal advantages of the SGML solution for INGEPOL.

Technical Environment

At the server level, the use of SGML for validating message instances, generating a set of data groups that are characteristic of the database and a set of classes and methods

Note:

^{See Generation of Database Services, above.}

for uniformity, has made standardization of the project easier. Moreover it has reduced the risk of errors because the components generated were stable and has relieved the developer of much of his development work and from carrying out tests.

The generic modules that form the client workstation have allowed the interpretation of a dialogue instance that respects the grammars used.

The User Interface

The content-processing encapsulation principle which is possible with SGML has allowed, along with the object-oriented languages (C++, Python), a better correspondence between the needs of the end-user and the constraints of the producer, in particular through prototyping.

Within the context of INGEPOL, the prototype, based on the principles mentioned, has shown the strengths and weaknesses of the system as originally conceived. Indeed, as soon as the technical environment that allows the generation of components is stable, in addition to the further development/evolution of the server, the project essentially consists of the description of the user interface in more simple terms. Prototyping is the next process where the system is described in relation to a pilot object, validations occurring at regular intervals by processing concrete cases. Major modifications taking place at user-interface level mean that the impact of a modification requested by the client is limited to modifying dialogue instances and generating templates. Once the pilot system has been validated, it is easy to generalize on all the objects and to obtain an end-product. A considerable amount of time can be saved with complex client/server applications, and on multi-platforms that use a considerable number of screens and messages.

By facilitating a dialogue between the client and the supplier, the SGML strategy adopted contributes towards delivering, at the end of the implementation, a product which conforms to the expectations and the needs.

Conclusions

Through allowing a unique definition of the user interface in spite of the different platforms targetted, by authorizing the automatic generation of services dedicated to the databases, achieved by using intrinsic programming possibilities associated with specific SGML parsers, SGML has allowed the simplification and improvement of the development process as far as costs and deadlines are concerned. Above all, SGML permitted command of the complexity which is inherent in any project that calls for different workstations, distant databases that are conceptually modelled according to their needs, and heterogeneous networks, in short everything which characterizes large present-day projects.

SGML plays an important part in the world of documents and it is possible, indeed effective, to use it in a project such as INGEPOL. It has been shown that the flexibility of SGML associated with object-oriented languages allows the description of the behaviour of an application without having to worry about the client platform, and to standardize the encoding process to a greater extent by allowing the abstraction of services generated by the concept.


extended Structured Query Language (xSQL)		Table of contents		Indexes		XML Message Switching