Newsgroups: php.internals,php.xml.dev
Path: news.php.net
Xref: news.php.net php.internals:1061 php.xml.dev:100
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
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>
In-Reply-To: <1051482765.25677.15.camel@hasele>
References: <1051482765.25677.15.camel@hasele>
Content-Type: text/plain
Organization: Bitflux GmbH
Message-ID: <1051515335.1936.8.camel@lappi.lappi.chregu.tv>
Mime-Version: 1.0
Date: 28 Apr 2003 09:35:37 +0200
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-XML-DEV] Replacing expat with libxml
From: chregu@bitflux.ch (Christian Stocker)

On Mon, 2003-04-28 at 00:32, Sterling Hughes wrote:
> Hi,
> 
> 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.

I'm still no big fan of bundling libxml2 with php, but if there's a
consensus that it should be bundled, so be it, _if_ anyone takes the job
of merging the constantly updated libxml2 sources into the php-tree. On
the other hand, wouldn't it be enough, if it's bundled in the
downloadable sources and not put into CVS?

> On the other hand libxml is a very robust xml processor, providing
> support for:

Just for your information: Rob Richards is currently working hard on the
new domxml extension, which follows the DOM Standard much better than
todadys domxml. Furthermore it will also have better memory management.
I think, it's soon in a state where we can put it into CVS.

We were also talking about a new name for this new extension as domxml
is quite missleading (as Sterling said, libxml2 can do a lot more than
just DOM processing). Any thoughts about that?

chregu


> 
> - XML Schema
> - DOM
> - Validation (against a DTD or Schema)
> - SAX
> - XML Catalog
> - Docbook and HTML Parsers
> - XPath, XPointer, XInclude
> - Base XML datatypes (XML Schema Part 2)
> - FTP and HTTP transports (as well as an IO wrapper library like
> Streams)
> 
> 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).
> 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?
> 
> -Sterling
> 
> -- 
> "The computer programmer is a creator of universes for which he  
>  alone is responsible. Universes of virtually unlimited complexity  
>  can be created in the form of computer programs." 
>     - Joseph Weizenbaum
-- 
christian stocker | bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich
phone +41 1 240 56 70 | mobile +41 76 561 88 60 |  fax +41 1 240 56 71
http://www.bitflux.ch  |  chregu@bitflux.ch  |  gnupg-keyid 0x5CE1DECB