Re: A few more ideas on delete and iterate

Hi Erik (and all),

Generally agree with everything you said here.  I'll go for your second 
issue first.

Yes, I think we already did agree that "lazy" @iterate was not the way we 
were going, so yes if a node is inserted into a place that the iterate 
expression *would* match if it were evaluated again, then the node is not 
iterated over because the iterate expression is not reevaluated.

The point I'm on about the effect of deletion on @iterate is really a 
point about how context is obtained.

I claim that an iteration over a deleted node is a no-op... except if some 
explicit vocabulary is used (as described further below).

This claim is based on a few tenets, which may become facts or may not:
1) The initial in-scope evaluation context for an XForms action is 
obtained at the beginning of its execution
2) The initial in-scope evaluation context node is a node of instance data
3) At the end of an XForms delete, a deleted node ceases to be part of 
instance data.

Now, with an XForms processor having an XPath 1.0 engine underneath, the 
absence of a context node means that the expression of a context, nodeset 
or ref attribute cannot be evaluated, which is being handled in a manner 
that I'll identify as a fourth tenet:
4) An XPath 1.0 expression that has no context node is handled as if it 
produced an empty result.

The fourth tenet is what seems to cause an iteration over a deleted node 
to effectively no-op.  Even with an XPath 2.0 engine, the expressions can 
still be evaluated without a context node, but unless special expressions 
are used that don't require a context, the actions will still no-op.  In 
particular, they would no-op in the interesting/common cases involving 
iteration, wherein the loop body expressions are stated relative to the 
iteration node.

I don't really see a problem with a deleted node continuing to exist as an 
orphaned entity stored in some special place by the XForms processor. This 
will become increasingly pertinent as we get deeper into features like 
xpath variables.  In fact, let's give the place a name, if deleted nodes 
continue to exist, then they are the "ghosts of data nodes departed" and 
so perhaps the location in which the XForms processor stores the ghosts 
could be called "purgatory".

Maybe all deleted nodes go to purgatory.  Maybe you have to ask for them 
to go to purgatory, for example by providing a variable name for them. 
Either way, the deleted nodes are in a place called "purgatory" which is a 
place other than the one called "instance data" from which they were 
expunged by the delete.

So it comes down to whether the tenet 1 and especially tenet 2, or some 
versions of them, become facts.

An emerging problem we have is that nodes, as well as "items", can now be 
created out of nowhere and used to drive context, such as the <repeat 
ref="1 to 5"> example in another recent email.  Clearly, tenet 2 has to 
expand from its XForms 1.1 version to accommodate all "living" data nodes 
and items, but the high-order bit on the question remains: 

Should the "ghosts of data nodes departed" be included or excluded from 
providing the initial in-scope evaluation context node of XForms elements?

Assuming deleted nodes do not provide initial context, we should look at 
whether there are any good use cases for accessing them from "purgatory" 
after they've been deleted, and then go from there to mechanisms for 
access and lifecycle. 

Assuming deleted nodes do provide initial context, then we should look at 
what mechanism would allow us to determine whether a node has been deleted 
since a reasonable use case for avoiding deleted nodes has arisen.   Note 
that my use case is, I feel, only a representative of the class of 
"in-place data mutation iterations".  My technical opinion is that I don't 
like this outcome for the following reasons:

1) we're ignoring nodes inserted into an iteration, and so the default 
behavior should at least look like we're ignoring the deleted nodes (even 
if you can go out of your way to override that).
2) to borrow your excellent phrase about the principle of least surprise, 
it would be very surprising if "in-place data mutation iterations" 
produced strange results until some special measure is taken.  A great 
example of this is all the pain we have with each person who has to learn 
to type "true()" because "true" is virtually false in XPath!

Finally, note that marking nodes as deleted appears to be needed 
regardless of the outcome above.

John M. Boyer, Ph.D.
Distinguished Engineer, IBM Forms and Smarter Web Applications
IBM Canada Software Lab, Victoria
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw





From:   Erik Bruchez <ebruchez@orbeon.com>
To:     public-forms@w3.org
Date:   01/12/2011 02:46 PM
Subject:        A few more ideas on delete and iterate
Sent by:        ebruchez@gmail.com



All,

Some more food for thoughts on this topic.

1. An argument of familiarity using DOM's removeChild function

The first thing I wanted to point out is the behavior of removeChild in 
DOM [1].

(And yes I know that it's called "remove" not "delete" ;)

The interesting bit is this: "The removed child node still exists in
memory, but is no longer part of the DOM. You may reuse the removed
node later in your code, via the oldChild object reference."

In other words, mutations functions that remove nodes from the DOM in
browsers don't obliterate the removed nodes. This is also the case
with various DOM libraries (not necessarily W3C DOM) for Java that I
know of. The system assumes that references to DOM nodes might exist
independently of whether that node belongs to the actual HTML
(typically) DOM. This is not only possible using e.g. JavaScript
variables pointing to those nodes, but the removeChild function itself
returns the removed subtree.

Right now in XForms 1.1, since there are no variables, it's harder to
get into the situation of keeping references to nodes. However it is
possible as we have discussed, via the context node/item and related
function, for example.

XForms 2, with variables, only makes this much easier, and mirrors
what is possible to do in general-purpose languages like JavaScript or
Java.

I think the principle of least surprise for programmers here pushes
more towards behaving like the DOM.

2. Lazy @iterate

I suggested during last call that, independently from xforms:delete,
we could make @iterate lazy. The idea was that future iterations would
reflect node deletions that have occurred during past iterations.

DOM has a similar concept e.g. with
https://developer.mozilla.org/en/DOM/element.getElementsByTagName [2].

The interesting bit is this: "The returned list is live, meaning that
it updates itself with the DOM tree automatically."

Now thinking a bit more about this, it doesn't seem easy to implement
at all. The live list in DOM is based on tag names, to it is pretty
easy to maintain the live list (naively, for example using a linked
list, and checking removed subtrees upon remove/delete).

Now in our case, we are using XPath. Nobody wants to rewrite a new
XPath engine from scratch, so that causes problem. The simplest thing
to do would be to evaluate the whole list of items eagerly, and then
checks whether the results have been detached (deleted) using a
marking algorithm during delete. However, new data inserted into the
DOM would never appear in the @iterate, and it wouldn't be "live": it
would just not included deleted nodes, which conceptually is a bit
inconsistent.

So I am backing down on this idea that a lazy @iterate could help much 
here.

-Erik

[1] https://developer.mozilla.org/en/DOM/Node.removeChild
[2] https://developer.mozilla.org/en/DOM/element.getElementsByTagName