Re: A few more ideas on delete and iterate

Yeah, I agree it's a case of "one man's limitation is another man's 
sensible behavior."
And if the situation were reversed, it would be "one man's non-intuitive 
behavior is another man's useful feature."

As an indicator of this, I didn't really see the +'s and -'s working out 
the same way Nick did.  For example, the marking of deleted nodes seems to 
be needed regardless of which way this turns out, in order to make it 
possible to have any kind of vocabulary to access the use case of the 
"other man".

Moreover, I'm not even really fully in the camp of "delete destroys nodes" 
as Nick characterizes below.  What I am saying is that the current spec 
gives me a clear and rigorous idea of when the nodes are supposed to go 
away, which is after processing of the xforms-delete event.  Which means 
that they do live briefly after their deletion. 

I don't have a problem with the nodes continuing to live as long as we do 
rigorously define under what conditions they continue to live, how are 
they accessed, and when do they get destroyed for real.

Separately, I happen to think it is counterintuitive for "deleted" nodes 
to continue to be accessible *by default*.  This is why we need to hew 
toward Leigh's suggestion of seeing what are the actual use cases.  Nick 
said that it breaks some of our new features if the deleted nodes are 
unavailable/destroyed.  OK, so what is the markup for these features? 

This is necessary to get a sense of whether the use cases could still be 
easily solved if we assume the addition of an extra function that can 
access the deleted nodes.  I think it would be OK to access the deleted 
nodes by a non-default or "explicit" piece of vocabulary. 

Assuming access to deletednodes by an explicit piece of vocabulary would 
also get rid of complexities of other solutions that might be based on 
creating a pseudo-MIP around readonly-ness or non-relevance. 

For example, perhaps xforms:delete could get an extra parameter that 
provides an XPath variable name where to store the deleted nodes so that 
they are referenceable later by that name:

<xforms:delete nodeset="some/nodes" saveto="X"/>
...
<xforms:insert ... origin="$X"/>

And, perhaps the nodes should go away for good if they are deleted from 
the saved name, e.g.
<xforms:delete nodeset="$X"/>

and/or they get moved if you do something like this:
<xforms:delete nodeset="$X[predicate]" saveto="Y"/>

Question: Are the uses cases described by Nick (and Erik) solvable with 
this type of solution?


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:   Leigh L Klotz Jr <leigh.klotz@xerox.com>
To:     Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>
Cc:     John Boyer/CanWest/IBM@IBMCA, ebruchez@gmail.com, Erik Bruchez 
<ebruchez@orbeon.com>, public-forms@w3.org
Date:   05/12/2011 04:22 PM
Subject:        Re: A few more ideas on delete and iterate



I don't think we're going to be able to agree on whether delete makes the 
node unusable in XForms 1.1 or not, and I don't think it's productive to 
argue it.

I think John has shown compelling use cases for the concept of removing a 
node from an instance and marking it to be skipped in actions and XPath 
functions that operate on instance data.  If you think about it, it's akin 
to a relevance MIP but extending to actions, just as setvalue obeys 
readonly. 

So one way to look at this is to say it's a 'readable' MIP, and we might 
be able to decouple it from the way it gets set.  

If that works out, we can then have an XForms 2.0 action to detach nodes 
from their parents, and leave them readable, and another to detach them 
and mark them readable=false.  Then we have firm semantics under control 
of XForms spec, and don't depend on one interpretation or another of how 
we have bolted on mutability to the XPath data model.  It fits well with 
John's implementation (a mark on a node is very much like the way some 
implementations store MIPs), and it lets us satisfy both sets of use cases 
in XForms 2.0.

Leigh.

On 12/02/2011 11:57 AM, Nick Van den Bleeken wrote: 

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

 think everybody agrees on 3) too