Re: Actions changing the XPath context

John,

Great feedback, thanks.

Many XPath expressions do not actually require a context to be evaluated 
(e.g. "/a/b"), but I am not sure whether there is support for this in 
any spec. XPath 2.0 mentions in a couple of places what happens when the 
context item is "undefined", but does not seem to say how this can arise.

If that was the case however, we may have to consider whether an empty / 
undefined context necessarily prevents execution of the XPath 
expression, or if it does so only if the expression requires the context.

-Erik

John Boyer wrote:
> 
> Hi Eric,
> 
> In the specific case you provided of a pair of setvalue actions, I 
> believe a
> convincing case exists in favor of your expected behavior.
> 
> It is true that the first setvalue makes a change that *would* affect 
> the single
> node binding of the group, except it is clear based on the deferred update
> behavior of XForms actions that the single node bindings are not updated
> immediately after the first setvalue.
> 
> The group's single node binding is updated during the xforms-refresh, which
> occurs in deferred update after the second setvalue.
> 
> On the one hand, you could just modify your question by putting an explicit
> refresh action between the two setvalue actions.  But the more important
> use case that you actually articulated should work.
> 
> Moreover, the above variation is akin to your question at the end about 
> what
> happens if the context node were actually destroyed by a delete.  Moreover,
> this is equivalent to the "Context consuming actions" question I posted 
> to the
> working group:
> 
> http://lists.w3.org/Archives/Member/w3c-forms/2006JanMar/0442
> 
> This was before we switched to the public list.  Anyway, it's winding 
> its way
> up the discussion agenda and will likely have an answer in the next four 
> weeks.
> 
> For what it's worth, I believe that the spec does not define an 
> exception for the
> inability to evaluate a binding expression due to lack of context node, 
> so it is
> reasonable to assume that no exception should occur.  It also seems 
> reasonable
> to conclude that the result is, degenerately, an empty nodeset.  This in 
> turn would
> mean that such actions should simply no-op silently.
> 
> Best regards,
> John M. Boyer, Ph.D.
> Senior Product Architect/Research Scientist
> Co-Chair, W3C XForms Working Group
> Workplace, Portal and Collaboration Software
> IBM Victoria Software Lab
> E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/
> 
> Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
> 
> 
> 
> 
> *Erik Bruchez <ebruchez@orbeon.com>*
> Sent by: www-forms-request@w3.org
> 
> 05/25/2006 01:37 PM
> 
> 	
> To
> 	"'www-forms'" <www-forms@w3.org>
> cc
> 	
> Subject
> 	Actions changing the XPath context
> 
> 
> 	
> 
> 
> 
> 
> 
> 
> All,
> 
> Consider the following simple example:
> 
> <xhtml:html xmlns:xhtml="http://www.w3.org/1999/xhtml"
>             xmlns:xforms="http://www.w3.org/2002/xforms"
>             xmlns:ev="http://www.w3.org/2001/xml-events">
>     <xhtml:head>
>         <xforms:model>
>             <xforms:instance>
>                 <instance>
>                     <sort-by>name</sort-by>
>                     <sort-order>ascending</sort-order>
>                 </instance>
>             </xforms:instance>
>         </xforms:model>
>     </xhtml:head>
>     <xhtml:body>
>         <xforms:group ref=".[sort-by != 'capital']">
>             <xforms:trigger>
>                 <xforms:label>Change</xforms:label>
>                 <xforms:action ev:event="DOMActivate">
>                     <xforms:setvalue
> ref="sort-by">capital</xforms:setvalue>
>                     <xforms:setvalue
> ref="sort-order">ascending</xforms:setvalue>
>                 </xforms:action>
>             </xforms:trigger>
>         </xforms:group>
>     </xhtml:body>
> </xhtml:html>
> 
> When loading up this example, the button should appear. When you
> activate it, the two xforms:setvalue actions will be run in order.
> 
> However, right after the first action has been executed, if you were
> to evaluate the xforms:group single-node binding, it would now return
> an empty node-set. This means that the context for the evaluation of
> the second xfomrs:setvalue is now empty, and you will either get an
> error or the action will do nothing. This may or may not achieve what
> the form author initially intended (in this case, it didn't).
> 
> Note that the single-node binding expression ".[sort-by != 'capital']"
> may be be considered unususal, but it is a very convenient way of of
> hiding and showing controls and groups.
> 
> My questions are:
> 
> 1. Is this meant to work? I not, I believe it should ;-)
> 
> 2. Does XForms 1.0, explicitly or implicitly specify when the
>    xforms:group's single-node binding is evaluated, i.e. is it allowed
>    to re-evaluate it after the first xforms:setvalue?
> 
> 3. What would happen if instead of using xforms:setvalue, I was to use
>    xforms:delete in the action to delete the node to which an
>    enclosing xforms:group is bound?
> 
>    <xforms:delete nodeset="sort-by" at="1"/>
> 
> -Erik
> 
> -- 
> Orbeon - XForms Everywhere:
> http://www.orbeon.com/blog/
> 
> 


-- 
Orbeon - XForms Everywhere:
http://www.orbeon.com/blog/

Received on Monday, 29 May 2006 16:31:10 UTC