XML, XSL, XSLT, XPath support?

[Koos Vriezen]

On Fri, Apr 08, 2005 at 05:03:35PM +0200, Nikolas Zimmermann wrote:
> Hi Koos,

Hi,

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

Yes

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

I see ..

> > 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 ;)

Well it's also a matter of taste (and thank whoever, we not all fall for
the same indenting style :-), but I don't follow your argument. Before I
did any KDE hacking my setting was something like 'ts=8;sw=4:noet', then
after reading about recommendations on developer.kde.org and khtml
sources, I changed it to 'ts=8:sw=4:et'. They all look alike in vim, but
my two settings keep looking good in eg. kedit.
Anyway, it's not important for kdom, only for future khtml..

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

Yes, that's what I meant with everything.

> 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 think we mean the same thing and I'm not sure if my suggestion could
work with current kjs. But the host and part live in the same address
space and share the same globals (if kjs has any). So, eg. if element
XXX from an xhtml document has as first child an svg object, than
document.getElementById("XXX").firstChild.firstChild.lastChild would
be the body of the SVG         ^svg obj    ^svg doc   ^svg body
(assuming svg also has a head and body structure) could work if after
finding an object (document.getElementById("XXX").firstChild) it would
look for the corresponding KJS global and plug that one in.
In case the svg document has an element with id SSS, something like
document.getElementById("XXX").firstChild.firstChild.getElementById("SSS")
could be written. Which looks a bit strange indeed ...
Anyhow, this is not restricted to kdom. Other kparts having kjs support
could be accessed this way too.

> 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 ;)

Yes enterLoop is a big PITA. However for eg.
  var i = document.applets[0].someobject.someFunc()
and an out-of-process plugin something must be done (some for the kjs
debugger btw). KDE/Qt4 it a good starting point to think about threading
in khtml's kjs usage IMHO.

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

I don't follow this wrt. to the problem ..

Koos

> Bye
>  Bye
>   Niko