W3C home > Mailing lists > Public > public-forms@w3.org > October 2011

Re: Thoughts on @iterate

From: Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>
Date: Tue, 11 Oct 2011 15:24:58 +0000
To: John Boyer <boyerj@ca.ibm.com>
CC: "<public-forms@w3.org>" <public-forms@w3.org>
Message-ID: <E4299506-EF77-40B4-B7FF-13680B4D1168@inventivegroup.com>
Hi John,

I always thought that the delete action in XForms just removed the node from its parent. As a result the node became a sub-tree of it was the root node. And as you note, nothing happens with its children (when you traverse from a child node, the ancestor chain of course stops at the node that is deleted). Therefore I gave all those samples with orphan nodes, because I thought you couldn't tell the difference between an orphan node, because it wasn't yet inserted in a tree or an orphan node that was just deleted from a tree. Is there a difference in your implementation?

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<mailto:nick.van.den.bleeken@inventivegroup.com>
www.inventivedesigners.com


[cid:image001.png@01CBF2F8.1DA19110][cid:image002.png@01CBF2F8.1DA19110][cid:image003.png@01CBF2F8.1DA19110]

On 11 Oct 2011, at 16:36, John Boyer wrote:

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<mailto: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<mailto:Nick.Van.den.Bleeken@inventivegroup.com>>
To:        John Boyer/CanWest/IBM@IBMCA
Cc:        "<public-forms@w3.org<mailto:public-forms@w3.org>>" <public-forms@w3.org<mailto:public-forms@w3.org>>
Date:        10/10/2011 11:37 PM
Subject:        Re: Thoughts on @iterate
Sent by:        public-forms-request@w3.org<mailto: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<mailto:nick.van.den.bleeken@inventivegroup.com>
www.inventivedesigners.com


<Mail Attachment.png><Mail Attachment.png><Mail Attachment.png>

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<mailto: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<http://www.mailscanner.info/>, and is
believed to be clean.


________________________________

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

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.


________________________________

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



image001.png
(image/png attachment: image001.png)

image002.png
(image/png attachment: image002.png)

image003.png
(image/png attachment: image003.png)

Received on Tuesday, 11 October 2011 15:25:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:56 UTC