Newsgroups: php.internals,php.xml.dev Path: news.php.net Xref: news.php.net php.internals:1056 php.xml.dev:96 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 18429 invoked from network); 28 Apr 2003 00:00:57 -0000 Received: from unknown (HELO www.lerdorf.com) (66.93.78.119) by pb1.pair.com with SMTP; 28 Apr 2003 00:00:57 -0000 Received: from [10.0.1.10] ([10.0.1.10]) by www.lerdorf.com (8.12.9/8.12.9/Debian-3) with ESMTP id h3S00njh008237 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 27 Apr 2003 17:00:49 -0700 Date: Sun, 27 Apr 2003 17:00:49 -0700 (PDT) To: Sterling Hughes cc: internals@lists.php.net, , , "Stig S. Bakken" , "Thies C. Arntzen" In-Reply-To: <1051482765.25677.15.camel@hasele> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [PHP-DEV] Replacing expat with libxml From: rasmus@lerdorf.com (Rasmus Lerdorf) References: <1051482765.25677.15.camel@hasele> > The following incompatibilities exist: > > 1) some XML_ERROR_ * constants are irrelevant (they are stilled defined, > but they have no meaning for libxml). > 2) xml_error_get_string() just returns a blank string. This can be > changed in the next couple of days, i just need to implement error > strings ontop of libxml error codes. > > Having this library bundled internally will allow people to develop > other extensions which use libxml features, and will allow for future > extensions (for example, a fully compliant DOM extension) to easily be > added, without requiring extra bundling. > > Thoughts? I take it from this that old apps written against expat using the xml_set_element_handler() style will continue working? Like I said in New York, I agree we need to move to libxml, but I worry about breaking thousands of existing php-xml apps. If you have managed to make it BC-safe, perfect! -Rasmus