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.
Insertion and deletion
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, that is, 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:
- A sorted list of all elements, sorted by element type.
- A multimap with the key being an element ID and the value being the elements themselves.
- The multimap is used to speed up URI resolution since URIs query the database by element ID. It is also used if the user supplies an ID for the getElement or getElementCount query functions.