[PHP-DEV] Re: RFC: ext/xslt
On Sun, 2002-10-06 at 20:28, Melvyn Sopacua wrote: Sterling, At 22:20 2-10-2002, Sterling Hughes wrote: http://www.bumblebury.com/phptodo/xmsl.html my thoughts on the matter... If you really want to handle XML, XSLT and the like in PHP, the solution is to build a standardized, documented, DOM, SAX, XPath, XInclude, XPointer interface, and then have functions which wrap around these to apply XSLT transformations. I've given this some thought. And while you're right that it would be the best option, I don't see it happen any time soon, because: -- this would then make it core, same as mbstring yes, and? :)) While XML/XSLT is a relatively unimportant technology from a usefulness perspective (imho), it is a very important technology when it comes with interacting with external data sources, ie, sources that you don't have control of/cannot better design. It is essential for PHP, in order to keep up from an enterprise perspective (again, imho), to have a _very_ solid XML extension/XML scheme bundled in. -- domxml module already has an audience and is well maintained so does the xml module. but both modules are (again, imho) inadequate at this point. The domxml module is quite a bit closer, but it started out at a disadvantage because the xml module was bundled by default, and it only aimed to be a dom module. -- the libxml/libxslt libraries are quite a moving target. so is xml... To my knowledge they haven't broken bc in a while. Furthermore, they are the most actively developed, _stable_ libraries that I know of. -- not enough people/knowledge to handle it. This i find hard to believe. I've used libxml/libxslt in other projects and it took me around 2 hours to figure out most of the library and start being productive with it. The project I was doing with XML/XSLT was rather large scale and libxml/libxslt intensive, for other smaller projects it shouldn't be more than 15 minutes to figure it out. Its _certainly_ 100 x easier than figuring out sablotron, SXP, XSLT and expat interfaces. LibXML, libxslt and friends are more feature rich and DOM compliant. Further more - this would make the implementation for another backend quite difficult and possibly slow - would you then drop the libxml/libxlt interaction, or does - despite the other backend - libxml/libxslt still handle the abstraction. Libxml and libxslt are the most feature rich, fastest and most stable libraries out there. Don't take my word for it, try an internet search, studies consistently rank them better than the opensource alternatives... Another point, as a sidebar, libxml/libxslt are C projects and have a more loose license (MIT, I believe) than sablotron. C projects are generally better as PHP tries to be pure C (thus bundling sablotron would be out of the question), and also it lowers the bar for contribution. I personally prefer contributing to C projects, even though I know C++ (in fact, its _because_ I know C++ that I prefer C projects :). Such an abstraction should be easily handled, as far as I see 2 things need to be considered: 1) Adherence to current standards. At this point libxml/libxslt are fully standards compliant, as well as supporting the additions to those standards (including docbook xml/xslt transformations and certain other essential hacks). 2) Expansion. We need to find a way for providing backwards compatibility and forwards compatibility to support the old standards, and to support the new standards without having to change our interface. Also, these libraries would add up to the download size (minor). err... :) So does expat... The fact is _we need a bundled XML solution_. Currently expat only gives us SAX - we need SAX2, DOM, Xpath, Xpointer, Xinclude, XSLT, bundled together, working together flawlessly. I think the approach you've made so far, is the right one, which I'd like to extend further, with the following outlines in mind: -- Abstract x* standards and provide a default backend, which is a lightweight, straight forward approach. These modules should by default be procedural. cvs -d:pserver:[EMAIL PROTECTED]:/repository co adt take a look at the adt abstraction, we should be aiming to provide both interfaces at the same time, DOM (and therefore, XSLT and Xpath, lend themselves to OO approaches, especially when dealing with scripting languages). -- Leave domxml where it is - it is a feature-rich alternative, for people who want an object oriented interface and want to be in sync with the latest standards. -- Add DOM support on ext/xml using the Sablotron SXP interfaces. This extension is now based on expat (which will continue to be so, for existing functions), but it lacks the document creation functions. It only allows for parsing. We could also move ext/xml to ext/xml-parser but I don't think it's a good idea. IMO it will not compete with DomXML, simply because it's procedural and will
Re: [PHP-DEV] Re: RFC: ext/xslt
At 18:48 10/7/2002 +0200, Sterling Hughes wrote: On Sun, 2002-10-06 at 20:28, Melvyn Sopacua wrote: Sterling, At 22:20 2-10-2002, Sterling Hughes wrote: http://www.bumblebury.com/phptodo/xmsl.html my thoughts on the matter... If you really want to handle XML, XSLT and the like in PHP, the solution is to build a standardized, documented, DOM, SAX, XPath, XInclude, XPointer interface, and then have functions which wrap around these to apply XSLT transformations. I've given this some thought. And while you're right that it would be the best option, I don't see it happen any time soon, because: -- this would then make it core, same as mbstring yes, and? :)) Frankly? I'd rather acknowledge my limitations, than get in way over my head :) Programming a core module is just not something I'm enclined to do. Now if this would be a devoted team, with enough time to spare, I'd be willing to do my share. While XML/XSLT is a relatively unimportant technology from a usefulness perspective (imho), it is a very important technology when it comes with interacting with external data sources, ie, sources that you don't have control of/cannot better design. It is essential for PHP, in order to keep up from an enterprise perspective (again, imho), to have a _very_ solid XML extension/XML scheme bundled in. Agreed. -- domxml module already has an audience and is well maintained so does the xml module. but both modules are (again, imho) inadequate at this point. The domxml module is quite a bit closer, but it started out at a disadvantage because the xml module was bundled by default, and it only aimed to be a dom module. So this would mean, we invent yet another xml related 'extension'. Well - at least it gives users some options... -- the libxml/libxslt libraries are quite a moving target. so is xml... To my knowledge they haven't broken bc in a while. True. Furthermore, they are the most actively developed, _stable_ libraries that I know of. True also. -- not enough people/knowledge to handle it. This i find hard to believe. I've used libxml/libxslt in other projects and it took me around 2 hours to figure out most of the library and start being productive with it. Well - I haven't and I guess it's just a bit overwhelming API, when you count pages :-). The project I was doing with XML/XSLT was rather large scale and libxml/libxslt intensive, for other smaller projects it shouldn't be more than 15 minutes to figure it out. Its _certainly_ 100 x easier than figuring out sablotron, SXP, XSLT and expat interfaces. The basic transformations in Sablot we're pretty straight forward actually. And the SXP interfaces also, except for a starting point, other than a string doc. LibXML, libxslt and friends are more feature rich and DOM compliant. Yes - for the enterprise you would need it. For a basic website (a large portion of the PHP audience currently), which is for instance collecting news data from different content providers, or distributing to different sites from one source (my next larger project at work) this is not needed. The end user of course still has all the options to choose. Further more - this would make the implementation for another backend quite difficult and possibly slow - would you then drop the libxml/libxlt interaction, or does - despite the other backend - libxml/libxslt still handle the abstraction. Libxml and libxslt are the most feature rich, fastest and most stable libraries out there. Don't take my word for it, try an internet search, studies consistently rank them better than the opensource alternatives... Still leaves the question. Are you going to force the abstraction on any given module, wanting to use XML families, or is this going to be an extension, completely seperate from any other efforts. [...] Such an abstraction should be easily handled, as far as I see 2 things need to be considered: 1) Adherence to current standards. At this point libxml/libxslt are fully standards compliant, as well as supporting the additions to those standards (including docbook xml/xslt transformations and certain other essential hacks). 2) Expansion. We need to find a way for providing backwards compatibility and forwards compatibility to support the old standards, and to support the new standards without having to change our interface. [] cvs -d:pserver:[EMAIL PROTECTED]:/repository co adt take a look at the adt abstraction, we should be aiming to provide both interfaces at the same time, DOM (and therefore, XSLT and Xpath, lend themselves to OO approaches, especially when dealing with scripting languages). I'll do that. -- Add DOM support on ext/xml using the Sablotron SXP interfaces. This extension is now based on expat (which will continue to be so, for existing functions), but it lacks the document creation functions. It only allows for parsing. We could also move ext/xml to
[PHP-DEV] Re: RFC: ext/xslt
Sterling, At 22:20 2-10-2002, Sterling Hughes wrote: http://www.bumblebury.com/phptodo/xmsl.html my thoughts on the matter... If you really want to handle XML, XSLT and the like in PHP, the solution is to build a standardized, documented, DOM, SAX, XPath, XInclude, XPointer interface, and then have functions which wrap around these to apply XSLT transformations. I've given this some thought. And while you're right that it would be the best option, I don't see it happen any time soon, because: -- this would then make it core, same as mbstring -- domxml module already has an audience and is well maintained -- the libxml/libxslt libraries are quite a moving target. -- not enough people/knowledge to handle it. Further more - this would make the implementation for another backend quite difficult and possibly slow - would you then drop the libxml/libxlt interaction, or does - despite the other backend - libxml/libxslt still handle the abstraction. Also, these libraries would add up to the download size (minor). I think the approach you've made so far, is the right one, which I'd like to extend further, with the following outlines in mind: -- Abstract x* standards and provide a default backend, which is a lightweight, straight forward approach. These modules should by default be procedural. -- Leave domxml where it is - it is a feature-rich alternative, for people who want an object oriented interface and want to be in sync with the latest standards. -- Add DOM support on ext/xml using the Sablotron SXP interfaces. This extension is now based on expat (which will continue to be so, for existing functions), but it lacks the document creation functions. It only allows for parsing. We could also move ext/xml to ext/xml-parser but I don't think it's a good idea. IMO it will not compete with DomXML, simply because it's procedural and will have a minimal set of functions. Further more, it will be aimed at what's known to work and therefore lag behind published recomendations. Think Opera vs. Mozilla if you like. Last but not least, the created documents can be passed to ext/xslt for fur- ther processing, without any dump-2-string construct. -- Add ext/xpath. I'm not entirely sure, that it deserves an extension, since it's not really a programming language you can use, without using other parts of the xml family. It's nice to run an xpath query on any given string, but that's probably all that it's good for. It would make an xml-based stream-filter very easy though. For instance a 'syslog' module, which distributes the xml-based log events by quering the header. However - looking at XPath 2.0WD there are a lot more interesting things, that can warrant an extension. -- Add further extension for things like xmlsig and xml encryption, which would make secure interaction possible. These would need libraries that are specific for the task, or coded from scratch if there isn't one suitably available. All of the above is aimed at 4.4/5.0 whichever comes first. PS. Not sure what to do with XMl-Schema - it's sortof more an 'internal' of many XML dialects. It could be abstracted, but not sure what to do with it, other than 'xmlschema_validate()'. PS2: Feel free to move this to /dev/fuckoff if you feel that way :-) Met vriendelijke groeten / With kind regards, Webmaster IDG.nl Melvyn Sopacua -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RFC: ext/xslt
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 http://www.bumblebury.com/phptodo/xmsl.html my thoughts on the matter... If you really want to handle XML, XSLT and the like in PHP, the solution is to build a standardized, documented, DOM, SAX, XPath, XInclude, XPointer interface, and then have functions which wrap around these to apply XSLT transformations. Xalan/Xerces, Sablotron/Expat, and Libxslt/Libxml all provide, or aim to provide good support for these things. Libxml/Libxslt seem to be the most developed at this point, so I'd suggest bundling them and then working on a unified extension based on them... Just my 2c, not really interested in taking the project further... -Sterling 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
