Re: [xsl] XSLT 2.0 support in KDE [was: Opera's JavaScript API for XSLT?]

[Frans Englich <frans.englich@xxxxxxxxx>]

On Wednesday 27 September 2006 15:34, Michael(tm) Smith wrote:
> Frans Englich <frans.englich@xxxxxxxxx>, 2006-09-27 16:39 +0200:
> > 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.
>
> Wow. Having support for browser-side XSLT 2.0 transformations
> would certainly seem to make it unique. Or even just having a XSLT
> 2.0 library available to apps in the way that libxslt is now.

Yeah, the open source community is lagging a bit behind on XQuery/XSL-T 2.0 so 
hopefully that hole will be filled in some way or another. The reason I'm 
going for XSL-T 2.0 instead of 1.0 is namely because it's something worth to 
mention. Deploying 1.0 is only a mandatory "catching up" where one can only 
finish last.

> Is there any particular reason why it needs to be limited to use
> by KDE apps? I see that the homepage mentions that it has
> dependencies on QtCore and the KDateTime class from kdecore. Why?

The QtCore dependency will never go away. It provides things like 
string/unicode handling, basic container classes, regexp, thread safety, 
(some) date/time handling, and portability. However, I don't see this as a 
problem. QtCore is small and fast.

KDateTime(in kdelibs' kdecore library) is used for zone offset handling, which 
Qt currently has no support for. Dropping kdecore, by somewhere duplicating 
the KDateTime functionality(either in Qt or in Patternist) and the KDE 
dependency is gone. The KDE dependency will go away at somepoint, but I don't 
know the details at this point.

> As far as I know libxslt (for the sake of comparison) doesn't have
> any similar dependencies (well, except for relying on the standard
> C library, if you want to count that).

One always want less dependencies. But if one wants functionality there is two 
alternatives: either get a dependency or re-invent the dependency.

libxml2/libxslt have largely re-invented stuff instead of having dependencies, 
and if it wants to get the same amount of functionality Patternist has and 
will have, they will have to write stuff like Unicode handling and so on. And 
that is tons of work. The result would be worse. With Qt, one already have 
well-defined contracts, well-tested and well-documented APIs(something 
libxml2 notably lacks).

So the reasons are "functionality" and to finish in a reasonable time frame. I 
also believe it is much easier for users to use Qt/Patternist than only 
Patternist plus a bunch of custom, never-seen APIs for handling basic stuff 
like string handling.

The other day I got tipped about Arabica[1], roughly an XPath 1.0 
implementation in C++, where all classes are parameterized to be able to 
handle several different string types. But I don't see how that is possible 
with XPath 2.0(and related host languages) because it's radically more 
complex.


Cheers,

		Frans

1.
http://www.jezuk.co.uk/cgi-bin/view/SAX