[XML-SIG] DOM API

uche.ogbuji@fourthought.com uche.ogbuji@fourthought.com
Wed, 21 Apr 1999 23:08:50 -0600


> > This does make sense.  The first question would be philisohical: should such a
> > unified interface stick closely to the W3C's IDL, or should it be more
> > faithful to Python (i.e. returning PyLists instead of NodeList objects).  This
> > is the main difference between the two Python DOM implementation.  We could
> > build an adapter accordingly (most of the work is already don with
> > DOM.Ext.NodeList2PyList, etc), but I'd like to hear people's opinions first.
> 
> Do we really have to choose? If, for example, a NodeList object can act as
> a Python sequence then don't we have the best of both worlds? I mean if
> you really need a PyList then you can use "map" to generate one.

Dieter Maurer already pointed out to me that my memory was fuzzy, and that 
PyDOM already provides combined (NodeList and PyList) interfaces.

The main problem with 4DOM's overloading NodeList with PyList behavior, 
besides our desire to remain close to the spec except in clearly-marked 
exceptions, is the fact that you can't invoke methods of the form "__method__ 
" across an ORB.  In fact, strictly speaking, you can't encode them into IDL.

I know that this brings up yet again the question of why we insist on 
ORB-enabling 4DOM, but it has to do with much of the work we have been doing 
with 4DOM: some for clients, and some hopefully to become separate open 
products soon.  Interfacing to object-database adapters, for instance, is a 
lot easier if one can directly take advantage of the ODMG-OMG bindings.

We have considered a lightweight 4DOM that isn't so ORB-fanatic, but we don't 
really have the time for this, and besides, PyDOM fills that niche quite well.

I know, I know, the problem remains that PyDOM and 4DOM are different enough 
to complicate portable Python DOM applications.  I hope this conversation can 
lead us to a way about that.

> I would like to think that Python is sufficiently flexible that most of
> these choices could be made in a DOM compatible AND Python compatible way.

Python is, of course, but not CORBA, helas.

> The downside of doing both is that a Java or C++ implementation of a "raw"
> DOM accessed over CORBA or COM would not be compatible -- but we could
> write Python wrappers that would make them so.

Well, we do provide the NodeListToPylist and PyListToNodeList, and we do often 
use these wrappers in our own apps.  It appears you're asking for more, though.

BTW, we're preparing a pretty neat demo of interchanging DOM between Java and 
Python over an ORB with 4DOM on the Python side.  We've already found that you 
can do powerful things with this arrangement.  Now if only Fnorb would play 
more nicely with other ORBs via IIOP, or if ILU would be less insistent on 
explicit server-side reference of objects.

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