XE Wishlist

This page lists known defects, omissions, areas for improvement and ideas for the future.

Defects

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).

Omissions

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.

Areas for Improvement

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.

Planned Enhancements

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.

XSL Ideas

In developing an XSL engine, the following observations and ideas resulted.

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!).

XML Ideas

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).

(This page was last updated on 21 June 1998 by SW.)