XML, XSL, XSLT, XPath support?

[Nikolas Zimmermann]

Hi,

> Bring yourself back to reality for a minute. You propose to make
> kdenonbeta/xpath work with KDOM when KDOM isn't even used in KHTML yet, and
> nobody has said it will be. Maybe you should think about finishing
> kdenonbeta/xpath and make it work with current KHTML first, as I'm sure
> that would be much more useful for both Andy and anybody else who wants
> XML, XSL, XSLT, and XPATH support in KHTML now rather than later.
> Otherwise, you're asking somebody to invest time in something that might be
> cool but isn't guaranteed to be used, and it sounds like Andy could really
> use support for XPATH in KHTML now rather than later.

Well you should have a look at it before judging in such a way.
There's nothing particular against khtml and of course no decision has
taken place yet - as we haven't started a port of khtml to kdom so far.
This had (& has) obvious reasons:
- the whole shared css/ecma stuff should be probed from ksvg2 first
  -> this phase is actually over now with _great_ success.
- dom 3 load/save is just being worked on, and this should be in place 
  first.

Do you think we joke or dream when working for more than 1,5 years
on such a project? It shouldn't be some kind of toy for us - it offers way
more khtml's dom implementation can offer right now. "Compound Document
Format" is the future - embedding ie. xhtml in svg or the other way round.

KDOM will be the base for such things. And FYI the implementation has copied
_most_ concepts from the excellent khtml code base - while cleaning  them up
& refactored the stuff to also keep a "layer on top" in mind - ie. ksvg2 on
top of kdom. It shouldn't be a _very_ complicated job to do such a test port
prototype - which would be quite functional already.

Next point: the "hairy" (say: touchy) stuff in khtml are the render objects &
the whole html handling (tokenzier, parser, html*element..). And guess what?
We didn't touch any of these areas. KHTML can even keep it's own html parser
on top of KDOM::Parser. From ksvg2 we can still use the libxml2 based parser
for efficiency.

kdom/ksvg2 are also being ported to mac os x.

Technology status:
- DOM Level 1 Core/2 Core/2 Events - 100% completed.
- DOM Level 3 Core - 70%, 3 LoadSave - just in progress.
- CSS 1/2 selectors, partly CSS3 - 1:1 shared with khtml head
- OASIS Catalog implementation - done.
- XInclude support - on the way (Frans :)
- XPath support - should be started on after XInclude support.

My personal wishlist still lists: XPointer, XSLT.

Though kdom is really a good starting point, as it is the basically
the khtml dom code, with easier-to-follow code. Okay, stuff like
EcmaScript really differs, but that's intended and already discussed
with for instance Harri/David/Dirk.

Bye
 Bye
  Niko

P.S. DOM Level 2 Traversal/Range needs khtml porting... anyone? :)