[XML-SIG] Finding _xmlplus in Python 2.3a2

Martijn Faassen faassen@vet.uu.nl
Tue, 4 Mar 2003 12:33:30 +0100

Uche Ogbuji wrote:
> Of course, this leads us to the likely bad news.  I think that there might be 
> some resistance to all the bells and whistles we use to work all this stuff in 
> 4Suite.  Martin, for example, already preferred to rewrite the XPath/XPattern 
> parsers in Yapps.  If the 4SUite mechanisms are not accepeted as they are, or 
> close to it, I anticipate a lot of work, that we might not be able to find 
> contributors for.

Side note: Infrae's working on an XML database with a (hopefully) fast
XPath implementation that uses a fast but compact index mechanism and
things like database joins. I took some of the PyXML XPath parsing code
to build up the basic parse tree. I'm worried about the long-term
maintenance issues of that code, as I had to do quite a bit of hacking
to make it work and use my Parsed* classes and not PyXML's. I think that
this uses Martin's parser and not 4Suite's. A pluggable architecture
would be nice. :)

> > It's getting down to the wire on the 2.3 release. Perhaps it would be a good 
> > idea to raise the subject on python-dev.
> I'd like to just get a round of thoughts from the others on this thread first. 
>  Then I'll volunteer to broach the topic on python-dev.  AT least I'll talk 
> about swallowing SAX and DOM-minus-4DOM.  I think talk of swallowing 4XPath, 
> 4XSLT or aught else from 4Suite 1.0 is probably a topic for later on, on 
> python-dev, though fair discussion here right now.

Yes, I think we should consider not letting that be swallowed by the
core ever. After all, these are programming language implementations (XPath
and XSLT are) and the Python core is already maintaining one. So I
would suggest distributing this as a separate package (pyxml) and not having
the ambition of moving it into the core.