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<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 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<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:        Erik Bruchez <ebruchez@orbeon.com<mailto:ebruchez@orbeon.com>>
To:        public-forms@w3.org<mailto: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<mailto: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<http://www.mailscanner.info/>, and is
believed to be clean.


________________________________

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