Re: 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:cvsuser@cvs.php.net:/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 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?

Overhead-- ?

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?

Nothing really. I use them in AxKit based sites (mostly internal Docbook server) and they work well. I just haven't used them with php (duh) and the API and some of the discussions on libxml-dev, are educational (really) but also much deeper into the C language than I can comprehend, at this point in time. Maybe that just held me off at really looking into it. But - I also like the way Sablotron works, despite it's shortcomings. ____________________________________________________ </MELVYN> void wakeup() {

        for(unsigned int cuppajava;drink();cuppajava++);

}