Symphony.

OK, since symphony does not use browser-based transformation, you are not limited to using XSLT 1.0 Why then you are not using any of the XSTL 2.0 features? Doesn’t php libxslt support them?

No, libxslt doesn’t support XSLT 2.0.

I see. I know php has exslt extension. What does it include?

If you browse through the functions here, it’ll tell you at the bottom of each page whether it’s supported in libxslt. Not sure if there’s a list anywhere of all them…

Worth noting that it is possible to set up a custom server environment that uses another XSLT library (Sablotron, for instance) rather than libxslt.

@mr_smith,

Among other things, the exslt functions allow you to:

• Apply templates to Result Tree Fragments (using node-set())
• Evaluate strings as attribute value templates (using evaluate())
• Write output to files using ‘document’

While not as robust as xslt 2, these capabilities do get you around some of the more glaring limitaitons of v.1, and they are fairly common in any env that has libxslt.

Old thread, I know. But recently the XSLT 2.0 adoption has been discussed on the XSL List. In that thread a Java implementation of a PHP interpreter, called Caucho, is mentioned.

Could this be an alternative for using XSLT 2.0 with Symphony? Anyone tried the combo Caucho + Saxon?

From the brief look of Caucho, it looks like it’s going the other way around. Caucho is a Java implementation of PHP. The opposite is required if Symphony is to run with Saxon.

Yes, but will we ever see a implementation of XSLT 2.0 in libxslt (or similar)? As Michael Kay sais:

Unfortunately there seems to be a shortage of people prepared to invest what’s probably 5 man years of (top-class) programming effort – or more like 50 years if you’re a big corporation, where things take longer – into producing something that then gets given away for free. I really can’t imagine why.

Great things happens in the world of open source – but this seem to be a too daunting task for the OSS-community, or?

We already have a working prototype server running Saxon with Symphony using a PHP JAVA bridge. So it’s definitely possible. However, this isn’t something that can be easily replicated.

We plan to offer hosting services down the track that offers XSLT 2.0 support.

very interesting, allen. how stable is the PHP JAVA bridge implementation?

So far so stable; no crashes or timeouts and we’ve been benchmarking it pretty hard. There is a slight performance overhead of around 2-3% per thread, but we can compensate for that. We have a number of hurdles to get over to make installation a one step process rather than the two hour dependancy waste land that it is at the moment, but we’re not far off reaching that milestone.

Once we get there I’ll blog about it in more detail.

That is awesome! 2-3% performance loss in exchange for XSLT 2.0, I could live with that too!

This hosting service you’re talking about, when will we get more information about it?

Soon I hope!

We’re in active development at the moment and are bursting to tell you all about it…

@Joseph - are y'all still testing the PHP-Java bridge to enable XSLT 2.0?

I'd also be interested in how this is going. Recently hit some difficulties which would be eased by the ability to use XSLT 2.

Is this a stupid suggestion: could you potentially have a RESTful web service which serves only to provide XSLT 2.0 support (i.e. a web server running Java/Saxon). Our Symphony builds pass over the page XML and XSLT to this server, it processes, and returns the result. I imagine there'd be a considerable overhead caused by the HTTP traffic, but it might work.

Or if you're so inclined, here's a tutorial I found that documents how to get a Java bridge running.

Attachments:

Marco_(editor)_Polo-php_architect_(March_2003)-Business_Information_Group(2003).pdf

I've setup Java bridge + Saxon a few times already, the last time it was pretty close in performance to the build in libxml extension. Problem is, it's not portable at all.

We need to hire a Java guru, to see if a simple package can be handed out to people who wish to use it.

RESTful would have considerable overhead, but it is possible that it wouldn't matter with a good caching scheme.

I'll preface this comment with a non-sense warning, since I really don't know a lot (read: "anything at all") when it comes to the internals of Symphony...

Is it the case that actually getting the Java Bridge + Saxon going so it'll transform pages isn't too difficult, but ensuring that it's integrated with Symphony as tightly as libxslt is where most of the work lies? Presumably, Symphony would need quite a few modifications to ensure things like error handling/reporting still works nicely? Is that where most of the effort from Joseph & co is centred?

Please correct me if I'm way off the mark.

So no new news from the official effort to get Saxon + Symphony working? I noticed Joseph's post saying 'Soon I hope' was from August '09. Any update?