Re: LC: Issues with repeat index manipulation and generalized insert/delete actions (PR#21)

The working group accepted this LC comment, and further requested in the
resulting action item (Action 2007-08-15.3) that the content of should be
accounted for.

The solution has been implemented and now appears in the editor's draft
available from the working group homepage.  See in particular sections 9.3.3 and
9.3.4 of the specification for language about repeat index management during
repeat processing and user interaction, and note that the insert and delete
actions have been moved to Section 10 and stripped of language pertaining to
repeat index management (except for notes referring the reader back to Section

John Boyer

> Three issues regarding Section 9.3.5 and 9.3.6 (and technically 9.3.1):
> 1) When insert or delete actions occur, the repeat index is updated for
> any repeat bound to node(s) inserted or deleted.
> Currently, this is described in the insert and delete actions, which is
> inappropriate since it is a property of repeats.  The intent of insert and
> delete in XForms 1.1 is to be generalized data manipulators, so they
> should not contain language about manipulating repeat indices.
> Moreover, now that we have the proper context information in xforms-insert
> and xforms-delete it is even possible to describe how repeat index
> manipulation could be achieved by having repeat semantics imply listeners
> for xforms-insert and xforms-delete with index update according to whether
> the nodes listed are applicable to the given repeat.
> Although this is an implementation, I think it is important to preserve
> the property that the repeat indices are updated immediately (as is the
> case now) and not at some later time that might seem more obvious, such as
> xforms-refresh.
> 2) It is completely unacceptable to me that the index of a nested repeat
> is reset when its containing repeat's index is updated.  This behavior
> should simply be stricken from XForms 1.1 as there is no earthly reason
> for doing it.
> I believe it was added to XForms 1.0 at a time when repeating was not
> nearly as well understood as it is now.  I believe there was the thought
> that there would only exist one instance of a data structure to represent
> any repeat, including an inner repeat,  Hence the index of that object
> would be changed to the start value in a newly inserted repeat item
> (9.3.5, bullet 8).  I believe similar reasoning was used to arrive at
> inner repeat reinitialization in the delete case (9.3.6 bullet 5).
> However, we now know that inner repeats are similar to inner switches in
> an outer repeat.  Just as the selected case of a switch may be different
> in each repeat item, the index of an inner repeat may be different in each
> repeat item.  Hence there is no need to modify the indexes of inner
> repeats when a repeat item in the outer repeat is created or destroyed,
> just as there is no need to reset the cases of all switches in all repeat
> items just because one is added or deleted.
> Alternately, observe that if the inner repeat index adjustment really were
> necessary on insert and delete, then there would be a flaw in that case
> adjustment of repeated switches would also be needed, and the spec makes
> no allowance for this.
> The proposed solution is that XForms should retain only the simpler
> behavior which says that a repeat index is updated if the context node of
> the indexed repeat item is deleted or if a new node is inserted into the
> 3) Insert and Delete are now in the wrong section.
> In XForms 1.1, insert and delete have become generalized data
> manipulators.  They are not really tied to repeat anymore in that we do
> suggest their use in other cases, like extracting the data payload from a
> SOAP envelope.  To avoid confusion that insert/delete should only be used
> with repeated data, they should be moved to Section 10.
> This of course is another good argument for moving the index updating
> logic to repeat in 9.3.1.
> John M. Boyer, Ph.D.
> STSM: Lotus Forms Architect and Researcher
> Chair, W3C Forms Working Group
> Workplace, Portal and Collaboration Software
> IBM Victoria Software Lab
> E-Mail:
> Blog:

Received on Thursday, 6 September 2007 21:36:51 UTC