Re: implementors question: correct behavior of nested nodeset in repeat

I think removing the restriction is a good idea.

For the record, I believe the restriction was put in place
because at the time repeat was designed some members of the WG
were uncomfortable about how flexible/powerful it felt.

The initial design for repeat that I did along with Josef Dietl
was based on lisp's mapcar (map for non-lispers)
--- 

Erik Bruchez writes:
 > 
 > John & all,
 > 
 >  > Although there is reasonably strong support for removing the notion
 >  > of homogeneous collection in principle, I believe we did not resolve
 >  > to do so.
 > 
 > As an official WG resolution, no, I don't think so.
 > 
 >  > I believe the sticking point was around the loss of the single
 >  > common parent more than anything else, although continuity is useful
 >  > too.
 > 
 > In our implementation, we have not found any usefulness in having a
 > common parent or continuity as an assumption.
 > 
 > If a form author wants a common parent and continuity, he is of course
 > free to use that, and that is in fact a very common use-case.
 > 
 >  > But for the repeat itself, it becomes more difficult to
 >  > *efficiently* detect whether the repeat needs to be updated.  One
 >  > could, for example, create a listener on the single common parent to
 >  > detect any addition or deletion of a child element and use that to
 >  > know whether the nodeset for the repeat needs to be re-evaluated.
 >  > The nodeset may still be the same, in which case the repeat does not
 >  > get updated, but having the single common parent as the focal point
 >  > means that in a larger form I don't have to check every repeat
 >  > nodeset whenever *any* node is inserted or deleted.
 > 
 >  > If we make this change, then the addition or deletion of a node *in
 >  > any instance* would require the reevaluation of all nodesets of all
 >  > repeats bound to that model.  It can be done, but it's slower.
 > 
 > You could probably still make your implementation more efficient when
 > you detect a homogeneous node-set. Then it is up to the form author to
 > decide if he wants faster performance and restrict himself to a
 > homogeneous collection, or potentially slower performance and enjoy
 > unrestricted repeats. The performance argument is fairly theoretical
 > anyway...
 > 
 > I think that it is completely reasonable and desirable to remove this
 > restriction for the following reasons:
 > 
 > * It makes the spec confusing because the reason for the existence of
 >    the restriction is not explained and probably difficult to
 >    convincingly explain. Even XForms specialists in this mailing-list
 >    have trouble explaining to each other why it is a good restriction
 >    to have!
 > 
 > * Removing the restriction arguably can make an implementation
 >    simpler. At worst, it won't make the implementation much more
 >    complex. Probably that several XForms implementors are likely to be
 >    able to confirm this.
 > 
 > * xforms:repeat is one of the most powerful features of XForms, and
 >    there are numerous use cases where this restriction gets in the
 >    way. Remember also that you don't always use xforms:insert and
 >    xforms:delete with xforms:repeat: you may have "read-only"
 >    xforms:repeat (repetitions over collections that don't change over
 >    the life or the form), or use a repeat on an instance that is
 >    updated by replacement (a point not really covered by the spec I
 >    believe).
 > 
 > -Erik
 > 
 > -- 
 > Orbeon Forms - Web Forms for the Enterprise Done the Right Way
 > http://www.orbeon.com/
 > 
 > 

-- 
Best Regards,
--raman

Title:  Research Scientist      
Email:  raman@google.com
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman 
GTalk:  raman@google.com, tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc

Received on Thursday, 1 March 2007 22:40:55 UTC