Re: A few more ideas on delete and iterate

Hi Nick,

No problem.  My "claim" is wrapped up in those tenets, mainly #2, and what 
I actually asked the group to do is to decide whether some version of 
tenet #2 is true.  I believe it is, whereas you're saying tenet #2 is not.

To focus on a shorter message, here it is again

1) The initial in-scope eval context node for an action element is 
obtained at the beginning of its execution.  Do you agree or disagree?

2) The initial in-scope eval context node is a node of *instance data*. 
This is the key issue.  Do you agree or disagree?  (Ignoring complexities 
introduced by other new features; they are addressed in my original email 
below and that content ca be revisted after this discussion of the basic 
principles concludes).

3) The delete action expunges a node from *instance data*.  This is clear 
as a bell in the spec, but it is worth asking do you agree or disagree?

So, if you delete a node (tenet 3), then as of the very next action to be 
executed (tenet 1), the node cannot be used as the initial eval context 
node (tenet 2).

The key is whether you agree with tenet 2 or not.  I agree with it because 
it is what the definition of evaluation context says (
http://www.w3.org/TR/xforms11/#expr-eval).  The context node comes from 
instance data, whether for an outermost element, or a non-outermost 
element that obtains context from a binding attribute, which can only 
reference instance data.  Your description makes it clear that you feel 
the deleted node continues to provide context after their deletion, but 
this would require the deleted nodes to still be instance data, which 
contradicts the first sentence of the description of the delete action (
http://www.w3.org/TR/xforms11/#action-delete).

Finally, as stated in prior email and again above, the definitions used to 
come to these conclusions do have to be amended around the term "instance 
data" due to new features we are now adding, but these features are about 
automatic ways of creating "live" content that the form should operate 
over, and I don't consider "deleted nodes" to be a new feature that now 
should behave as live content, where it didn't used to, at least not 
conceptually, if not in all implementations of the current spec.

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:   Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>
To:     John Boyer/CanWest/IBM@IBMCA
Cc:     Erik Bruchez <ebruchez@orbeon.com>, "<ebruchez@gmail.com>" 
<ebruchez@gmail.com>, "<public-forms@w3.org>" <public-forms@w3.org>
Date:   02/12/2011 12:17 AM
Subject:        Re: A few more ideas on delete and iterate



Hi John, 

Sorry but I still don't get why you are using the claim that in XPath 1.0 
an expression needs a context, because even when the node is deleted you 
have context for the action in my opinion. Can you point out where I 
making a mistake in my reasoning?:
If an action has an iterate attribute you evaluate the XPath expression in 
the the in-scope evaluation context to get the iteration sequence-> no 
problem here because we didn't do the delete yet
For every item in the iteration sequence the action is processed using 
that item as it context (while and if are also part of this processing) 
Suppose that the action, or one of its descendant actions deletes the node 
from an instance which is the next iteration item
On the next iteration there is no problem to provide an evaluation context 
because you have a context item (node is no longer part of an XForms 
instance, but why should XPath 1.0 care?), position and size

In one of my original responses to the 'problems' with iterate I proposed 
to have a function that returns the name of the instance to which a node 
belongs and using the 'if' attribute to skip the deleted nodes. Personally 
I still find this the best solution for the 'problem'. The iteration 
sequence is constructed the first time the action is run/evaluated in its 
context, and can consist of nodes from instances, atomic values, 
dynamically created nodes or nodes/items provided by an implementation 
specific way (e.g.: the host document, environment,…).

As a side note, I think you should only be able to attach MIPs to instance 
data nodes, and that only instance data nodes can add dependencies for 
MIPs in the data model (all other items should be considered constant and 
won't trigger recalculations, nor updates of other MIPs if they do 
change). 

Kind regards,

Nick Van den Bleeken
R&D Manager

Phone: +32 3 821 01 70
Office fax: +32 3 821 01 71
nick.van.den.bleeken@inventivegroup.com
www.inventivedesigners.com




On 02 Dec 2011, at 01:32, John Boyer wrote:

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




-- 
This message has been scanned for viruses and 
dangerous content by MailScanner, and is 
believed to be clean. 



Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer