zorba-coders team mailing list archive

[Markos Zaharioudakis <markos_za@xxxxxxxxx>]

> > Federico, I think the documentation in node-position.xq needs some more
> work.
> > I can do this, but first we must agree on what is exactly the functionality
> > and the assumptions about node positions that you rely on. For example, in
> the
> > documentation of the np:node-position() function, you write:
> >
> > "The returned URI is stable, i.e. it does not change when other nodes are
> > inserted, deleted or modified"
> >
> > Do you rely on this? If not, then we shouldn't write it down.
> 
> Yes, at the moment I am relying on it. It could be possible however, with some
> limitations, to lift off this requirements. I have not a clear idea at the
> moment
> of the limitations involved or the amount of work required to do so. If you
> think
> is bad to promise that uri are stable I can look into it.
> 

It's ok if you rely on this, but I am not sure I understand what it means exactly. 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?

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



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