Search

Just want to see other people's opinion on this matter.

Reason I'm starting this discussion is that just a few days ago I checked back on the status of updating libxslt to xslt2 and it's still as dead as a few years ago.

I remember there were some newsgroup discussion a few years ago that basically comes down to - libxslt satisfies most people's needs, and it costs too much to develop libxslt 2.0 and then gives it away for free.

I've beginnng to see extensions for Symphony that starts to require the exslt extension, and that's just yet more server requirements that might discourage a potential adopter.

Don't get me wrong, xslt is still heavily used for document processing outside of the web, but xslt on the web is pretty much been dependent on just libxslt - for general users I mean, I do know there are java implementations that requires a lot of work and control of the server to implement/integrate - and it's just been harder and harder to get functionality implemented in it without roundabout hacks that won't be needed in xslt2, or depend on exslt which is yet another non-common web configuration.

The fact that xslt is verbose even without hacks doesn't help at all.

With still no light at the end of the tunnel, I can't help but wonder by being reliant on xslt and in effect libxslt, it's becoming akin to going down with a sinking ship.

When I really think about it, Symphony's main advantage to me is really more about the architectural flexibility than the fact that it chooses to use xslt. I'm pretty sure it would work just as well for me if it implements a good PHP-based templating system.

Hey, maybe it's just me.

Related previous discussion: JSON vs XML API's and Symphony and What do you love about XSLT?.

For most of us, XSLT is one of the main reasons we use Symphony in the first place.

I've beginnng to see extensions for Symphony that starts to require the exslt extension, and that's just yet more server requirements that might discourage a potential adopter.

Are you referring to the EXSLT Function Manager extension? This naturally relies on EXSLT because that's exactly what the extension is there for — exposing your own functions using EXSLT. This is the only one to my knowledge.

's just been harder and harder to get functionality implemented in it without roundabout hacks that won't be needed in xslt2, or depend on exslt which is yet another non-common web configuration

EXSLT is pretty standard in the PHP world — it's included with PHP5 by default and I've yet to come across a shared hosting provides that does not have it enabled. It's not like libxml is this weird third party component that needs to be installed — it's a standard PHP package like curl or GD. Could you give a few examples maybe, so I can understand better?

I've had a look through XSLT 2.0 and have only seen one or two things that would benefit my daily workflow with Symphony, namely regular expressions and nodesets. The former we tend to require very infrequently, since views should be really logic-light, and node-set conversion can be handled by the EXSLT node-set function anyway.

it would work just as well for me if it implements a good PHP-based templating system

Maybe so. But one of the areas XSLT excels is keeping your views light. I've worked with MVC frameworks such as Zend or CodeIgniter where views are written as HTML interspersed with PHP, and to my eyes it's not pretty. There's a tendency to include too much logic in views because it is easy to do so ("where should this PHP go, in the controller or the view?"), whereas using XSLT enforces strict separation — let your page events and data sources (models/controllers) do the work and provide their result (XML), and simply transform that into something else using XSLT.

I've thought about this before, and it is probably actually possible (or nearly possible, some extra delegates might be required) to write an extension for Symphony that lets you use an alternative templating language entirely. But because Symphony speaks XML almost everywhere, XSLT is the obvious choice.

With still no light at the end of the tunnel, I can't help but wonder by being reliant on xslt and in effect libxslt, it's becoming akin to going down with a sinking ship.

Maybe you simply don't like XSLT itself (rather than the fact there is no XSLT 2.0 support)? I've yet to see an alternative templating language that is as powerful (having used things like HAML, Moustache, Smarty). XSLT doesn't need to be verbose, and you shouldn't need to be hacking things. In fact many people coo over XSLT's simplicity and architectural beauty.

XML and XSLT isn't is in vogue as it once was, but that doesn't necessarily mean it isn't a sensible technology to use.

If anything on the web can really be called future proof, it would be a language, like XSLT, that exists as a W3C standard.

I also think it’s cool that my views don’t really care what programming language I’m using. Provided it continues to generate the XML output my views expect, I could replace the backend with something running Python or Java, and my views would still work. Would one ever need (or want) to take advantage of this? I don’t know … but the future is full of such unknowns, and in that light, the separation that XSLT enforces between the view and the programming logic seems beneficial when it comes to future-proofing one’s sites.

Many good points raised, but it is not about xslt itself's future-proofness, it is about libxslt's future-proofness, which is pretty much single-handedly powering xslt on the web.

Is XSLT 1.0 really all everyone would ever need? With absolutely no need for update forever?

The main worry I have with libxslt is that the project's pretty much dead, no update possible at this point.

No matter how small the inconvenience not having XSLT 2.0 is giving you right now, it will only get bigger, since features with NEVER get added at this rate.

As time goes on, wouldn't tiny annoyances/problems just snowball into something unmanageable?

As time goes on, wouldn't tiny annoyances/problems just snowball into something unmanageable?

And that’s when you redesign and refactor.

