Re: Bundling libxml2 and expat compatibility layer
| From: | Adam Dickmeiss | 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