Bundling libxml2 and expat compatibility layer

Hi, Well, OK, I have libxml2 successfully bundled with PHP, and I've further gone ahead and created a C-level compatibility layer which maps expat <-> libxml2. I've also moved the detection logic for both expat and libxml into php5/bundle/libxml and php5/bundle/expat respectively. This way you can choose your backend at the configure line, and things will work transparently (by default, expat and libxml are compiled in, and the XML extension uses expat). I've also done the "namespace redefinition" heavy lifting - I'm not quite sure it works, but I have renamed most (from what I can tell, all) public symbols, like with expat. I'm sure this could be ironed out pretty easily if I made any mistakes. As far as I'm concerned, the important thing here is bundling libxml2. I think everyone who is implementing XML support around PHP will agree that expat just isn't meeting our needs, specifically: 1) The ability to easily access and modify XML documents from within a programatic structure, alá DOM (this would also make it easy for me to implement my SimpleXML[1] extension). a) The ability to query an XML document via Xpath 2) The ability to validate an XML document against either a DTD or a XML Schema (very important, especially for SOAP.) 3) Proper unicode support 4) Support for XPointer and XLink 5) Support for Docbook and HTML parsing 6) Expat doesn't even full support the same capabilities that libxml2 does when it comes to SAX processing. However, when we bundle expat with PHP, and make ext/xml therefore an "always available" extension. We create the illusion that it is the "recommended" and "best" solution for XML parsing with PHP, when in fact it really isn't. Our needs as far as XML support are growing, whether it be implementing technologies that exist on top of XML (SOAP, WSDL, RDF) or implementing extensions that make it easier to access XML (SimpleXML, DOM), expat makes it way to hard (for all intensive purposes, impossible) to implement these systems. Therefore, I'm suggesting that we bundle libxml2, while (for now) keeping in expat as well. This will cause *absolutely* no backwards compatibility changes, while at the same time, it will allow you to use only libxml2 for XML processing (--without-bundle-expat), with 97% [2] backwards compatibility maintained. -Sterling [1] http://news.php.net/article.php?group=php.xml.dev&article=6 [2] This is one of 54% of facts made up on the spot. Suffice it to say that the new extension is "mostly" backwards compatible, and the places where it breaks, shouldn't have been relied upon anyway. -- "Reductionists like to take things apart. The rest of us are just trying to get it together." - Larry Wall, Programming Perl, 3rd Edition