What is my name?

[Cornelius Schumacher]

On Monday 29 May 2006 23:10, Frans Englich wrote:
>
> I am personally very interested in XQuery in the KDE-context(what a
> surprise). For those who doesn't know XQuery, it is basically SQL for
> XML(XML Query == XQuery).

Well, in contrast to SQL XQuery is missing the data manipulation part.

> Combined with that the data model is abstracted, 
> means that we in KDE can let loose a full fledged query engine on any data
> that can be represented in a hierachial way. In other words, it doesn't
> have to be "XML" as in "those text files" that is queries/searched, but
> pretty much everything. Later one one can also implement Full Text
> searching.[1]

How useful is XQuery outside of a database context? Without the help of a 
database backend it seems to be a bit questionable, if the enormous 
flexibility of XQuery is worth the performance.

> It would probably be healthy to brainstorm a bit on the possibilities of
> this on k-c-d or similar, to open up opportunities, and so on.

This sounds like a good idea, but I'm not really sure that would lead to 
anywhere, when it's not clear yet how somebody would be able to use it a all 
given the lack of a public API.

> > Isn't this tied to the rest of KDom?
>
> Actually not, it will be the other way around; KHTML/KDOM will depend on
> the XPath/XSL-T/XQuery code. KDOM/KHTML's trees are specialized for
> rendering/web compatibility, leading to performance impacts for those who
> only need data representation(and they neither allow different tree
> implementations) and they also bring in dependencies on X11 and what not :)
> We'll probably depend on kxmlcore beyond kdecore/qtcore, though.
>
> May I ask where your interest stems from? Identity constrains in XML
> Schema? XPath need in XForms? Our parser/tokenizers are already geared
> toward different XQuery/XPath dialects, so doing that kind of stuff is on
> the roadmap.

I would love to have an XPath implementation which could seamlessly be used in 
existing XML processing code. e.g. applying an XPath to a QDom document and 
getting a QDomElement as result.

It would also be interesting to have a XSLT implementation which could be used 
instead of libxslt. But I'm not sure how much we would be able to gain from 
it. A very simple wrapper of libxslt already provides most of the API one 
would need and I don't know, if the performance of a new implementation would 
be comparable to libxslt. Would be interesting to port for example the help 
kioslave to your xslt lib and compare the performance. As with XPath it might 
be interesting to be able to apply XSLTs to existing represenations of XML 
data, not only text, but also a QDom tree.

XQuery is quite a beast, so I don't know how interesting this would be to 
application developers. It still would be nice to have an implementation. The 
API for this could be very simple as well when it just uses existing XML 
representations.

I would really like to try your implementation. If it doesn't depend on KDom 
it should be possible to create something like a stand-alone package which 
already works now, right?

-- 
Cornelius Schumacher <schumacher at kde.org>