This page describes the overall structure of the XML Testbed software,
and says a little about the reasoning behind this structure.
The XML Testbed software has been divided into a number of Java packages, to make it as modular as possible. (In fact, it has been divided into as many packages as is sensibly possible.) The relationships and dependencies between these packages are shown in the following diagram (which adheres to no known notation):
|xa - XML Atom||The aim of this package is to encapsulate knowledge about certain aspects of the XML language. These facilities (and there are so far very few) used to be embedded inside the xe parser itself, but have been extracted to allow edit functions to make use of them.|
|xg - XML Grove||Classes for representing the components of a parsed XML document. This is not DOM-compliant, although it is intended to move towards it; for further details, see separate page on DOM compliance.|
|xm - XML Manipulator||This provides a range of document manipulation capabilities, including factory classes, a base parsing 'engine' class, and document model and document listener classes (to co-ordinate changes made in multiple document views). This package also contains the 'node type registry' for specialised element and other classes.|
|xc - XML Customizer||This is a library of classes for editing XML entities of various types (as represented by classes in the xg package). The name of this package comes from JavaBeans, in which a customizer is used for editing a bean.|
|xv - XML View||This contains swing.text.View classes to be used to display elements in a Swing styled editor.|
You may observe from the diagram that even the low-level packages are dependent upon the Java Swing library. The only reason for xg depending upon Swing is that the basic xg_Node class inherits from DefaultMutableTreeNode, for convenience in displaying any type of entity within a Swing JTree.
XML Parsing Engines
The XML Testbed infrastructure is not confined to using a single parser. It can be driven by any parser for which a suitable 'engine' class has been written, where an engine class must inherit from xm_XmlEngine in the xm package. The xe package comprises one such parser and engine class. Two other engine classes have been implemented, for SAX and NXP; these are in the xt package. 'sax' as shown in the diagram above is not a package, but is shown merely as a representation of a collection of unknown parsers and their SAX drivers (unknown to the rest of the XML Testbed, that is).
Note also that the diagram above shows no packages depending upon the
parser packages. This is achieved by having the engine factory in the xm
package create an engine given its class name. This is true for the core
processing, but at present the xu package explictly uses an xe engine (for
|xe - XML Engine||Steve's XML parser and supporting classes. The salient feature of this parser is that it delegates the parsing of each type of XML entity to a parser class specifically built for the job, and so comprises a suite of small parser classes rather than monolithic large classes. These classes are created by a parser factory driven by the 'node type registry' in the xm package, which provides a great degree of configurability and allows new types of parsers to be added easily. The main benefit of this to date has been in cleanly accommodating changes to the XML specification (with the latest Namespace specification dooming the namespace declaration parser), but it also permits other specialised parsers to be slotted in as required.|
|xs - XSL Engine||An XSL engine, for applying an XSL stylesheet to an XML document.|
|xu - XML User Interface|
|da - Database Analysis||This generates a schema in XML for an existing database - any database
to which it can connect via JDBC.
A sample generated XML is supplied: NorthwindDB.xml is the result of analysing the 'Northwind' example database provided with Microsoft Access. An XSL stylesheet suitable for use with such a database schema is supplied, xsl/DatabaseSchema.xsl, but it important to note that the da package generates XML elements which have attributes for the main schema values, and the stylesheet assumes these values are in child elements. A conversion is thus required in order to complete the cycle, and a utility to do this is included in the xm package (and can be invoked using the 'Convert attributes to nodes' button on the XML Testbed toolbar).
Invoking Application and Miscellaneous
|xt - XML Testbed||A frame for editing, processing and viewing an XML source, and an environment to which XML usages can be easily added.|
|eh - Error Handling||This contains a class (eh_Debug) for logging application-level debug
messages. Requests to output a message are displayed in a debug frame.
This frame displays messages in a Swing text area, and uses a separate
thread to reduce the performance impact - which is still substantial, nevertheless.
The quantity of debug output can be controlled by a current debug level (a number from 0 to 9), and each call having a similar level to indicate its importance. Note that debug calls to eh_Debug are static, so calls can be made from anywhere, and it not necessary to instantiate this class all over the place.
A considerable number of debug calls are embedded in the other packages, to make it easy to see what the application is doing. They do, however, degrade performance significantly and are slowly being removed from the stable parts of the system. Many are commented out.
|oh - Online Help||A frame for displaying HTML help. It can be created by another frame (as xt_XmlTestbedFrame does), and be told which page to show. It also has its own menus which allow navigation to other pages. The contents of the menu are specified in an XML configuration file.|