Re: 2 bugs in 'delete'?

Hello Paul,

i've setup a testcase that uses your form and fixes the behaviour like this:

all three actions now return 'good', means that delete never cancels the 
action flow.
i've also added the case the index is '0' and asserted that the index 
value is not changed by these illegal actions.
Paul Miniato wrote:
> Hi,
>
> this may turn out to be another one of those XForms "spec
> interpretation bugs", but I hope not.  I think it would be easy to
> "fix".
>
> The attached example shows delete actions that appear to misbehave.
>
> 1.)  Delete None is using a "nodeset" that selects no nodes.
> According to < http://www.w3.org/TR/xforms/slice9.html#action-delete
> > "If the collection is empty, the delete action has no effect." It
> appears that org.chiba.xml.xforms.action.deleteAction.perform() is
> returning false in this case, causing the enclosing action to be
> stopped prematurely.
>
> 2.)  Delete Last is using an "at" that is beyond the size of the
> selected nodeset.  This one I'm not sure about. <
> http://www.w3.org/TR/xforms/slice9.html#action-delete > seems to
> imply that "at" might be treated the same way for delete as it is for
> insert.  At < http://www.w3.org/TR/xforms/slice9.html#action-insert >
> it says "If the resulting index is outside the valid range of the
> node-set, it is replaced with either 1 or the size of the node-set,
> whichever is closer." I know in the delete section it goes on to say,
>  "If no nth node exists, the operation has no effect." However, this
> might be looked at as merely a reiteration of "If the collection is
> empty, the delete action has no effect." So perhaps one could infer
> that Delete Last should delete the last item even if there aren't 4
> (unless there aren't any. ;-)
this are the little delights of spec interpretation ;)

although your proposal would be consistent with the behaviour of insert 
i'll tend to prefer to take it's stated 9.3.6 The delete Element.
Already under 1. you can read:
"If the collection is empty, the delete action has no effect."

and then under 2. (as you've stated):
"If no nth node exists, the operation has no effect."

this means for me that here an index bigger the size of the nodeset must 
be meant cause 1. already 'ensures' the existence of a nodeset.
anyway, not doing anything here is at least less destructive ;) and the 
defensive way to implement it. if we learn something different later we 
can change it - we have tests :)
Joern



> Anyway, #1 is somewhat inconvenient, #2 just a nit.
>
> Thanks, Paul
>
> Paul Miniato Architect/Designer http://ecommerce.cucbc.com

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click