[XML-SIG] DevDay results

[uche.ogbuji@fourthought.com]

> (I ought to introduce myself first - while I'm not working
> on the XML modules myself, I've spent the past month working
> on a XML editor for KDE, using Python.)

[snip]

> As far as I'm concerned, the DOM is absolutely basic. At least, it's what
> I turned to immediately when I started writing my editor. If a DOM isn't
> included in the standard XML package, would it be allowable to include
> it in every application that needs one?

I doubt anyone would disagree that the core of the DOM is basic, but as I've 
already witnessed elsewhere, if you got all these people together, there would 
be no easy consensus on what constitutes that core.

We all seem to be agreed that 4DOM is (and even PyDOM would have been) too 
bulky to be bundled with Python.  Most have also expressed that some DOM 
interface would be good for bundling with Python.  Perhaps you can bring your 
fresh perspective to the question of exactly how we go about this.

If you don't mind, take a look at the xml-sig thread beginning at:

http://www.python.org/pipermail/xml-sig/1999-April/002712.html

and Paul's final proposal at:

http://www.python.org/pipermail/xml-sig/1999-April/002763.html

Except for the hard-core DOM-haters, most of us liked Paul's proposal, and it 
is only time that has prevented us from building in a conversion layer from 
4DOM to miniDOM.

I think we should review Paul's proposal in the face of DOM Level 2, and come 
up with a miniDOM which _can_ be bundled with Python, knowing that miniDOM 
code could be easily migrated to 4DOM if bigger guns are needed.

You'll also see a lot of dicussion of qp_xml in that thread.  qp_xml is nice 
and lightweight, but my resistance to it (and others) is that it doesn't 
follow the XML Infoset, which, rightly or wrongly, makes many concessions to 
DOM.  I'm sure we have all written our own quick and effective XML APIs (Mike 
and I have written our share).  We moved to DOM, warts and all, because 
standardization and intellectual cohesiveness is more important than memory 
and processor footprint for a general API.


-- 
Uche Ogbuji
Fourthought, Inc., IT Consultants
uche.ogbuji@fourthought.com	(970)481-0805
Software-engineering, project-management, knowledge-management
http://Fourthought.com		http://OpenTechnology.org