Re: A few more ideas on delete and iterate

John,

I think everybody agrees on 1)

As you already concluded I believe(d) that a node doesn't needs to be in an instance to be able to be a context item. Otherwise implementation defined extension functions that return nodes become a lot less useful. I always thought you were making your claim based on limitations in XPath 1.0. But I miss understood that, it was due to wording in section 7.2. I've read that section a lot lately but I never paid attention to the words 'instance data' apparently. The good thing is that it is a limitation in our spec and not in Xpath 1.0.

I think we should definitely remove this limitation for XForms 2.0. Because it has nothing to do with 'limitations in XPath 1.0 on evaluation context' but an extra limitation introduced in XForms. As said in my previous e-mails some limitations on what is allowed will be kept  in XForms 2.0 (e.g.: you can only attach MIPs to instance data nodes, the dependency algorithm only takes into account instance data nodes, it is implementation dependent wether you can change non instance data nodes).

I think everybody agrees on 3) too

So the good news is that we only have to agree on if delete only deletes nodes from instance data or also destroys the nodes and behaves as if they are removed from all other sequences that contain that node. I (and Erik I think) would go for the first option (only delete only deletes nodes from instance data), and you would go for the later I believe. We should try to come to a consensus on this.

Maybe we could try to compile a list of the advantages and disadvantages of both approaches?

1. Delete only deletes node from the instance
+ Behaves like remove works on DOM
+ No extra marking on the complete subtree of the deleted node
- Need for an extra function to test if a node is part of an instance

2. Delete destroys node (behaves as if  all references to the node are destroyed)
+- When a node is deleted from the instance it disappears everywhere
- Extra marking on the complete subtree of the deleted node
- Requires extra checking in all iterate loops
- Should all child actions of an action that no longer has a context stop?
- Hard to implement if the node was retrieved before deleting it with our DOM interface

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 19:14, John Boyer wrote:

Hi Nick,

No problem.  My "claim" is wrapped up in those tenets, mainly #2, and what I actually asked the group to do is to decide whether some version of tenet #2 is true.  I believe it is, whereas you're saying tenet #2 is not.

To focus on a shorter message, here it is again

1) The initial in-scope eval context node for an action element is obtained at the beginning of its execution.  Do you agree or disagree?

2) The initial in-scope eval context node is a node of *instance data*.  This is the key issue.  Do you agree or disagree?  (Ignoring complexities introduced by other new features; they are addressed in my original email below and that content ca be revisted after this discussion of the basic principles concludes).

3) The delete action expunges a node from *instance data*.  This is clear as a bell in the spec, but it is worth asking do you agree or disagree?

So, if you delete a node (tenet 3), then as of the very next action to be executed (tenet 1), the node cannot be used as the initial eval context node (tenet 2).

The key is whether you agree with tenet 2 or not.  I agree with it because it is what the definition of evaluation context says (http://www.w3.org/TR/xforms11/#expr-eval).  The context node comes from instance data, whether for an outermost element, or a non-outermost element that obtains context from a binding attribute, which can only reference instance data.  Your description makes it clear that you feel the deleted node continues to provide context after their deletion, but this would require the deleted nodes to still be instance data, which contradicts the first sentence of the description of the delete action (http://www.w3.org/TR/xforms11/#action-delete).

Finally, as stated in prior email and again above, the definitions used to come to these conclusions do have to be amended around the term "instance data" due to new features we are now adding, but these features are about automatic ways of creating "live" content that the form should operate over, and I don't consider "deleted nodes" to be a new feature that now should behave as live content, where it didn't used to, at least not conceptually, if not in all implementations of the current spec.

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:        Erik Bruchez <ebruchez@orbeon.com<mailto:ebruchez@orbeon.com>>, "<ebruchez@gmail.com<mailto:ebruchez@gmail.com>>"        <ebruchez@gmail.com<mailto:ebruchez@gmail.com>>, "<public-forms@w3.org<mailto:public-forms@w3.org>>" <public-forms@w3.org<mailto:public-forms@w3.org>>
Date:        02/12/2011 12:17 AM
Subject:        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


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

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

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