[XML-SIG] DOM Considered Harmful :-)

Jim Fulton jim@digicool.com
Wed, 05 May 1999 10:54:42 -0400

Greg Stein wrote:
> 2) the close() method and parent/sibling relationships

Acquisition (http://www.zope.org/Documentation/Reference/Acquisition)
should work very well for this.

> Adding parent/sibling relationships introduces loops unless you use
> proxies or introduce a close() method (if there is another way, then I'd
> like to learn it). Proxies are out for efficiency reasons -- objects get
> constructed every time you simply want to peek into the data structure.
> While the complexity is (mostly) hidden from the client, it is still
> there. You don't end up with simple data structures... instead, you get
> a lot of "mechanism" in there to deal with intercepting accesses so that
> you can create a proxy to bundle up the necessary data.

I guess that acquisition corresponds to a "proxy" approach.
We have optimized it heavily so performance is not an issue.
Also, acquisition provides a very simple model that adds very
little complexity.
> A close() type method introduces other problems. If you aren't careful,
> then it is easy to leak the entire parse tree. What happens if you pass
> a subset of the tree to another subsystem? You will have one of two
> problems: 1) the client avoids calling close() so the subsystem can use
> parent references (this leaks the whole tree); or 2) the client calls
> close() so the subsystem only retains its subtree, but now its
> (expected) parent/sibling relationsips no longer work. It has a set of
> objects that don't fully respond to their published API.

Acquisition avoids this issue because it eliminates the need
for child refereces to parents.


> I'm tremendously in favor of the model returned by qp_xml.

(BTW, could you provide a link to this proposal?
I must have deleted the message that contained it.  I'd
like to look at it.)

Acquisition has worked very well in Zope.  It provides a
very nice way to share information in a containment hierarchy.
It's only drawback is that it requires use of ExtensionClass, 
which is actually a bonus. ;)


Jim Fulton           mailto:jim@digicool.com   Python Powered!        
Technical Director   (888) 344-4332            http://www.python.org  
Digital Creations    http://www.digicool.com   http://www.zope.org    

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for