XML, XSL, XSLT, XPath support?

[Nikolas Zimmermann]

Hi Koos,

> > 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).
I don't get this part :) Are you referring to khtml itself?

> When will this stuff move to kdelibs?
Well this is the big question. I'd prefer to have a working khtml(2)
prototype in kdenonbeta first, to ensure kdom is working for both
khtml & ksvg. Then we can araise the thought about such a move.

> 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?
Well Rob and me do prefer tabs over spaces. Using the right editor (tm),
it makes it easier to follow the document structure for me. My opinion ;)

> 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.
Please define 'everything'. I'm referring to other w3c defined languages like:
html, svg, xml+css, xpath, xpointer, xinclude. etc..

In current KDEs, all we support is: html, css, xml (+css), ecmascripting, 
(and unfinished: xpath; currently lives in kdenonbeta, built on khtml)

kdom brings a native oasis catalog implementation, shared css engine,
shared ecma engine, etc. etc. - stuff we haven't had yet.
In progress: xinclude, (xpath will be ported to kdom soon)

> 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).
Well the point is: if you want to implement CDF in a proper way
(defined by the spec!), the nodes of other embedded documents, should
live in the same object. -> If we have a xhtml documenting including svg,
the SVGElements have to live in the same documents with the DOMElements.
And with all consequences for the css & ecma part. The solution you
describe, could be possible, though it's very unclear how you want to
solve such situations, as I just described.

I'm aware that this surely needs work in kdom, too - as we haven't got
khtml on kdom yet, all I can offer: the devotion of my time to make such
a port possible, as well as my focus on CDF support, once that's done.

> 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?
Well I also played around with enterLoop lately, though this can never
work. It causes endless recursions, ie. a mouse move can trigger another
ecma event, where you just invoked enterLoop before ;)

KDOM's vision is the "shared" way, khtml could request a ksvg2 part
which can create a documentfragment from the passed data,
which would be adopted by the 'cdf' document. This requires quite some
work technically, but Mozilla supports it for ages, and we really need it.

Bye
 Bye
  Niko