Re: Bundling libxml2 and expat compatibility layer

From: Date: Sun, 04 May 2003 12:36:17 +0000
Subject: Re: Bundling libxml2 and expat compatibility layer
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-1198@lists.php.net to get a copy of this message
On Sat, May 03, 2003 at 12:11:14PM -0400, Sterling Hughes wrote: > Hi, > [snip] > 3) Proper unicode support What is it that Expat misses? Expat itself MAY recognice the encoding in the header. However, the C code in PHP forces Expat to use some other fixed encoding by providing a NON-NULL pointer for XML_ParserCreate. Furthermore Expat allows you to plugin conversion handlers that allows for a substantial subset of characer sets out there. It is possible to use iconv for that purpose. (Expat call XML_SetUnknownEncodingHandler). Expat does not do much, but it does its job well and fast. -- Adam > 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 > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php -- Adam Dickmeiss mailto:adam@indexdata.dk http://www.indexdata.dk Index Data T: +45 33410100 Mob.: 212 212 66

« previous php.internals (#1198) next »