DOM runtime database
The DOM database is straight forward except that it needs to be thought of as the “Runtime Database,” since a persistent database store (XML database, SQL database) would be implemented as an I/O plug-in.
The database does lazy insertion and removal of elements. It keeps a list and then does the actual insertion or deletion upon the next database query, if any.
The queryElement function has never been implemented but I assume it would be used to parse XPath or XQuery expressions. The current DOM would not be able to do full XQuery support because there is no way to address attributes or values by themselves and XQuery allows you to get lists of all attributes that … , etc.
The stlDatabase is the default implementation of a daeDatabase. The only time I think someone would want to write their own database is if they want database paging, i.e. moving data in and out of memory based on usage. (this would require a lot of work besides just writing the database though)
The database contains two structures to store all elements. One is a sorted list of all elements, sorted by element type. The other is a multi map with the key being an element ID and the value being the elements themselves.
The multi map is used to speed up URI resolution since URI’s query the database by element ID. It is also used if the user supplies an ID for the getElement or getElementCount query functions.