Summary

Description

No proper list of defects!

Numerous minor defects have already been detected. Many (but by no means all!) can be identified in source code by '//TBD' and '//TEMP' style comments.

Components have no end position

Some types of components (notably DTDs and their constituent parts) do not have their end position calculated. (This is particularly noticeably when looking at them in the tree view.)

Table view problems

The Swing JTable class is rather an unruly beast, and is causing several problems, including:

• The table does not refresh when the underlying tree changes (eg. when a new document is parsed).
• Double-clicking on an unexpanded document sometimes does not expand it - leaving you unable to see it.
• Certain types of node (eg. text) cannot be viewed in a normal node customizer (ie. the panel on the right hand side). They cause a null pointer exception - which, in this case, is no doubt not a Swing problem.

Source/tree not kept in sync

Considerable work needs to be done to keep the different views of a document in step with one another. This would be a precursor to more sophisticated editing of the source directly (eg. being able to switch off display of much of the non-content part of an XML document), to give a certain degree of WYSIWYG editing.

Changes to the source are not reflected in the tree until the document is explicitly reparsed.

Changes to the tree (and there is nothing you can do yet except change the value of an attribute!) are not reflected in the source - unless you save the document from the tree (which also causes all position information to be lost).

Summary

Description

Non-validating

XE is presently not a validating parser.

It does, however, perform what is called 'verification' (not a sanctioned XML process!) on each node as soon as it is parsed, by calling the node's verify() function. This allows element type-specific verification to be invoked during the parse. A number of element classes use this feature to perform checking which could (should!) be done as part of validation - although it has the advantage that a DTD is not required.

References not properly supported

Reference are parsed, but nothing more is done with them. They are not properly expanded, nor are they added to the parse tree.

External DTDs not supported

The definition of an external DTD can be parsed, but it will not be read.

Summary

Description

Performance!

The parser is currently very slow. The biggest factor is the presence of a large number of debug calls. Performance is greatly improved when the debug level is reduced.

(James Clark claims to have the fastest XML processor available. I claim to have the slowest. I recognize that his claim is more valuable, and would like to adopt his parser when I get round to it.)

xe circular dependency

There is a circular dependency between three of the key xe classes, which means they cannot be compiled from scratch. (Ie. if no .class files are present, lines must be commented out of one of these files to allow it to be compiled.) xe_Parser uses xe_ParseManager, xe_ParseManager uses xe_ParserFactory, and xe_ParserFactory creates xe_Parser objects. The likely solution is to split xe_ParseManager into two classes.

Summary

Description

Externalise error messages

Error messages are currently hard-coded. Rather than simply read error message texts from a resource file, it is intended to store further information about each type of error (in XML, of course!). This would to provide further information on the nature of the error and to allow prompting for corrective action (such as displaying a list of allowed alternatives to an illegal value).

Pick all text up from resource file

Most text displayed in the XT user interface comes from a Java resource file, but some doesn't (of which some is in the XML menu definition file, and some is hard-coded).

Introduce styled editor

The source edit frame is currently a simple JTextArea, but it is intended to replace this with a Swing StyledEditor, which will facilitate colour-coded display of different types of entities. Much of the supporting infrastructure for this is already in place - such as use of the Swing Document class for the source and creation of Swing Positions for the start and end positions of each entity. (Notice that an entity's tooltip text in the tree view displays its position, and this changes if the source is edited.)

Display and edit node details

It is intended to display the details of the entity currently selected in the tree view and allow it to be edited. This panel already exists (as the right hand spilt pane in the tree view, but contains little content yet). All the supporting infrastructure is in place, with XE allowing special 'customizer' classes to be registered for particular types of elements.

Externalise knowledge of XML

Most of the knowledge of XML embodied in the software is in the parse-related classes (and some in the xg grove nodes). To improve structure and flexibility, it is intended to pull as much as is sensible out into the xa (XML Atom) package, which is intended to harbour much of the low-level knowledge of the XML language (including keyword strings). This process has already begun (as the existence of xa testifies!).

Use XML menu definition in aj application

The.xt_TestbedFrame picks up its menu and toolbar definitions from an XML file (xt_Testbed.xml). The calling aj application (aj_AdjutantFrame) does not - yet.

Summary

Description

Use XSL rules for other purposes

The underlying idea of rules driving a stylesheet is very elegant, and there seem to be no reasons why this idea could not be applied to other XML processing tasks beyond the creation of styled output.

Rules could remain the same, but new types of actions could be introduced to perform any task on the selected target the developer wishes.

Note that the structure of the XE parser would allow new such action classes to be registered and used with no modification required to the core software. If using rules for other purposed, however, it may be cleaner to split the generic parts into a separate package (xr is suggested).

Allow processing of multiple source XML files simultaneously

It appears to be a simple matter to allow multiple XML files to be supplied for XSL processing at the same time, to allow controlled merging of them.

It is suggested that this could be implemented by enhancing the 'target-element' element to allow it to identify which document it refers to. (If one XML document were to be regarded as the 'primary' and used as the default target in the absence of an explicit name in the 'target-element', existing stylesheets would remain correct for processing of a single document.)

Use XSL to specify XML editor parameters

It is planned to enhance the XML source editor in XT to more than simply display the raw source. (Or, rather, it is planned to keep the current view and introduce a second, more advanced, edit view.)

An XSL stylesheet would be an excellent vehicle for holding the details about how to display different types of elements. Apart from the basics (such as fonts and colours), such stylesheets could hold other parameters (which have yet to be defined!).

Summary

Description

Autotest in Testbed

It should be a straightforward matter to define a list of XML source files (in XML!) and parse them one after another. These files would be a mixture of valid, well-formed and erroneous (of various sorts), and the configuration could define the expected outcome for each.

Compare/merge functions

One purpose to which I wish to put XML is as a vehicle for automatically-generated information, to which manual annotations are then added. (The df package is an example of this: it uses JDBC to obtain the schema of a database and record it in XML. Descriptions of tables, columns, etc. can then be added by hand.)

To prevent the resulting XML becoming out of date, we wish to be able to automatically regenerate the core information again (eg. to take into account changes in our database schema). This makes both comparison (diff) and merging capabilities highly desirable.

For example, in the case of our database, we wish to be shown clearly what has changed since before (comparison), and also to not have to manually re-apply our annotations (merging).