- From: John Boyer <boyerj@ca.ibm.com>
- Date: Mon, 16 Apr 2007 16:55:00 -0700
- To: public-forms@w3.org, www-forms-editor@w3.org
- Message-ID: <OF1228E847.B79453A5-ON882572BF.0080EB10-882572BF.008362CB@ca.ibm.com>
I seem to recall some years-old discussions about the effect of a repeat index change on the XForms processor. I seem to recall a face to face discussion in which it was suggested that a repeat index change should correspond to an automatic rebuild because bind nodesets or MIP expressions may contain invocations of the index() function. I also recall the conversation indicating that implementations could do something more optimized that a full rebuild, such as focusing on binds that actually invoke index() on the affected repeat since those that don't would be unaffected. However, note that XForms 1.0 SE and XForms 1.1 both now say (in 9.3.8) that changing the focus to a control in a repeat item (row) other than the indexed repeat item does cause the repeat index to implicitly change. In combination with the statement above, this would mean an implicit rebuild-recalculate-revalidate-refresh based. Moreover, changing focus may change the index of multiple repeats that are nested, so one's spidey sense gets the tingle of another optimization. But the problem is that I cannot find any language in the XForms spec that even implies a connection between repeat index changes and automatic rebuilding. For the record, I think the connection between repeat index and rebuild is wrong, and I was going to write a last call comment to suggest its removal. But alas I have been foiled by the fact that it already doesn't seem to exist in the spec. If someone can find this, please let me know; otherwise I will proceed on the assumption that the spec does not follow a repeat index change with an automatic rebuild. I believe that the original discussion about automatically rebuilding on index change was held, at least in part, from a desire to correct for the fact that index() *could be* invoked from the XPaths within an XForms bind (i.e. from model binding expressions). However, since such automatic rebuild is ultimately doomed to failure (because of automatic index changes on focus change in 9.3.8), it seems better to consider restricting the index() function to only being used in certain cases. Clearly, the index() function was designed for use in the XPaths of XForms actions. When index() is used in a UI binding, it is possible though somewhat difficult to create problems due to the staleness of the result. More significant problems are easier to produce when index() is used in a model binding expression. In the past, this would have been hard, but XForms now requires different exception behavior based on where an XPath is located. For example, in Section 7.1, the choice of a binding exception versus a compute exception is based on where the XPath is located. An invocation of index() appearing in any XPath other than those used in XForms actions should either produce NaN or preferrably an appropriate exception. 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: boyerj@ca.ibm.com Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Received on Monday, 16 April 2007 23:55:53 UTC