What is my name?

[Frans Englich]

On Sunday 28 May 2006 12:29, Cornelius Schumacher wrote:
> On Friday 26 May 2006 19:24, Frans Englich wrote:
> > A name, is badly needed for KDE's XPath 2.0/XQuery 1.0/XSL-T 2.0
> > implementation. The stack will likely be quite high profile and visible,
> > so a good name means *a lot*. Especially, when the current one is such
> > generic and misleading as KXPath..
>
> Where can I find more information about this code?

First of all, I am available for answering of any questions regarding this, so 
feel free to shoot.

> Are there API docs 
> available online somewhere?

Not online, but it's relatively easy to generate it:

1. Check out https://svn.kde.org/home/kde/trunk/kdenonbeta/kdom/xpath
2. Run `doxygen` in kdom/xpath/
3. Browse kdom/xpath/html/index.html

The code is surely  playing hard-to-get right now: it only compiles against a 
certain revision of kdelibs trunk. There are no "public" APIs available but 
there will essentially be two approahes: 1) via the W3C DOM XPath Module[1]
(XPath 1.0 only) which is implemented in xpath/dom/ and will be available 
when integrated with KDOM/KHTML, and 2) via whatever public APIs people would 
like.

So, starting to use it *right* now is a bit tricky, but it's not far from 
there. The code is very capable, and a kdelibs inclusion is not that far 
away. It also depends on what interests people have; if people want to start 
integrating/using it, an inclusion can be done earlier rather than later.

But a name is needed for kdelibs inclusion! Hence my fishing for one.

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). 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]

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.

The implementation has advanced linearly in a stable way for long, is 
statically typed with already many basic optimizations, and is strongly 
regression tested.[2]

> Why do you need a separate name for XPath, XQuery and XSLT implementations?

Whether that trinity(hm..) justifies its own name, depends a lot on ones 
perspective, I think. For some people an XSL-T/XQuery implementation is their 
biggest choice of technology, and influences their project the most in pretty 
much all perspectives. For others, it's perhaps just something one the side.

I could of course be suffering from the "Of course my baby should have a 
name!"-syndrom, but I think I still insist on a good name. I think the same 
reasoning apply to Phonon -- why shouldn't it be named KSound? I do agree the 
name should be descriptive, but I think that can be achieved in other ways 
beyond "KTechnology".

(Transformism, Kueer, Queer, KTrinity, hm..)

> 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.


Cheers,

		Frans
1.
http://www.w3.org/TR/xquery-full-text/

2.
Check out the cool tools we use:
http://websvn.kde.org/trunk/kdenonbeta/kdom/xpath/kxqts/docs/KXQTSView-mainwindow.png?rev=535935&view=markup