[Zope] ID's in one XML Document nt unique?

[Martijn Faassen]

Amos Latteier wrote:
> 
> At 05:01 PM 9/7/99 +0200, Martijn Faassen wrote:
> 
> >> _make_id() makes sure there are no two elements with the same URL, it does
> >> so by making sure there are no two elements with the same id on one level
> >> of the URL.
> >
> >I must be seriously misreading the code then! As I understand it, it
> >goes up the XML tree from the current node until the parent node isn't
> >an XML Node anymore. It would find the top node of the trees this way.
> >Then it checks the next_id attribute there and uses this for the new id.
> >It also increases the _next_id attribute by 1. Wouldn't this guarantee
> >an unique id each time it's called? Perhaps there's something in the way
> >it's called that makes me misread it.. Or I misread the loop that I
> >think goes up the tree?

> I believe that this is in fact what _make_id does.

Ah, I see. I was starting to doubt my understanding of the whole thing,
ability to read source, and so on, so I wanted to make sure I knew what
was going on. Such a relief! :)

> However, I can imagine
> scenarios in which moving Nodes around, rebuilding nodes, and the like
> could allow duplicate ids to exist at different levels of the tree. At this
> point I don't think that XML Document guarantees that all Node ids in a
> tree are unique.

I see. Let me think this through out loud here. Hm, I can't see how
moving nodes around (in a _single_ tree) can by itself duplicate node
ids. Reconstructing parts of the tree also seems to always result in new
node ids to be generated (as far as I understand it _make_id is always
called in the builder, as it uses appendChild). The only case I can
think of right now is when the *root* of the tree (that keeps the
_next_id) is somehow modified so that _next_id is wiped out. Could you
describe another scenario where duplicate ids are generated?
 
> Let me repeat the XML Document is in *alpha* which means that it may change
> significantly. If you have strong feelings about how this issue, please
> write a short proposal/justification and send me patches to implement it.

I know it's in alpha, but I'm working on bashing it into beta
eventually. :) This note is part of the friendly bashing (um, 'debate')
of course.

My strong feeling is that each node _should_ have an unique id (in the
tree). It makes it easier to selectively render part of the tree
differently. For instance, if I have a number of paragraphs, and I want
one paragraph to be temporarily 'focused' I can re-render the entire
thing with a special variable focused=<id of paragraph>. When the
paragraph render method notices 'focused' is set to the current id, it
will render the paragraph differently. This kind of thing is nice when
you try to implement XML editors in Zope (which I am trying to).

I imagine this is solveable with absolute_url(), but it seems to be more
difficult. Also you may run into trouble with acquisition this way. I
think duplicate ids in the same tree may make acquisition of nodes in
general less clean anyway, but I haven't thought this through yet..

I'd like to work on patches, but so far I haven't thought of a scenario
yet that generates duplicate ids! There must be some as that's what
prompted Stephan's question. Perhaps Stephan has a simple scenario?

> I believe that this whole discussion started because someone wanted to
> identify Nodes in a sure fire way. I still suggest that folks use a full
> path such as:
> 
>   myDoc/e15/e27/e66
> 
> To identify Nodes of an XML Document. Even if XML Document guarantees that
> all Node ids in the tree are unique, I still think that is the right way to
> identify Nodes in most cases.

Why so? It is fairly complicated extracting the right path, at least far
more complicated than getting at the id. As I understand it, you need to
use absolute_url(), somehow cut off the front part, and compare that, or
is there a simpler way? Since nodes have ids anyway, and these ids are
currently at least _approximately_ unique, wouldn't it be easier on all
of us to make them completely unique?

Regards,

Martijn