W3C test case 10.4.f is wrong (I think)

[GoogleCodeExporter]

I've been looking into issue 417, raised because UXF is failing test case 
10.4.f. However, as I started looking into it, I realised that test case 
10.4.f itself looks wrong to me. But I'm not an XForms expert, so I'm 
raising this with the hope that one of the gurus out there can provide more 
feedback.

At the risk of being too verbose, I'm going to start by quoting the 
relevant part of the spec, which is what I've formed my opinion based on:

"If one or more nodes have been removed from the repeat collection by a 
delete action, then the repeat items corresponding to the deleted nodes 
must be destroyed and the repeat index must be updated based on the rules 
below.

1. If, prior to node deletion, the repeat index indicated a repeat that is 
still contained in the repeat collection after node deletion, then the 
index is adjusted, if necessary, to indicate that same repeat item.

2. Otherwise, if all repeat items in the collection have been destroyed, 
the repeat index is set to 0 .

3. Otherwise, if the repeat index was pointing to one of the deleted repeat 
items, and if the new size of the collection is smaller than the index, the 
index is changed to the new size of the collection.

4. Otherwise, if the repeat index was pointing to one of the deleted repeat 
items, and if the new size of the collection is equal to or greater than 
the index, the index is not changed. 

Note: The change of index on a repeat does not cause the index of any 
repeat nested within it to be re-initialized."

So with that in mind, here is why I think the test is wrong. The test is 
divided into three parts, each with its own dedicated instance. The first 
part of the test is fine. The parts that I think are wrong are the second 
and third parts.

Each of them tests a nested repeat couplet, operating on separate copies of 
the following nodeset:

<number_list id="1st number_list">
  <number xsi:type="xsd:integer">1</number>
  <number xsi:type="xsd:integer">2</number>
  <number xsi:type="xsd:integer">3</number>
</number_list>
<number_list id="2nd number_list">
  <number xsi:type="xsd:integer">4</number>
  <number xsi:type="xsd:integer">5</number>
  <number xsi:type="xsd:integer">6</number>
</number_list>
<number_list id="3rd number_list">
  <number xsi:type="xsd:integer">7</number>
  <number xsi:type="xsd:integer">8</number>
  <number xsi:type="xsd:integer">9</number>
</number_list>

The second part of the test performs these operations:

  1. Set the outer repeat index to 3;
  2. Set the inner repeat index to 3;
  3. Delete the third number_list node.

According to the spec, I would expect this to leave the outer repeat with 
an index of 2 and the inner repeat with an index of 3. But the test expects 
the inner repeat index to be 1 (and as it happens, UXF behaviour conforms 
to the test on this part).

The third part of the test performs these operations:

  1. Set the outer repeat index to 2;
  2. Set the inner repeat index to 3;
  3. Delete the second number_list node.

According to the spec, I would expect this to leave the outer repeat with 
an index of 2 and the inner repeat with an index of 3. But the test expects 
the inner repeat index to be 1 (in this case, UXF returns an index of 3 for 
the inner repeat, which is the failure described by issue 417).

So who is wrong; me or the test suite?

Original issue reported on code.google.com by phil.boo...@gtempaccount.com on 17 Apr 2009 at 12:40

[GoogleCodeExporter]

Hi Phil.

I think the note you refer to simply means that any index values on inner 
repeats are
preserved across changes to outer repeats, rather than getting reset.

The effect is that if you 'revisit' an outer repeat index, any changes you 
previously
made to the inner repeat should be restored.

Here is a sequence to illustrate the point:

1. Set the outer repeat index to 3;
2. Set the inner repeat index to 3;
3. Set the outer repeat index to 1.

The inner repeat index should be 1 because it was never changed for outer index 
value 1.

4. Set the outer repeat index to 3 again.

The inner repeat index should now be back to 3, since that was its value when 
the
outer index was last set to 3.

Another way to look at it is that each row of the repeat has its own index 
value,
which is initialised to 1, but doesn't change as the different rows are 
selected and
deselected.

Original comment by mark.bir...@gtempaccount.com on 17 Apr 2009 at 1:10

[GoogleCodeExporter]

Issue 323 has been merged into this issue.

Original comment by phil.boo...@gtempaccount.com on 22 Apr 2009 at 3:54

[GoogleCodeExporter]

Hi Mark. It is funny, because I read the spec as meaning the exact opposite of 
your 
understanding. Are you 100% certain of your take on it? If so, I'll crack on 
and change 
UXF accordingly. If not, I'll send an email to the WG (if you think that is a 
good 
idea) to try and get the authoritative opinion.

Original comment by phil.boo...@gtempaccount.com on 23 Apr 2009 at 8:51

[GoogleCodeExporter]

Hi Phil,
I read your description, the verbosity of which was helpful.
The spec is written in terms of repeat items, not repeats.
For the inner repeat, there is supposed to be one index maintained *per outer 
repeat 
item*.
When the test starts, it sets the outer repeat index to 3, then it sets the 
repeat 
index of the third outer repeat item's inner repeat to 3.  The first and second 
outer repeat items have inner repeat indices of 1.
When the test deletes the third repeat item of the outer repeat, the outer 
repeat 
index becomes 2 as you say.
However, the deletion has no effect whatsoever on the indexes of the two 
occurences 
of the inner repeat.  The inner repeat in the second outer repeat item should 
have 
an index of 1 because it was never changed from that value in the 
initialization.
I think the difference is that you are considering there to be only one index 
for 
the inner repeat across all of its occurrences in the outer repeat, but this is 
not 
the case.  Every occurrence of a repeat gets a separate index to work with.

Original comment by John.Boyer.PhD@gmail.com on 24 Apr 2009 at 1:55

• Changed state: Invalid