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 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++);
}
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
