FYI: An OASIS XML Catalog implementation ready for use

[Frans Englich]

On Saturday 02 April 2005 17:02, Nikolas Zimmermann wrote:
[...]

> of course no decisions have been made yet - though I can't see any obvious
> reasons for not using kdom for khtml in KDE4 - only possible new
> regressions.

After a second thought, according to my opinion it could be a good idea to 
wait until DOM lvl 3 Core have settled down. The reason I find is that it's 
currently buggy and incomplete, which easily leads to increased amount of 
work if that is to be fought in addition to porting khtml. It may also be 
that DOM 3 provides better ways to implement things, and if it's 
absent/incomplete, it leads to workarounds and inefficiencies.

Similarly, over the future there will be many different "components" running 
around in khtml/xml related code, and the error reporting framework DOM 3 
Core provides would be practical to have in place.

Considering the different tokenizers/document builders that exist, and the 
need for flexibility in that area, it could be a good idea to also have DOM 3 
Load and Save[1] done, such that it gets designed around a flexible, generic 
API.

IIRC, Rob once stated he wanted the core fully done before bringing it heavily 
to use, and I perhaps now better understand why.

In other words, since these KDOM parts in either case should be completed, it 
could be an idea to start with that.

The universal, revolutionizing truth: more man power is needed.


Cheers,

		Frans

1.
API for opening and saving files. Provides APIs for plugging in serializers, 
tokenizers, and so forth. The spec:
http://www.w3.org/TR/2004/REC-DOM-Level-3-LS-20040407/load-save.html