[XML-SIG] XPath's reliance on id()

[Martijn Faassen]

Alexandre wrote:
> On Wed, Mar 13, 2002 at 07:24:02PM +0100, Martijn Faassen wrote:
>  
> > I hadn't considered that, but at first glance it seems to be fairly icky to
> > support this. These ParsedXML documents are usually persistent in the ZODB
> > and it'd be adding yet another field to it all. Plus DOM manipulations would
> > mean possible large scale changes of docIndex all over the tree..
> 
> I had a discussion with Uche on similar issues a few months ago. He
> pointed out that the id could be floats, which means that, to a certain
> extent, inserting a node in the middle of the tree didn't require that
> the ids of nodes after the inserted one (in document order) had to be
> updated. You just have to set the id of the new node to 
> 0.5*(id_before+id_after). 

That'd be an unreliable hack I'd vote against, but the principle is of course
sound; you could make sure to leave some space between the docIndex numbers 
so that most insertions wouldn't result in a recalculation of them all. A 
numbering scheme I've played with that has some nice properties like that
is described here:

http://citeseer.nj.nec.com/454193.html (PDF and PS on the topright side)

Though in fact a far nicer property of this scheme is the ability to
find out whether a node is a descendant of another very very cheaply.
Still, implementing such a thing inside a DOM won't be a very easy exercise,
and I am looking for a quick fix. :)

The issue with proxying nodes is real right now; Martin implies using hash()
wouldn't be the right thing, and though I'm still arguing with him I'm
willing to look at other possibilities. One would be simply to have a special
uniqueKey() method on the Node interface that in the normal case just returns
the id(), and in my case does something more complicated. Would have some
performance implications though -- perhaps it could fall back on id() if
no such method is found, mitigating most of those issues..

Regards,

Martijn