Configuration data, what is it? Professional

The term "Configuration data" describes data that is not processed by an application in the usual sense, such as creating a report from a database, for example, but is used to control the behavior of an application. What is the default directory for databases? Where to store the position of the application window so that the program "wakes up" at the same position when it is re-started? These are common questions to be answered in the context of configuring an application program.

The main problem in finding a solution to such questions is the lack of a standardized and convenient file format to be used for configuration data storage. Some developers tend to use the Windows registry for this purpose, others write a parser/reader for their own proprietary file format, and there is a group of programmers favoring the well known Windows INI file format which develop their own program routines to process such files.

As a result, programmers all over the world have developed scanners or parsers to suit their own needs, and it can be assumed that parsers or scanners are one of the most redundantly written pieces of code.

Configuration data can be "hard-coded" in PRG source code. However, there is an increasing demand for flexibility and this requires an application to become more and more data driven, i.e. the application must use external data. In addition, applications must integrate with other solutions for the purpose of data exchange. EDI or EDIFACT is a well known data exchange format in this context, for example.

The need for a platform independent, easy to maintain and widely accepted file format for configuration data requires a configuration file to be readable/editable with a normal ASCII editor. This excludes any form of binary files, such as DBF or XPF files. In addition, configuration data must be accessible via symbolic names, it must be user-definable, covering complex data structures such as arrays of more than three dimensions in depth. Windows INI files meet two of these requirements (ASCII editor, symbolic names), and this is the reason for the wide acceptance of this file format, but INI files are unsuitable when complex data structures must be stored.

A file format for conveniently reading/editing configuration data with an ASCII editor that allows for storing complex data structures and accessing data via symbolic names is XML. In addition, the XML file format is platform independent since it is defined by a commonly accepted standard.

These are some reasons for the existence of the Alaska Software XML parser library that allows for easy processing of XML files from Xbase++ applications. The purpose of this document is to demonstrate the versatility of XML file usage for configuring an Xbase++ application. A short introduction into XML is followed by a discussion of how to design XML files and how to apply the Alaska Software XML technology in a common usage scenario.