On 2/23/04 1:53 AM, Sterling Hughes wrote:
It will never work correctly for option 1. Namespaces in SAX was a 2.6
thing
(SAX2).
Right, but namespaces just need to work as good as they did in PHP4, we can't lose that compatibility. If it works better - bonus.
So what exactly is broken then in comparison to PHP4? From the size of the patch and everything that was replaced, I was assuming quite a bit. And looking at some of the functions added (start_element_ns, etc...) - those are all SAX2 things. Are these needed to get it all working correctly or were those just additional features? If that is the case, then I would definitely agree fixing it for 2.5 is the way to go and not implement the additional features - Arent we in a feature freeze anyways :)
(*) I don't think any of that is actually broken with comparison to PHP4 - I think all that breaks in PHP4 too. PHP4 uses the prefix with namespaces as does PHP5, all these problems are inherent with using namespace prefixes. The default namespace problem may not exist with PHP4 (haven't tried it), but I assume the other problem must.
Even if PHP4 did it wrong in ext/xml, we shouldn't actively violate PHP4's compatibility. This is not like domxml which was never stable, we
shouldn't break compat, even if we are doing the right thing.
No, it worked right in PHP4 with expat. See php5/ext/xml/xml009.phpt, this test works in PHP4/expat and now in PHP5 with libxml2.6, but not with libxml2.5.
Therefore at the moment, with libxml2.5, BC to PHP 4 is broken. I recognized that, when I tried to use HTTP_WebDAV_Server from PEAR (the only package in pear, which uses xml_parser_create_ns, btw)
And I didn't introduce new features ;) xml_parser_create_ns() exists since 4.0.5. And the internal implementation is much shorter and much simler now.
I'd also prefer if we don't have to bump the requirement to 2.6 at this stage in the release process. If solution 3 (disable it) or 4 (use broken code for 2.5) is the way to go, I don't know. The functions seems not to be used very often, as noone reported any problem with it. But if you would use the broken one, you would soon run into troubles, since a lot of XML files with namespaces use default namespaces and those are not recognized. And this particular issue leads to a very high WTF factor, IMHO. I'd therefore prefer solution 3 in the short term. Fixing it for 2.5 would be even better, of course... And 2.6 as prereq could then be something for 5.1 ;)
If noone complains, I'll commit a patch for solution 3 later this morning, so that it at least compiles again with libxml2.5. If solution 4 is preferred, we still can add/revert it later. I don't mind ;)
chregu
-Sterling
(*) Wrap the first paragraph with 'As Far As I know,' I haven't tested this.
-- 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 | [EMAIL PROTECTED] | gnupg-keyid 0x5CE1DECB
-- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
