All, as said in my previous message, discussion and efforts to get a solid maintenance for the xslt extension has started on the Sablotron mailinglist, after Sterling's announcement.
There are currently two main issues that are pending: Is it realistic to expect that other xslt processors will be integrated via the abstraction, that Sterling has provided? If not - this would raise whether the xslt_ namespace is correct (academic but still) and if so, how would (Sablotron) processor specific functions be integrated? Would these register under: xslt_sablot_* or would function xslt_*, which is only available for processor X, be a userland issue, where xslt_backend() would provide the means to detect availibility? The SXP interface in the Sablotron library provides DOM functions, which also allows creation of DOM documents. Exposing those, would effectively create 2 extensions with equal functionality and totally different approaches (ext/domxml and ext/xslt). Is this something we would want in core (ereg vs. preg / recode vs. iconv / shm vs. shmop)? Thread on sablotron list: http://archive.gingerall.cz/archives/public/sablot2002/msg01713.html Met vriendelijke groeten / With kind regards, Webmaster IDG.nl Melvyn Sopacua <@Logan> I spent a minute looking at my own code by accident. <@Logan> I was thinking "What the hell is this guy doing?" -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
