Lenny Brenner
[EMAIL PROTECTED]
LENNY
I have written a base level API for storing XML which allows facads such
as the DOM,
XQL, XSL, XLINK,... to be built on top. Originally, I designed the
structures used here
to allow JAVA to efficiently store real time XML event streams and have
multiple models
build around it. This current version is written in perl with
XML::Parser::Expat and can
load the neccessary information 20% faster then the XML::DOM. It provide
compression
by reusing strings and compresses children pointers so that 100 ->{101,
102, 103, 105}
and 3045 -> {3046, 3047, 3048, 3050} now both point to {0,1,2,4}. Using
these and many
other compression techniques I have reduced the memory needed by 60%.
This memory is then
used to keep indexes from the meta data to various elements or
attributes. So if I want to find all
/School/Class/Children/LastNames I have a VEC containing
{10,56,76,34,...}. The combination
of these indexes parent links, links from the strings to several
elements or attributes and others
allow me to do SQL style searching in a very constant order. In addition
I have a level of indirection
between element IDs and string IDs. This indirection make versioning as
trivial as swaping
the indirection vectors. I have recently figured out how to make this
API work with databases
for long term storage so I will be adding the XMLDB:DBI. My reason for
submiting this
if to allow others to build complete versions of the DOM, XQL and even
to build models
around it for GUI generation while I handle the optimization for each
additional module.
I will be ready to provide version 0.01 in the next couple of weeks I am
currently waiting
for GTE Laboratories to sign off on the release. One more thing I intend
on building
XMLDB:HASH to allow nested hashtable and arrays to be seperated into
meta data and
actual values.
XMLDB adpO Data model for loading and storing XML
