Re: Thoughts on @iterate

Hi Nick,

I actually agree with your second point and think there has just been a 
small misunderstanding.

My point was that the iteration should skip nodes that have actually been 
deleted, which is different from skipping nodes that are orphans for some 
other reason.  In both of your examples, orphan nodes are created and 
placed into the iterate sequence, so we should iterate over them.  If some 
action within the iterate loop body deletes some of those orphan nodes 
that have not yet been iterated over, then those deleted orphan nodes 
would be skipped when the iteration reaches them in sequence, just as 
deleted non-orphan nodes should be skipped.

I think this does not really make things harder to implement because the 
absence of a parent is not a reliable test for whether a node was deleted. 
 There has to be  a special marking for it because the implementation 
almost certainly does not waste time disconnecting the parents of all 
nodes in a subtree that has been deleted.  For example, if you do 
iterate="descendant::*" and then delete some internal node during the 
iteration, then all of its descendants are also deleted even though they 
are still part of the subtree of the internal node, meaning that their 
parent pointers are not cleared. 

Cheers,
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:     "<public-forms@w3.org>" <public-forms@w3.org>
Date:   10/10/2011 11:37 PM
Subject:        Re: Thoughts on @iterate
Sent by:        public-forms-request@w3.org



John, 

I also think that the sequence to iterate on should be obtained only once 
(on the initial execution of the action). 

But I'm not convinced that we should always skip nodes that aren't in an 
instance:
For sure we shouldn't skip atomic values (e.g.: iterate="for $i in 1 to 10 
return $i"). 
We shouldn't skip nodes that are created with our parse function (e.g.: 
iterate="for $n in xml-string return xf:parse($n)") 
We shouldn't skip nodes that don't have a parent otherwise you couldn't 
iterate over a sequence that contains root nodes)

I see your use case, but couldn't you use an 'if' attribute and check if 
the iterated node has a parent node, using the parent axis in XPath?

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 11 Oct 2011, at 01:31, John Boyer wrote:

1) Combining @iterate with @while and @if 

Not that I like it overly much, but the spec language for the while 
attribute indicates that an if attribute is evaluated at each iteration of 
the while loop, so the 'if' is inside the while loop execution. 

For consistency and ease of implementation, it is tempting then to say 
that @iterate obtains a nodeset and then for each node, the action bearing 
@iterate is executed, excluding the @iterate but including any @while and 
@if attributes on it. 

However, currently the if and while attributes are evaluated in the 
in-scope evaluation context of the containing element, so we would have to 
amend that language to say that if and while are evaluated in the context 
as set by iterate.  Otherwise, it would be very weird to authors to say 
that if and while occur for each node of the iterate but have no way to 
access that iteration node and are evaluated in a context that is outside 
of the iteration nodeset. 

Due to the possibilities for confusion, we could say that an 
implementation MAY support iterate in combination with the other 
attributes, so that we can say how it should be have if supported without 
forcing all implementers to get there. 

2) Deleting nodes from the nodeset 

I am hitting lots of really reasonable cases where I am deleting nodes 
from the nodeset over which I am currently iterating.  This includes not 
only the current iteration node, but possibly successors. 
It should be legal to delete the iteration node and, at least in the same 
delete action, to delete successors of that node. 

3) Dynamically adding to the iterate nodeset 

I am hitting a lot of cases where I legitimately want to add nodes that 
*would* match the @iterate expression if it were re-evaluated, and in the 
cases I'm hitting, I definitely don't want to include those nodes in the 
iteration because they are predecessors to the current iteration node.  In 
other words, I don't even have to use a predicate to achieve this effect 
of not wanting to include these nodes. 

It seems better to say, as in #1 above, that the @iterate nodeset is 
obtained once, and then that nodeset is used in a for-each.  When we get 
to a particular node, if it is "stale" because it has been deleted, then 
skip it.  If other nodes are added to the context in which the iteration 
nodeset was obtained, they are not included in the for-each behavior.   

As a concrete example, here is the pseudo-code for a simple "selection" 
sorting routine: 

iterate nodeset "employees/person" 
    maxvalue = ./name 
    iterate nodeset "next-sibling::*" { 
          If compare(./name, maxvalue) > 0 
             maxvalue = ./name 
    } 
    insert context=".." origin="person[name=maxvalue]" 
    delete nodeset="(self::* | next-sibling::*)[name=maxvalue]" 
 
The penultimate insert adds new nodes to the beginning of the employee 
list that match the outer iterate loop's nodeset, but clearly the 
iteration should not take these new nodes into the iteration.  The final 
line deletes the copies of the nodes inserted.  If there are duplicate key 
values (e.g. sorting by first name), then this operation will remove one 
or more nodes from future steps of the outer loop iteration.  Also, when 
the maxvalue is the current iteration node, then the final delete also 
eliminates the current iteration node.  In the duplicate key case, we need 
the delete to remove all matched nodes even though the first node it 
removes is the evaluation context  node for the delete action.  This 
should not be a problem because all XPaths of the delete action are 
evaluated before the first node deletion takes place. 

Cheers, 
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


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