[XML-SIG] Re: saxlib 1.0beta

[Lars Marius Garshol]

Paul Prescod wrote:
> 
> No. I guess I'm suggesting we just drop xmllib. Turn it into a wrapper for
> xmlproc unless it is faster or otherwise better as it is. 

It's not faster. A speed test on my NT box here in Germany gave these
results (in seconds) when parsing quran.xml (1 MB) with saxtimer.py:

xmlproc      118
xmlproc_val  142
xmllib       148
xml-toolkit  451

I've since added attribute whitespace normalization to xmlproc, which
slowed the non-validating driver down to 123 seconds. The effect on the
validating one will depend on the DTD used, since it has to do extra
work
for all non-CDATA attributes.

> The DOM may also present performance problems. Python objects are a
> little heavyweight for large documents. Maybe someone will/should write a
> DOM in C. I wouldn't expect it to be that large or complicated. It would
> primarily shift the property lookup from bulky hash tables to svelte C
> code and (relatively) bulky PyObjects to C strings and pointers.

Having the choice between Python/C implementations, just like with the 
parsers sounds very good to me. (Something for the wishlist?)
 
Apropos wishlist: I was bored two nights ago and started an XPointer
implementation. I now have a parser and have implemented significant
parts
of a DOM XPointer implementation. (Basically all relative location
terms, 
with candidate counting, element type filtering and attribute
filtering.)

Next week will probably see a string of new releases from me: xmlproc
0.31,
the XPointer thingy and quite possibly saxlib as well. (No, the official
SAX version is not set in stone yet and I'll wait for that before I
release
saxlib.) This means that the XLL-implementation can be taken of the
wishlist
and put on the deliverables list.

--Lars M.