Symphony.

No, we don't have any news on this front at this point in time, I'm afraid. This is however on all of our minds so we will be looking at this again once our existing slate of work is complete and ready take this on again.

Apologies for the delayed response -

Our focus was on getting a stable Saxon/Symphony setup working. This was successful, however the stack performance was not really usable for anything other than the smallest of sites. As a result we dropped this effort, focusing instead on creating a reusable image for high performance delivery.

Update @14:45: Heh - I had this page loaded from a few days ago and hadn't see Allen's comment

Guys, and what about fast'n'furious NGINX? :-)) AFAIK, it has several modules for XSLT2 transforms. proof link: http://xxslt.sourceforge.net/?id=xslt2

Nginx is cool, not used it myself yet, but heard good things on here though.

I think the goal is to support the greater requirement, which unfortunately has no native support for XSLT 2.

If a user can control the environments that they host the sites on, and want to support XSLT 2, then they have the choice, but most like myself don't and have to stick with libxsl.

Lots of the functionality that XSLT 2 adds, can be achieved in XSLT 1, using EXSL and other functions, it's just a longer way round and a harder learning curve.

nginx is very fast when it comes to:

• serving static files
• load balancing

If we talk about Symphony websites (where PHP has to do the heavy lifting), you will have a hard time to get an nginx setup significantly faster. I tested this myself. Without going into too much detail here, in the end I decided to use Apache/mod_php for stability reasons. This combination is rock solid.

Guys, what i meant was to eliminate the words "Symphony websites where PHP has to do the heavy lifting". Suppose the web server could achieve these tasks in much quicker and elegant way with xslt/xslt2 modules. Or am i wrong? ;-)

XSLT is typically the least resource intensive aspect of the system stack. Its role in a system is the transformation of content to presentation. This only makes up one part of many in a fully functioning system, which must also account for authentication, URL rewriting, database management and many other aspects that a system needs to manage.

The shift to XSLT 2.0 may see some performance improvements, although it'd be negligible in the grand scheme of things. I'd argue that the added complexity that XPath 2.0 brings and the increase in functionality scope for XSLT 2.0 won't necessarily make the transformation processing generally faster. The improvement moving to 2.0 would be predominantly for coding convenience.

" = on the money

For me the possibility to use XSLT 2.0 within the Symphony framework would be very attractive and useful.

Any news on the direction the above mentioned initiatives are taking?

Personally, i really love XSLT / XPath 2.0, but I don't think it will ever by implemented in LibXslt (last change to this library was in 2009). Without libxslt support, the PHP community will not implement xslt 2.0, especially since xslt 1.0 is good enough (especially if extended with EXSLT).

The Java brigde option to enable the use of Saxon is really not an option, there is no gain in adding a dependency to a platform Symphony is not using. Supporting this would raise the question why the entire framework is not ported to Java (and the person asking would have a point in asking). Since there is no desire to port Symphony to Java, I'm afraid the quest for XSLT 2.0 support ends here.

The best bet would be to stalk the PHP community, which in turn might start stalking the people at xmlsoft.org. But being available for 5 years already, I'm afraid XSLT 2.0 is not going to be implemented in PHP at all.

Do you guys think that we are stuck forever with XSLT 1.0 + EXSLT? Or is there a way to throw money somewhere in order to make it happen? :-)

XSLT 3.0 and XPath 3.0 are coming, see the list of changes since XLST 2.0 (the biggest addition seems to be the packages).

See the Symphony Experts Panel discussion about the future of XSLT in Symphony. Allen Chang has been working with a Java bridge that enables access to Sablotron as an XSLT 2.0 processor.

The likelihood of libxslt, on which PHP depends for XSLT 1.0, being updated for XSLT 2.0 compatibility appears to be slim at the moment, primarily because of the lack of interest in the mainstream PHP development community. Increase adoption of XSLT in PHP and the future of libxslt may change.

Thanks for noting the working drafts for XSLT 3.0 and XPath 3.0. That will be very interesting to follow.

Thanks for the link to the Symphony Experts Panel!

Interesting, it appears that Saxon is also available on .NET. It would be interesting to find out if that implementation would run faster than the Java-based one when being called from a webserver.

Edit: Actually, it looks lite the .NET part is just a wrapper for the Java code.

I've been thinking about this somewhat lately, and I think that not having XSLT 2 in PHP is just pathetic, and poor form of the PHP community to be honest.

How much do we think this would cost to pay someone to do it? Maybe we could all donate sums of money to a pot to hire someone to do this.

Then we could donate it to PHP as a marketing exercise.

Don't forget that PHP itself is basically just a wrapper for all those basic features that can be found somewhere else in the operating system. So the problem isn't with PHP but the lack of a more capable standard Unix XSLT-library (and to some extent even the XML-library).

Those two libs are very old (and very stable) and there apparently hasn't been the need to have XSLT 2.0 in Unix itself so they never got updated.

Apparently, libxml2 won't be able to do essential XSLT 2.0 stuff like schema awareness etc. so before you'd go and create a new XSLT-library you'd have to start the XML-bit from scratch. After that you could create a new libxslt. A huge task given it took experts 13 years to create both libxml and libxslt in the form we know them now.

And then... You'd have to lobby for actual Linux distributions to ship your new implementation. Otherwise you'd never get PHP to adopt the new libraries or have shared hosts offer XSLT 2.0 to end users.

All in all I'd say it would take more than 10 years to have an implementation that's as reliable and ubiquitous as the one we have now.

I'd say that manpower should definitely instead be invested in improving the bridge to i.e. Saxon, an already really powerful and well-maintained processor. Yes, that would require all those fancy XSLT 2.0 folks to jump through extra hoops to get the new features. But let's be honest, 99% percent of the time you won't need it anyways.

Yes, it will require a C/C++ XSLT 2.0 library: Java / .NET calls from PHP will never be a reasonable solution.

And it seems that writing a XSLT library is a very complicated stuff. And when this hypothetical library will be available, it will still need to write a PHP extension.

Maybe libxsl can be extended to support XSLT 2.0? Maybe Saxon can be ported to C++? Maybe someone would like to do it, but just need some support?

I have no idea :-)

Have you seen the Rails.app project on Kickstarter?

EDIT: Just saw your edit Nils, and now I’m sad and hopeless, ha ha.

I never actually realised it was more to do with Unix than PHP, that actually makes sense now, thanks Nils.

It is a real shame that XSLT in general isn't more popular, but then again, people always want what seems easier, which puts XSLT out of the game.

We definitely should assist in improving that bridge then. Personally, I came across a need for XSLT 2 xPath functions, but found a way around it using templates instead. I think it would just make our lives a little easier, but I am happy with what we have.

Wow, I'm even more confused now about how modernised XPath and XSLT support can be included on the server than I was before I read it. :)

The Saxon bridge option sounds promising but probably not something that everyone will be able to setup for themselves. Would still be good to see some working examples and implementation details though as options are always good.

Other than that it sounds like lobbying is required en masse to let people know that XML is alive and kicking and desperately trying to step it up a notch. It's surprising really considering how globally popular and pivotal XML is across many languages and platforms. How did support for it's family of tools get so neglected? Especially considering they're web standards.

Pitch forks and burning torches at the ready.

Last time I checked, Nokia has taken the baton to implement XSLT 2.0 into libXSLT as they apparently use it quite extensively. I've not checked back on this for a while now, but I've never wanted a phone company to succeed so much in my life!