On Wednesday 27 September 2006 14:26, Michael(tm) Smith wrote:
Frans Englich <frans(_dot_)englich(_at_)telia(_dot_)com>, 2006-09-27 15:40
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
I've been working for a year+ on a project called Patternist, 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.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>