> >"The returned URI is stable, i.e. it does not change when other nodes are > > inserted, deleted or modified"
> Obviously, it is not entirely correct in the current implementation: > Consider 2 nodes P and C, where C is a child of P; if P is deleted, the result > of node-position(C) before P's deletion is different than after P's deletion > (because P and its subtree become part of a new tree). In other words, the > node position of C changes when P is deleted. Maybe we should say that the > node position of a node is stable as long as the node remains in its current > collection and tree? Yes, you are right. However even with the limitation you propose another problem would arise in the current implementation. (ie. TEXT_ORDPATH off) Consider 3 nodes C1 C2 and C3 children of a node P. Assume that C2 is a text node. This means that its ordpath is computed on the fly. If C1 is labeled 1.1 and C3 1.3, the label of C2 would be 1.2.1. Now if you remove C3 and compute again the label of C2 it would be 1.3. That is not stable even if it remains in the same collection and tree. I am removing the whole phrase. > Second, when you say that you rely on it, does it mean that you may need to > compare 2 node positions that were obtained in different snapshots? And if so, > do you expect that the result of such a comparison says anything about the > positional relationship of the two corresponding nodes at any point in time? > (in other words, is what I wrote for the is-ancestor function really correct?) I am (was?*) relying on the fact that the label of two nodes belonging to the same tree do not change over time. I am (was?*) interseted in some of the relations (ie. ancestor-descendant) which are not affected by the text node ordpath on-the-fly computation. * Just noticed that TEXT_ORDPATH off means that in the interested cases I can no longer store some the ordpaths in the PUL, so the problem should not exist anymore. > > > > > > > > > Also, look at the following rewrite of the ancestor-of function. Do you > > agree > > > with it? > > > > > > (:~ > > > : Determines whether the node position that is given as second argument > is > > > : an ancestor of the node position is given as first argument. > > > : > > > : If the two positions were obtained within the same snapshot S, then the > > > : result of the function applies to the corresponding nodes as well, that > > > : is, within snapshot S, the second node is an ancestor of the first. > > > : Otherwise, the result of the function does not imply anything about the > > > : positional relationship of the two nodes. > > > : > > > : @param $pos1 the potential descendant node position > > > : @param $pos2 the potential ancestor node position > > > : > > > : @return true if the node position $pos2 is an ancestor of the node > > position > > > : $pos1; false otherwise. > > > : > > > : @error zerr:ZAPI0028 if one of the given URI is not a valid node > > > : position computed by the <tt>np:node-position</tt> function. > > > :) > > > declare function np:ancestor-of( > > > $pos1 as xs:anyURI, > > > $pos2 as xs:anyURI) as xs:boolean external; > > > > Yes, I agree with it. When I wrote this I was a little scared to say that a > > structural relationship was ancestor of another, but now that they are > called > > node positions it should be ok. I am doing it. > > > > Federico -- https://code.launchpad.net/~zorba-coders/zorba/structuralrelationships2/+merge/78395 Your team Zorba Coders is subscribed to branch lp:zorba. -- Mailing list: https://launchpad.net/~zorba-coders Post to : zorba-coders@lists.launchpad.net Unsubscribe : https://launchpad.net/~zorba-coders More help : https://help.launchpad.net/ListHelp
