KDOM

[Frans Englich]

On Wednesday 30 March 2005 01:03, Paulo Moura Guedes wrote:
> Hi Frans,

Hello Paulo,

You're bringing an interesting topic. I've CC'd kfm-devel for 
archiving/exposure.

>
> As you may know, Quanta is considering the possibility of using kdom.
> Currently it parses the document to its own tree and for purposes of VPL
> (Visual Page Layout, aka WYSIWYG) it synchronizes that tree with the KHTML
> DOM tree.
> If KHTML and Quanta would switch to kdom, the hack of having to manually
> sync the two trees would disappear, and it seems that kdom is flexible
> enough for us to use (as opposite to the current khtml dom implementation).
>
> Now, my question is, how should I familiarize with kdom and what documents
> should I read (specifiations, etc).
> I'm asking you this because you're not the original author and had to get
> in touch to a already started kdom project, and you seem to be very
> interested in HTML/XML.

Yes, that reasoning for contacting me I think is wise. I try to keep in mind 
that the one who interfaces knows best what makes it difficult, and take that 
opportunity to "tell" people what needs to be documented! I've written some 
docs in kdom/readme.xhtml(source in readme.docbook, see the targets 'xhtml' 
and 'valid' in Makefile.am). See also kdom/TODO. I try to update them as I 
find useful info.

Other than that, it's probably a lot up to what area you will work on. For 
example, I'm researching for an XSLT engine, and I mostly study Java APIs, 
currently.

The DOM 3 Core recommendation documents the interface(but not implementation): 
http://www.w3.org/TR/DOM-Level-3-Core/core.html

Rob & Nikolas knows(of course) a lot about KDOM & SVG.

Feel free to drop in on #ksvg(and all other XML interested are invited too :). 
I think kfm-devel is quite suitable for XML related discussions, unless 
someone honks.

Rob, Niko, it would be strategic for KDOM's productivity, to document, say, 
how to run the DOM test suites, how the ECMA bindings work, or the broad 
concepts of the kshared KDOM stuff. (isn't that lovely to hear? :)

>
> P.S. I want to add a more powerful support to stylesheets (CSS, XSLT) in
> Quanta so if you have any plans for that for KHTML let me know, so we can
> look at things also in a WYSIWYG perspective :)

Yes, let's plunge into details as appropriate. I don't know what's specific to 
Quanta's VPL for KDOM et al., but I'll grow wiser. I've thought of Quanta and 
similar cases, when led plans and coded. For example, I've heard some 
commercial Web/XML editors have Catalog support; perhaps the Catalog 
implementation comes in handy if an interest emerges for it in Quanta.

My plan after the Catalog stuff is finished as well as my local XInclude 
fool-arounds, is to start thinker with kdenonbeta/xpath & XSLT.

It's delighting with your interest for KDOM, because there's a lot to do. For 
a thing like XSLT, there's quite a lot of common code needed to be written.

Anyone who's interested in XML hacking can have a look in kdom/readme.xhtml, 
which mentions what's missing etc. It's for example parts of DOM 3 Core, and 
an API for serialization is needed for for example XSLT, and XML 
Canonicalization[1]. Basically, an API which handles the generation of 
different types of characters streams when given a DOM structure(should 
probably go via a SAX API).

An XLink[2] implementation would be nice in KHTML, Firefox got the half of 
one.

An XPointer implementation would be nice; it's needed in XLink, XInclude, and 
stuff like XML Diff. Basically, a parser for xpointer strings, and an API(the 
XPointer Framework[3]) which plugs in handling of various schemes. For 
example, an xpointer with the "element(intro)" selects the element with id 
"intro" in an XML doc.


Cheers,

		Frans

1.
http://webservices.xml.com/pub/a/ws/2002/09/18/c14n.html
http://www.w3.org/TR/xml-exc-c14n/

2.
http://www.xml.com/pub/a/2000/09/xlink/
http://www.w3.org/TR/xlink/

3.
http://www.zvon.org/xxl/xpointer/tutorial/OutputExamples/xpointer_tut.html
http://www.w3.org/TR/xptr-framework/