Re: [xsl] Opera's JavaScript API for XSLT?

Subject: Re: [xsl] Opera's JavaScript API for XSLT?
From: Frans Englich <frans.englich@xxxxxxxxx>
Date: Wed, 27 Sep 2006 16:39:01 +0200
On Wednesday 27 September 2006 14:26, Michael(tm) Smith wrote:
> Frans Englich <frans.englich@xxxxxxxxx>, 2006-09-27 15:40 +0200:
> > On Wednesday 27 September 2006 12:24, Michael(tm) Smith wrote:
> > > Note that lack of support for the XSLT document() function in
> > > Opera's implementation is a known issue.
> >
> > Out of curiosity, what implementation are you using? Have you written one
> > from scratch or have you adapted some known (open source) implementation?
> Opera's XSLT implementation is not based on any other existing
> implementations (open-source or otherwise).
> While we're on the subject, I'm also curious to hear what plans if
> any KDE has for implementing browser-side XSLT. (I'm a long-time
> KDE/Debian user.)

I've been working for a year+ on a project called Patternist[1], an 
XQuery/XSL-T 2.0/XPath 2.0 framework, a bit similar in design to Saxon. It is 
designed from the ground up to be efficient, extensible, and be able to reach 
these new technologies. The idea is to make XSL-T/XQuery available in an 
efficient and well-integrated way to KDE apps, such as Konqueror.

Currently about 75% of the XQuery test suite is passed, and once XQuery is 
stable and done, XSL-T 2.0 will be worked on. XSL-T will be a significant 
amount of work, but incomparable to starting from scratch. However, I have no 
timeframes for any of this, there's many factors involved.

> I know Apple has an implementation in Safari, but I've not heard
> whether it's something they'll be contributing back to Webcore.

They use libxslt, the well-used open source implementation. It's not very well 
integrated(they convert between different trees, if I recall correctly), but 
XSL-T being inefficiently integrated is more or less the standard among web 
browsers. Opera is perhaps an exception. If I recall correctly, the 
document() function is broken on Safari too.

Their glue is open source'd and in either way it's relatively speaking not 
much work to connect libxslt to Konqueror/KHTML. The reason I haven't started 
working on this is that I'm aiming higher: I want something cleanly 
integrated and therefore breaking the trend of hacky XSL-T solutions in 
browsers, and I want good features: XSL-T 2.0 and good error reporting.

Another reason is that there's a lot of tumult in this area, see for example:



No releases yet. API documentation is here: 

However, Sourcefourge is down when I write this.

Current Thread