One could ditch the XML/XSLT paradigm for something newer/better. This could always happen. It would be silly to claim that any paradigm is the One Paradigm to Rule Them All and will be sufficient for one’s needs from now into perpetuity. Sites outgrow their design paradigms all the time, and the solution is to redesign the site and deploy new paradigms. Symphony, PHP, XML, XSLT … all these may one day fade into the background as newer technologies replace them. You could be right that there may come a time when using libxslt limits the types of enhancements one can make to one’s current sites. This possibility does not, by itself, mean that using XML/XSLT for now is a poor choice. Regardless of libsxlt’s “future-proofness”, it is at least sustainable, in the sense that it’s not suddenly going to stop working.

Alternatively, if dissatisfaction with the performance of libxslt reaches a critical mass, the open source community could step in and update or fork libxslt. The fact that no one has done it yet doesn’t preclude it from happening in the future.

By all means, don’t use XSLT/libxslt if you feel another templating system suits your needs better. But just because a templating system is in active development does not mean it is future proof—after all, development on it could inexplicably halt tomorrow!

Nothing lasts forever.

To my knowledge the xslt specification has been frozen back in 1999 and that same language is still in use today. The fact they get it right after (apparently) only one year of discussion doesn't mean it isn't as good as technologies that keep evolving everyday (if that could be considered good, either).

If you were to write your views in PHP you would have to deal with the current stable release (5.3) with an eye on the just released 5.4 and hoping to not break something that has been deprecated in PHP 6. Do you remember how fun it was the switch between PHP 4 and 5? Is this really something you could call future proof?

Xslt is one of the few technologies I'm happy to have in my bag and possibly the only I wouldn't trade for anything else, whether PHP is going to be replaced by node.js and mysql by nosql db (or not) and so on.

No matter how small the inconvenience not having XSLT 2.0 is giving you right now, it will only get bigger, since features with NEVER get added at this rate.

XSLT is a templating language, so I wouldn't expect to see new features in it, and like earlier stated by Nick, it does everything I would want, apart from regex, the features would be in generating the data that needs templating, and that's PHP

I wouldn't call XSLT a dead language quite yet. There are people who are passionate enough about it to be investing time in projects like Frameless: XSLT 2.0 for the Web. Read Robbert Boersma's article on XSLT for hipsters, or how to win the demojam.

The only thing stopping XSLT, ironically, is the web standards community. If we can get widespread buy in, people will develop XSLT 2.0. Empower user experience designers to be able to have complete control over their markup by using XSLT. In my mind, Symphony is the tool of choice for this. I've been using it for HTML/CSS prototypes for the past five years. I'd never use anything else, if I had the choice.

The only reason CSS is as popular as it is now is because there were evangelists like Zeldman, Shea, Bowman, Cedarholm, Clarke, etc. Inexplicably, Zeldman and company have not mentioned XSLT on A List Apart since 2002: Using XML. When I asked the Web Directions panel why we rely on proprietary APIs instead of open standards such as XSLT, Simon Willison and Jeremy Keith were oddly hostile to the idea of XSLT. (Search for XSLT in the transcript of the Web Directions panel discussion.) So, that night, I wrote a rebuttal to their argument.

I would challenge Zeldman to champion the topic of XSLT and write the next best seller: XSLT for Designers (and he could purchase the domain from me). I would write that book, if there were no other takers, but it's one of the many projects I have started but have no time for.

To make time, this coming week I am taking time off from work to consider my options. Because the book has to be written.

To put it in perspective, Apache recently released a new version of their web server, which probably runs 95% of all our websites (and about half the sites on the web). The previous release was six years ago.

When we use XSLT with Symphony, we're only using a small set of what the language can do. Flick through an XSLT book and you'll find so much that you can discard because it simply isn't relevant. Building websites with Symphony and XSLT just scratches the surface, so in my mind libxml in its current guise, and XSLT 1.0, is more than appropriate.

To make time, this coming week I am taking time off from work to consider my options. Because the book has to be written.

Awesome!

Nick it's also good to state that of the lot of things that we don't currently use I am sure there's plenty of stuff that would be useful. For the right task obviously.

A couple of weeks ago I unearthed a piece of XSLT which at least in my opinion is a great way of including other templates, whose name you might not necessarily know. Stuff like sidebar widgets etc... Its one of the must-have things for me when developing widget based systems now because it makes it so much easier.

Prior to this I had been playing around XSLT for around a year, and I'm pretty sure that there is more stuff to learn that might turn out useful.

As long as XSLT can render what I have in mind one way or another I'm happy. Being honest I still do find it much easier to learn and understand than other templating languages, yes there's a learning curve but its much easier then say building a WordPress template.

Many good points raised, but it is not about xslt itself's future-proofness, it is about libxslt's future-proofness, which is pretty much single-handedly powering xslt on the web.

Actually, Saxon is powering a sizeable portion of the XSLT-based web also.

No matter how small the inconvenience not having XSLT 2.0 is giving you right now, it will only get bigger, since features with NEVER get added at this rate.

