XML, XSL, XSLT, XPath support?

[Koos Vriezen]

On Thu, Apr 07, 2005 at 05:33:52PM +0200, Nikolas Zimmermann wrote:
> 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.

That was my impression too, change some bases classes here and there and
it should work again (thanks to OO). When will this stuff move to
kdelibs?

Small nitpick is the rigid code style you guys use (and esp. it's not
what I prefer). IIRC it's preferable to use space and not tabs, no?

Compound Document Format sounds cool. But do you expect everything to be
KDOM based (and isn't that a lot of work, or is it realistic)? Now we have
only kpart based embedding, which has the obviously benefits of re-using
work of others.
However, when it comes to cross document scripting, we only have
liveconnect now. I recall asking Rob once if kparts using libkjs could
be connected in khtml. Does someone reading this knows, can libkjs
iterate over its global objects and can a kpart-host use that one? That
would solve it too, ie. connect a kparts global to khtml's OBJECT and
push some 'top' global in the kparts scope. Allthough one would be at
the grace of the kpart writer whether the ecma binding would be DOM (but
does that really matter for eg. a PDF viewer).

A final note is an issue I've encounter a few times, and that's is how
to async communicate with embbed documents/kparts. The problem is that
kjs can't be stopped for a while w/o using Qt's enterLoop. This problem
is for real for out-of-process plugins like kjas/nsplugin. My personal
opinion is going the threaded way, but there were some thoughts about
redesigning kjs not using the C stacks, so it could be stopped/started
at will. What's KDOM's vision about this?

Koos