The reasons for implementing a more simplified document object model when there are several fully compliant DOM XML parsers available are several:
The DOM parsers are in general very heavyweight, which we found unattractive for use in an applet. By contrast, the Ælfred parser is extremely lightweight in spite of being a conforming XML parser.
The resulting object model is very complicated and heavyweight. The DOM is intended to be able to describe any type of XML document containing arbitrary markup. Again, our decision to enable the use of our browser in a web environment has led to demands of simplicity. In fact, as our XML DTDs are used as data structures rather than documents, the needed object model can be made much simpler without loosing any necessary functionality. The use of this simpler object model makes the code using the model much simpler as well.
Thus, we decided to use a simple parser and design a simple object model that fits our realively uncomplicated DTDs, but would not fit for example an HTML DTD. The decision still seems to have been the right one.
The component package design is extremely modular. Designing the package in this modular way has made clear the responsabilities of the different parts of the design, which in turn has influenced the design of the data format and component identity specifications. The structure will help when adding resolver functionality and other data formats.
The need for a listener mechanism is motivated by two cases of use:
When the same neuron is used several times in the same browser (in different maps), and is edited in one of them, it is immediately updated in the other.
Even when several users access the same CORBA object, they will all be notified when someone modifies the object.
The risk of not using a mechanism like this is to create inconsistencies when editing, something that is most problematic when using CORBA.
The need for full independence of the neuron level and the concept map level is motivated by the possibility to use the neuron level in other types of concept maps, but also by the fact that this library may be used when constructing server-side search engines and similar tools.
These parts of the library are not strictly part of the fundamental API, but still seem general enough to belong here. It is interesting to note that these constructs are implemented solely with the help of the API, using the components as a data structure.