XML, XSL, XSLT, XPath support?

[Nikolas Zimmermann]

Hi,

> 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..
well khtml can keep the style it wants, as long as I don't maintain it ;)

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

This problem is already solved in KDOM. Say I have a (kdom) DOM::NodeList
containing KDOM::Nodes (created by KSVGDocumentBuilder, ie. a 
SVGRectElement or SVGCircleElement node). Say I invoke the javascript
function call getItem() on the NodeList. The spec defines to return type
to be a 'DOM::Node', though in real life, one expects to get 'SVGRectElement'.
Now KDOM doesn't know anything about svg or svg nodes -> though it has
a 'getDOMNode' function which is able to cast a generic node into a
DOM::Element/DOM::ProcessingInstruction/etc... this function also caches
the dom nodes. We basically added a virtual function 'inheritedGetDOMNode'
which asks any "implementation on top" (ie. ksvg2) wheter it can convert the
passed KDOM::Node ptr into an ecmascript datastructure (KJS::Value).

This way myNodeList.getItem(0) can still return a 'SVGRectElement' object.
This should also answer Leo's question regarding the "shared ecma engine".

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

Hopefully, this enlightens it.

Bye
 Bye
  Niko