Re: Thoughts on @iterate

All,

I also agree that the iterate expression should fully evaluate once before
starting to iterate.

Side-effects in programming are a pain, and this situation is no different.

BTW XQuery with updates choses to handle things in a different way: all
mutations apply to an immutable snapshot of the data, and are added to a
change list. When the query terminates, the changes are applied.

I don't think we have the bandwidth to reinvent something like  this, and
that behavior that would not be compatible with existing code. But it would
be more sane!

On the question of what happens to nodes that have been deleted, I tend to
agree that no special behavior should take place, as that would be similar
to newly created elements that don't belong to an instance. Furthermore,
with XPath 2.0 at least, elements with no containing document are allowed.

-Erik

[1] "A snapshot is terminated by invocation of the upd:applyUpdates
operation. XQuery Update Facility 1.0 defines an entire query as one
snapshot." http://www.w3.org/TR/xquery-update-10/

On Tue, Oct 11, 2011 at 8:24 AM, Nick Van den Bleeken <
Nick.Van.den.Bleeken@inventivegroup.com> wrote:

>  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
> www.inventivedesigners.com
>
>
>
>  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
>
> 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*<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* <boyerj@ca.ibm.com>
>
> Blog: *http://www.ibm.com/developerworks/blogs/page/JohnBoyer*<http://www.ibm.com/developerworks/blogs/page/JohnBoyer>
> Blog RSS feed: *
> http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw*<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
>

Received on Wednesday, 19 October 2011 04:12:25 UTC