Despite being a huge fan of XSLT 2.0, I'm not convinced it's a better solution over XSLT 1.0 for the web, but I'll leave this discussion for another time as my points would veer this discussion off course.

XSLT is not a full-fledged programming language, and it absolutely shouldn't be. As a template language, its syntax and concept ought to be elegant and precise. There are only a handful of XSLT instructions to learn and the declarative nature of the language lends itself well with the concept of semantic web. It's also coupled with a very powerful node traversal tool (XPath) which runs circles around any other node traversal languages I know.

Bottom line is, the philosophy we abide by which made Symphony what it is today fits snugly with everything that XSLT offers.

Last point; Symphony does not live and die by XSLT, that would sort of defeat the purpose of view and content separation. If something better comes along, there is no reason why Symphony cannot adopt it.

All said, I have yet to find a template language that is as solid, beautiful and elegant as XSLT.

P.S. I'm currently working on getting Symphony running with Saxon XSLT 2.0--and no, not in the old PHP-JAVA bridge way, but done natively getting PHP compiled into JVM. I did say that XSLT 2.0 wouldn't necessarily be better than 1.0, but Saxon as a processor is very fast. The one other benefit is Saxon's ability to do custom output modes, so native HTML5 mode would come standard (yay).

I've come to 'like' XSLT through using it with Symphony. I say 'like' because I feel it's a bit of a love/hate thing. I love the flexibility etc. but I hate the fact that some 'simple' things are so darn hard. Case in point: using a simple HTML5 doctype, or HTML5 HTML indentation (I know I've spent way too much time ranting on these things) :/

Besides the fact that there's quite a steep learning curve for XSLT there's these little issues that I believe prevent many dev's from picking it up. XSLT is advertised as giving one complete control over the output but seems incapable of outputting a simple Document type or (libxslt) indenting one's code properly…

I love Symphony, 'like' XSLT and understand where you are coming from but have to agree with Shaw on this:

Symphony's main advantage to me is really more about the architectural flexibility than the fact that it chooses to use xslt.

Just my $0.02…

I haven't decided yet if i love XSLT or not... i can see the elegance in some cases.

But also, certain stuff is way to complicated to achieve. If you know PHP like most of us do, you feel a little bit like your hands are tied behind your back, especially in the beginning.

I believe this keeps some people away, who'd rather just do some hack n slash php in WordPress template files (i was one of them ;) ).

The XML specification hasn't changed since 2008. Does that mean using XML is not future proof?

The XSLT standard might not be evolving and has stopped in 2007 with the W3C recommendation for XSLT 2.0, there is still active development of the related XPath specification (the last version of the XPath 3.0 working draft is dated december 2011). So the fact that the 'templating' specification hasn't change, doesn't make the design pattern of using XML, XSLT and XPath less valid.

Due to this, Saxon is also still actively releasing with all features that XSLT and XPath can offer.

So I think it is safe to say that there is nothing wrong with XSLT, there is something wrong with the PHP community not stepping up to demand support for the latest specifications. Although, as many already suggested, XSLT 1.0 is good enough for the type of projects we work on.

And now for the ranting part: HTML5 is considered future proof, yet if you look a bit closer, it is nothing more than a complete failure of the W3C Memberships to set aside differences. The HTML5 spec is a bad compromise and should never have existed.

Say hail to XHTML 2.0... even though it died in 2006 and was officially buried in 2010. That would have been future proof.

For what it's worth, here is my semi-newbie input. I spent 18 months with symphony full time, doing 3 larger one-person projects. I'm a total fan of symphony, and I'm sticking to it for that reason, but i share davidhunds sentiment of 'love/hate' with XSLT.

My main problem with it is that symphony encourages me to use XSL for everything, since the step to custom datasources seems big to me (at least from this side, having not taken it :), even that I know php.

And some seemingly easy things are difficult. I recently gave up on finding the previous element in a grouped, sorted and recursive structure, and solved it client side instead :)

My point is that I'm using symphony for it's amazingly dynamic and abstracted data modelling capabilities (the subsection manager is a hit with the clients), not because of XSL.

J

I stick with Symphony for many reasons — the first being XSLT. I love XSLT.

I stick with Symphony for many reasons — the first being XSLT. I love XSLT.

Hear Hear!

The possibility to throw in some php wouldn't hurt.

I'd like to have something like /utilities/ that's like /php-functions/ that can be called from XSLT in emergency situations.

Like

<xsl:call-function name="stringModifier">
        <xsl:with-param name="string" select="/data/string" />

would run...

stringModifier($string){} from in an included /php-functions/ file..

This might be impossible, non standard and just stupid, but it's a tempting thought for me :)

I'd like to have something like /utilities/ that's like /php-functions/ that can be called from XSLT in emergency situations.

This is when you could use the EXSL Function Manager extension.

I fell in love with Symphony on first sight, without knowing XSLT at all. After learning it, the love just got stronger.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details