[XML-SIG] CORBA compliance for the DOM in Python? (RE-POST)

uche.ogbuji@fourthought.com uche.ogbuji@fourthought.com
Wed, 24 Nov 1999 18:59:27 -0700


Pardon me if you get this twice, but I had problems with mail at python.org 
yesterday

> Fred L. Drake, Jr. writes:
>  > Andrew M. Kuchling writes:
>  >  >     (The get_*() probably can't go away completely, though, because of
>  >  > external documents such as Sean McGrath's Python/XML book.)
>  > 
>  >   This one hurts; I really don't like leaving it in if we're actually
>  > going to change it.  Do you know if the book has gone to press?
>  >   This makes me want to rethink using the IDL mapping, but the catch
>  > is we need to if we are going to use general code to operate on
>  > arbitrary DOM trees, including remote ones.  Without this, there's
>  > little point to using ANY specific interface.  ;-(  We may end up with 
>  > multiple flavors of the interface, which I consider evil.
> I think it is not that bad. The differences are rather small
> and homogenous.

Yes, but many of the people who buy Sean's book will probably be newbies who 
will not like the unpleasant surprise of getting "AttributeError" exceptions 
every time they attempt the merest example in the text.

However, I expect that Sean would have python-xml 0.5.1 or so on the CD that 
comes with the book, which will still match the text, and if people come to 
python.org to get a new version, we can put up a big notice in corruscating 
periwinkle and ultramarine with blink tags that tells them that the API has 
changed.

I'll be honest that the _get_ stuff still looks odd, so I'll be encouraging 
users to stick to the pythonic interface, but we've almost completed porting 
4DOM to support both (and ditch the old interface), so we're committed.

> What about using an object factory to build DOM trees.
> This would be a good thing in any case, because applications
> could extend the DOM base classes to add support for application
> specific requirements.

DOM level 2 already takes care of this, defining a complete set of factory 
methods with the exception of Entity, NodeList and NamedNodemap.  Note that 
the re-worked 4DOM we're polishing off supports full DOM Level 2, including 
those factories on Document and DOMImplementation.

> Supporting an old/different interface (for compatibility/context reasons)
> would simply mean changing the object factory somewhat.
> It could be done by importing the DOM document constructor
> via a special module or through an explicite initialization
> call.

Not a bad idea.  PyDOM could ship with a "compatability" interface that is 
mixed in to the nodes if a particular parameter is asserted in the factories.


-- 
Uche Ogbuji
FourThought LLC, IT Consultants
uche.ogbuji@fourthought.com	(970)481-0805
Software engineering, project management, Intranets and Extranets
http://FourThought.com		http://OpenTechnology.org