Re: [PHP-XML-DEV] Replacing expat with libxml

Let me just clarify:

This is not directly related to the new extension.

The idea with this change is to allow people to develop different
extensions and API's ontop of PHP's XML support, and giving them a
robust library to do so, preferrably one that requires minimal external
functionality.

Expat is a very weak library, libxml is a very strong library.  My idea
is to replace it before PHP5, then we have a default library that people
can develop extensions for (like the new "libxml2" extension, etc.)  As
for bundling, the only other option I see is telling people "you must
install libxml2 on your system to install php."  And while that might
make the purists on this list happy, its not a practical solution.  

-Sterling

On Mon, 2003-04-28 at 03:35, Christian Stocker wrote:
> 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
-- 
"The three most dangerous things in the world are a programmer  
 with a soldering iron, a hardware type with a program patch and  
 a user with an idea." 
    - Unknown