Erik's Notes
This functionality would be extremely useful.
Mark made a proposal in this email:
http://lists.w3.org/Archives/Public/www-forms/2007Feb/0045.html
<xf:setvalue ref="event('context')" value="instance('other')/context"/>
<xf:setvalue ref="event('name')" value="@name"/>
<xf:dispatch name="foo" target="m" />
I do not feel that writing to the result of the event() function, as done above, is a good way to go. When event() returns a string or other atomic type, you simply can't write to it. When it returns a node-set, how do you write to the returned node(s)? In any way, it is confusing and not a regular XPath pattern.
Also, the above seems to imply the existence of a sort of event under construction that lives in the air somewhere, and which somehow will be picked by the next xf:dispatch. What happens to it after the first dispatch? Is the event context info cleared? IMO this is not intuitive at all.
The bottom line to me is that the idea of a read-write event() function is flawed.
Another approach could be along the lines of XSLT's xsl:call-template construct:
<xf:dispatch name="foo" target="m">
<xf:context name="context" select="instance('other')/context"/>
<xf:context name="name" select="@name"/>
</xf:dispach>
NOTE: The element is here called xf:context, but other names are possible (xf:with-param, xf:context-info, xf:event, ...).
I think that this would have the benefit of clarity and of following well-accepted patterns.