Re: Thoughts on @iterate

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


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

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