[Fwd: [PHP5-DEV] XML in PHP5]

here are my thoughts about this issue, which i sent to the php5-dev list. just to throw in my brainstorming chregu -----Forwarded Message----- In this mail I will mainly cover my ideas about the future of domxml. I can't speak for the other extensions. History: It looks to me, like domxml was developed (the initial versions) without having the dom-w3c standards in mind. There are a lot of functions in domxml, which never existed in the w3c-dom-standards, but are in libxml2. libxml2 never intended to be w3c-dom-compliant but having its own dom-implementation, so didn't domxml. This was very misleading. And then it was decided to introduce some w3c-dom methods, which we have today. Furthermore the oo-interface was introduced and more and more features added (xslt,xpath,html,validation,etc..). I'm only into domxml since about a year, so the above lines are not exactly about how it was, but this is my impression. Today, the API of domxml is a total mess (as a consequence of the history above). We have w3c-dom methods, we have libxml2 methods, a lot of others and some other issues (weak namesppace support for example).. Therefore I suggest, we start all over again with domxml and try to do the API properly this time. As a starting point we should certainly stick to the w3c-methods, but there are not standards everywhere as for example how to start an xslt-processor etc. For those cases, I suggest we look at the mozilla-js API or Java and take our ideas from there and try not to invent it again. This will certainly break BC, but as already mentioned on this list, one could expect that within a major release and domxml did break it a lot of times in the last releases already, therefore the uses are used to it ;) But since the new domxml will rely on the w3c-standards, the API shouldn't be broken again after that... I wouldn't suggest to only implement the w3c-standard since it's sometimes quite verbose. I like for example the get_content method of libxml2. It saves you a lot of lines of code and is much faster than something written in php and only w3c-dom-standards. but those convenience-methods are not of high prio and can be introduced later, but shouldn't really be ruled out just for the sake of a clean w3c-implementation. Furthermore libxml2 is not only about DOM, it also has XSLT, HTML, SAX, XPath, XML Schema, etc support. These XML technologies are all somehow incorporated into domxml today, but it's chaotic and needs a cleanup... libxml2 is very powerful and PHP could provide a lot of today's needed XML-capabitilities with only this library (I don't say, there shouldn't be others, but it's the ideal candidate to have a quite powerfull XML support in PHP5) Concerning different backends: sterling wrote in his paper, that we should have a common frontend and different backends for all those XML-Methods. The idea was, that you could for example write your XML-Document with libxml2 as backend and then let it process with sablotron. I'm not sure, if this could ever work, because the dom-implementation on the c(++)-level are too different for actually being able to interact with each other. As Pierre showed, it's no problem to write an XSLT-abstraction class in PHP. And I think, we could do something like that also for DOM, XPath and SAX. Sterling tried to do the OneFrontend/DifferentBackend story with ext/xslt, but there was noone, who ever wrote a different backend besides sablotron (which is certainly not Sterlings fault), the implementations are just to different and for libxslt it wouldn't make a lot of sense, either: Therefore, my suggestion for (DOM)XML and PHP5 is: - Rewrite DOMXML and incorporate all (or most of) W3C-DOM2 - use the new ZE2 features (Exceptions, setter/getter) - add SAX(2), XML Schema - XSLT, HTML, XPath, XPointer, DTD Validation will still be supported, have to find a meaningful API for it - break BC, warn user now. - integrate the soap-extension, as this also relies on libxml2 (IIRC) - look at the libxml2 patch by lukas schröder and see if we can prevent memory leaks with it (anyway, getting rid of mem-leaks and intelligent memory management is on top prio...) - In the longer term, domxml (or another name, as with todays features domxml is a little bit misleading) shall be the main xml-class, which covers most of what's needed for decent XML support in PHP ;) But there is certainly place for others like Sablotron etc. - never ever bundle libxml2 with php ;) As for the developement of this stuff. I'd really like to do it and I am more than willing to write it (not alone hopefully), but I can't make any promises until when and how much of the above points I can implement since my company is keeping me busy most of the time... (But if some kind soul has the impression, that PHP5 needs really good XML support and wants to sponsor me resp. my company for that, then that would be a whole other story, but I think, I'm not the only one here in this situation... ) Suggestions, Comments, etc are always welcome. And if anyone has a really good idea for the "different backend" problem, please stand up. Maybe I missed something badly ;) so long and good night chregu -- PHP 5 Development Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- 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