Newsgroups: php.internals,php.xml.dev
Path: news.php.net
Xref: news.php.net php.internals:1062 php.xml.dev:101
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <3EAD180D.1040908@caraveo.com>
Date: Mon, 28 Apr 2003 05:01:17 -0700
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401
MIME-Version: 1.0
To: Sterling Hughes <sterling@bumblebury.com>
CC: internals@lists.php.net, php-xml-dev@lists.php.net, php5-dev@lists.php.net,
   "Stig S. Bakken" <ssb@fast.no>, "Thies C. Arntzen" <thies@thiesos.org>
References: <1051482765.25677.15.camel@hasele>
In-Reply-To: <1051482765.25677.15.camel@hasele>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP5-DEV] Replacing expat with libxml
From: shane@caraveo.com (Shane Caraveo)


> After some discussions with various people at the PHP-Con, I decided it
> was important that we (at least) have libxml integrated with PHP by
> PHP5.  When it comes to XML processing, expat is a legacy library and it
> doesn't support nearly what is required for processing XML by todays
> standards.

> The current version of expat makes processing SOAP documents (for
> example) very hard, because XML schema is not available.

I'd like to talk with you about what features will be implemented in 
time for php5, as there are some specific features that would be good 
for soap (ie. pull parsing).  I'm at the airport now, so later this week.

> - FTP and HTTP transports (as well as an IO wrapper library like
> Streams)

Can the wrapper be made to work with the php streams?  It would be nice 
for instance, to simply be able to pass php://stdin to the library and 
have it handle input.  A call back to handle protocol headers, or 
alternate encodings such as dime would be necessary.  Anyway, those are 
some things I'd like to discuss.

> I've currently completed the first two steps of the integration.  I've
> removed the expat library from ext/xml and replaced it with libxml. 
> I've also ported the XML extension to use libxml as the underlying
> processing engine.
> 
> The following incompatibilities exist:
> 
> 1) some XML_ERROR_ * constants are irrelevant (they are stilled defined,
> but they have no meaning for libxml).

Are they mappable in any way, or simply library specific errors?

> 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?

My concern is of course BC.  I think a little bit of breakage is ok, but 
by little I'm thinking < 1%.  Otherwise, there needs to be some way to 
load the expat xml extension.  Perhaps the expat extension functions 
could be renamed to expat_xml_*, libxml would be libxml_*, and a utility 
function such as xml_use_library(XML_EXPAT) would map xml_* functions to 
the xpat library (or libxml).  The default mapping would be to libxml.

Shane