There was concern about the situation where a group of update statements would do different things depending upon the order that the update statements were executed in. This comes up whenever you allow the contents of the view to be based upon the current state of the view. Since the view may not be materialized it can be considered a dynamic set, and thus the execution order of the commands used to specify the view will become important.
Our solution was not to limit the user by saying that self referencing was disallowed, but to tell the user that ``odd'' things could happen, and to instruct them to create the view in 2 steps. The first step would require the construction of an intermediate view that depends only on the source database. The final view will ``inherit'' from the intermediate view and provide a static source for those commands that might have been self referencing in a single view.
I don't remember the exact example used, but the following gives the general feel for the problem:
Say you want to create a link between some Name ``N'' and P.A (here P is another name in the view.) To start off we will say that N has just one child with Label ``B'' and value 5, and P also has a single child labeled ``A'' with value 7:
ROOT
/ \
/ \
N P
| |
B | | A
| |
"5" "7"
Given the following two define statements there are two possible outcomes, depending upon which is executed first. One is where N will have a child ``C'' pointing to the value ``7'', and the other does not have this link. Both execution orders will delete the B link.
1.) N.B -= b
From N.B b
Where b = "5";
2.) N.C += a
From N, P.A a
where not Exists (N.B);