Comments on: XPath based Python dictionaries, on loan http://decafbad.com/blog/2004/09/01/xpath-based-python-dictionaries-on-loan It's all spinning wheels and self-doubt until the first pot of coffee. Wed, 07 Jan 2009 05:08:10 +0000 http://wordpress.org/?v=2.8-bleeding-edge hourly 1 By: Ryan Tomayko http://decafbad.com/blog/2004/09/01/xpath-based-python-dictionaries-on-loan/comment-page-1#comment-1302 Ryan Tomayko Tue, 30 Nov 1999 00:00:00 +0000 http://www.decafbad.com/blog/?p=544#comment-1302 <p>Funny that. I also have one that has survived a couple of failed apps. I have a hard time dropping it to be honest and just keep lugging it around to each new project. </p> <p>http://naeblis.cx/cvs/percolator/xb/lib/xpdm.py?rev=HEAD&content-type=text/vnd.viewcvs-markup</p> <p>It has some pretty big issues. Among other things, creating nodes with namespace support is a little.. ermmm.. not there. But it does a lot of things well like garbage collecting xmlDoc instances (freeDoc), copying nodesets between documents, encoding things when they need to be, etc.</p> <p>Anyway, I wonder if maybe we all might benefit by teaming up on this and try to define what a complete xpathish wrapper atop libxml2 should look like. And really, why limit it to libxml2? I'm of the opinion that the value here is an interface that embraces xpath. The fact that it's running on top of the blazingly fast libxml2 is nice but coding against the XMLTRAMP like interface is the value for me.</p> <p>So let me see if I can get some time together to whip up a quick comparison of the three implementations. I'll shoot that over to you and Kimbro and we can go from there. If these seem to work best as backyard APIs we like to keep close to us, we'll drop it. However, I think there's a good chance that we can all benefit by combining our efforts.</p> Funny that. I also have one that has survived a couple of failed apps. I have a hard time dropping it to be honest and just keep lugging it around to each new project.

http://naeblis.cx/cvs/percolator/xb/lib/xpdm.py?rev=HEAD&content-type=text/vnd.viewcvs-markup

It has some pretty big issues. Among other things, creating nodes with namespace support is a little.. ermmm.. not there. But it does a lot of things well like garbage collecting xmlDoc instances (freeDoc), copying nodesets between documents, encoding things when they need to be, etc.

Anyway, I wonder if maybe we all might benefit by teaming up on this and try to define what a complete xpathish wrapper atop libxml2 should look like. And really, why limit it to libxml2? I’m of the opinion that the value here is an interface that embraces xpath. The fact that it’s running on top of the blazingly fast libxml2 is nice but coding against the XMLTRAMP like interface is the value for me.

So let me see if I can get some time together to whip up a quick comparison of the three implementations. I’ll shoot that over to you and Kimbro and we can go from there. If these seem to work best as backyard APIs we like to keep close to us, we’ll drop it. However, I think there’s a good chance that we can all benefit by combining our efforts.

]]>