Re: Why guarantee parent-child relationship to be invertible ?

Hi Marton,

Thank you for your reply.

> 
> The parent-child relationship being invertible means that given a
> node $a
> - the parent accessor of any of its children returns $a, and
> - $a is contained among the children of its parent (unless
>   it is a document node, that has no parent)
> This property would be violated for instance if the element
> constructor had not logically copy their children nodes, but
> rather reference them, because those children nodes would have
> different parents before and after the element construction. 
> 
agree, this is understood. The term "invertible" is confusing, it 
suggests that the parent-child nodes' relationship to be swappable.
I would suggest that alternative wordings to be used such as 
"To guarantee that the parent-child relationship is navigable 
both ways"

> Such a behavior (i.e. when operations cause side effects) is
> undesirable because optimization becomes very hard. One cannot
> change the order of some operations, e.g. interchange for loops
> because of these side effects.
> So at least from a conceptual standpoint we want the data model to
> use immutable nodes and to satisfy the parent-child relationship,
> while allowing actual implementations to use specialized techniques
> (including using mutable nodes, if desired) for better performance
> or to avoid creating physical copies of the arguments to an element
> constructor.
> 

The consideration for children nodes having different parents
before and after element construction is an interesting one.
However, wouldn't this mean that the XML data is malformed 
and that we should throw an exception instead of allowing it ?

Please correct me if I'm wrong. In the current XQuery syntax,
element constructions are always written top-down and not 
bottom-up. (although actual query evaluation is bottom-up)
What this means to me is that we should not have the
scenario whereby there is a change in a node's parent 
throughout its lifetime. Otherwise, we must throw an exception
as there is an attempt to assign a child a new parent.

Moreover, every node created has its unique identity. 
Copying nodes will result in new identities, wouldn't this be a 
side effect too ? Even if its achievable that we have cloned
nodes to assume the same node identity, wouldn't this presents 
a data integrity nightmare, a terrible side effect too  ?

For the specification, I think it is adequate that it just states
the parent-child constrain. There is no need to state
that the element constructor logically creates all its children.

regards,
Kuan Hui

Received on Tuesday, 5 March 2002 21:28:29 UTC