On Wednesday 27 September 2006 15:34, Michael(tm) Smith wrote:
Frans Englich <frans(_dot_)englich(_at_)telia(_dot_)com>, 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
--~------------------------------------------------------------------
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>
--~--