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 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. > Why is really the question? 1) The sablotron libraries are inferior from a functionality and stability perspective. They are also much less used (libxml and libxslt are the basis for gnome's xml/xslt handling). 2) Sablotron is C++, that automatically stops us from bundling. > -- 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()'. > Again, the question that this begs is: why? Why not just use domxml as a base and build it into an all inclusive extension? Why not bundle the most stable, and fastest libraries? The libraries written in the same language as PHP, the most popular libraries, and the libraries that have the most support for standards?? I see no technical reason not to use libxml and libxslt. At this point in time, they are the best. They have the most development steam, and the largest user base. Perhaps you can tell me what you don't like about libxml/libxslt? -Sterling -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
