- From: Ray Whitmer <rayw@netscape.com>
- Date: Fri, 21 Feb 2003 10:11:47 -0800
- To: www-dom@w3.org
Sorry I did not respond to this earlier. [...] > <xforms:model> > <xforms:instance> > <data xmlns=""><a/><a/><a/></data> > </xforms:instance> > <xforms:bind nodeset="/data/a" calculate="position()"/> > </xforms:model> > > The 'bind' will select all a's (the selected nodeset) from the > instance > document, for each a the 'calculate' expression will be evaluated using > the > context position in the selected nodeset and the size of the selected > nodeset as > the context size. This will produce the following instance: > > <data xmlns=""><a>1</a><a>2</a><a>3</a></data> The example is a bit confusing to me as you have given it, mostly because I am not familiar with this sort of function of XForms. I think it is quite safe to say that DOM XPath never creates significant new content as part of it's execution, as the example appears to do. It returns existing nodes, and that is all. I assume you are saying that XForms would construct the new instance, but merely needs to be able to execute the position function within the context of each node in the former node set, reentering the active XPath context. You have suggested one of several ways to do this. XSLT, like XForms, would need this sort of extension to accomplish it's work. If someone were defining a custom XPath function that needed to reinvoke XPath in it's full context, this sort of thing would be needed in that case, too. It is clear that an an XSLT processor would also need additional interfaces for providing custom variable and function extensions required by XSLT. This sort of thing was considered out of scope for this version of the interface (see http://www.w3.org/2002/03/DOM-Level-3-XPath-issues/all.html#a6). Ray Whitmer rayw@netscape.com
Received on Friday, 21 February 2003 13:11:17 UTC