PHP5 and XML - Worth a Rethink

by Kurt Cagle

I have a class I'm preparing for tomorrow at the 2006 GeoWeb conference on the use of SVG in GIS. I'll be posting those notes tomorrow, but tonight, as I'm basically doing my damndest NOT to work on the class for tomorrow (serious procrastination issues here) I thought I'd just make a couple of quick notes about PHP5.

I have to admit it, I have more than a little bit of a bias toward the underdog, especially when that underdog isn't just one big mega-corp going after another big mega-corp. I think that's part of the reason I've always found myself cheering for PHP, even when I could readily admit that there were problems with the language. There were - PHP3 was, while not exactly slow, hardly known for its speed-demon like characteristics. It didn't really have much in the way of oomph when it came to object-oriented programming, which, while I personally believe OOP to have an upper boundary to the level of complexity it can handle, I still think that most contemporary languages should be able to support OOP as a matter of course.

Yet my biggest pet peeve with PHP, something that kept me from adopting it in any meaningful way, was Sablotron, PHP's erstwhile XSLT library. With Sablotron you had to install it directly, rather than as part of the normal install for PHP, which meant that for hosted sites, you were out of luck even getting it in many cases. The transformer was slow and buggy and non-standard, and while it has improved over the years, it was always something of an also ran within the XSLT world.


4 Comments

ac
2006-07-25 05:07:21
I have a like/ambivalence relationship with PHP. The community, when I was using it seriously, was helpful and friendly, and, while not inherent to the language, is an important factor in deciding whether to use it. However, its origins as a souped-up template language make it harder to work with in some situations. I've just never had the overall experience be as 'slick' as I'd like it to be, but I'm willing to chalk that up to the size of the library and the fact I don't work with it all the time. It is, generally, pretty gratifying to code something up in PHP and see results pretty quickly.


Agreed on all counts about libxml2/libxslt. Generally it's a joy to work with. Ruby's 'native' XML handling leaves a bit to be desired, but with the recent popularity of the language, it looks like the Ruby bindings for both are now available as gems (libxml-ruby and libxslt-ruby respectively).


Bruce
2006-07-25 05:37:41
Although, there are problems with libxslt, such as not being able to sort extended unicode characters. I consider that bug serious enough that I rarely use it.
Sylvain Hellegouarch
2006-07-25 08:30:54
I've used PHP 3,4 and 5 and each time I was scratching my head withe language. The PHP library is great but hardly coherent and quite randomy documented.


libxml and libxslt are great but my grief against it is its poor way to give you information when an error occurs. Mind you it might have changed since the last time I checked.

James Fuller
2006-07-26 01:03:33
Hello Kurt,


would like to add a few comments re sablotron, as I share offices with the main developers and have delved deep into its codebase over the past 2 years;


I think that everyone experienced the 'install nightmare' with sablotron on PHP; though want to point out that the problem wasn't sablotron...the problem was 9 times out 10 to do with expat and how php (or sablotron) linked to it.


in any event this resulted in 'i want to perform XSLT transforms and I cant do it because of sablotron'...which was a little unfair....I think that sabloton's php usage was overlooked by the original developers because they are a group of perl geeks in Prague...and probably would say that the real sleeper of this decade will be Perl6.


As for standards, sablotron does have some noticable gaps, but remember most of its development occurred way back a few years ago, a lot of work has happened with bug fixing over these years.


look out for new versions of sablotron; being written in c/c++ means that it has an extremely small footprint....as well as being fast...who knows perhaps there is a XSLT v2.0 processor in the future; though I think this would only be on the basis of a solid fully compliant XSLT v1.0 release coming out in the coarse of this year.


cheers, Jim Fuller