Re: Context consuming actions

Hi David,

I think the end of your email shows that you are talking about the 
*result* of an expression being an empty nodeset.
I agree that this should result in a "no operation".

What I'm talking about, though, is something different.  It's not that the 
setvalue ref evaluates to an empty nodeset
(as is the case in your example due to some conditional expression).

The problem is that the ref can't even be evaluated because context node 
has been deleted by the immediately
preceding action.  So the setvalue ref can't return an empty nodeset or 
any other result because the condition
for successfully executing an XPath expression does not exist.

There is a key difference between this issue and the one you raised in 
[1], though I can speak to that issue as
well based on my recollection of the recent working group telecon 
discussion of [1].

In my example, we have a delete followed by setvalue.  The problem is 
occuring due to the disappearance
of the context node that must be used to evaluate the ref in the setvalue. 
The setvalue is an action, not a UI control.
Although it has a "single node binding", this only refers to the attribute 
bundle associated with the action.  The
single node binding is not a UI binding, as would be the case if it were a 
form control.  So single node binding of 
actions like setvalue or message are not subject to delayed update during 
a refresh because they are not
UI bindings but rather ephemeral single node bindings that are evaluated 
at the point in time that the action
must be executed.

Your example, a clever one, is different because it places a form control 
(an output) into the content of the 
message action.  So the message action executes, but the question arises 
about the schedule of updating
the node to which the contained output is bound.

Others may have different recollections, but I recall the telecon 
discussion taking the course that the UI 
controls in the message action should behave as if they are created and 
bound at the time the message
is executed.  An implementation that creates the controls beforehand would 
be responsible for updating
the UI it must display immediately before displaying it in such a way that 
it is indistinguishable from a UI
that has just been ephemerally generated.

So, in conclusion, I do also agree that nothing in the spec suggests that 
a *binding exception* in particular
should occur when the single node binding of an action has no context node 
from which to evaluate, but
the XPath implementation we use follows the XPath Rec closely on this 
point and generates an internal
error if we hand it a starting context devoid of a context node.  We could 
generate that exception instead, but 
in any case the spec doesn't say what exception to generate, so we picked 
binding exception as the most
natural fit because something is wrong with the form author's attempt to 
create a single node binding in
an action after a prior action of the form author's design has wiped out 
the context node.

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/boyer/index.jsp





David Landwehr <david.landwehr@solidapp.com> 
03/31/2006 11:32 PM

To
John Boyer/CanWest/IBM@IBMCA
cc
www-forms@w3.org, w3c-forms@w3.org
Subject
Re: Context consuming actions






Hi John,

I believe this problem is related to the one I send to the list a while 
back [1]. In my implementation since the UI's bindings is first rewire in 
the refresh event and your event sequence is running in a deferred action 
scope then the trigger will first have a null context after the action 
block. If you had a xforms:refresh between the delete and setvalue then 
the setvalue would get a null context.

So in my implementation I only update the context for the UI in the 
refresh handling. I execute the XPath expression on actions for every 
execution (I'm unsure if the specification is clear about this). My XPath 
implementation can handle that the trigger's context node is no longer in 
the document and e.g. <setvalue ref=".."/>  evaluate to a null node in 
your example.

I wouldn't use an exception for this scenario at all. I thought that a 
null context for an action would result in a NOP. That is want I do since 
I thought binding-exception was used only when something was bad with a 
IDREF pointing no way or to something wrong. Also the point that an 
exception terminates processing seems a bit to much for me since it could 
be intentional by the author. E.g.
<xforms:setvalue ref="self::node()[conditional expression]" value="[value 
expression]"/>
if the conditional expression make the ref evaluate to the empty node-set 
would the value expression then also dispatch a binding exception? I guess 
it shouldn't and that this scenario is not really different from yours.

Best regards,
David

[1] Question about updating UIInline inside of message
http://lists.w3.org/Archives/Public/www-forms-editor/2006Jan/0009.html

Den Mar 31, 2006 kl. 9:38 PM skrev John Boyer:


We have been assuming up to now that if an action consumes the context 
node, then any subsequent action requiring an XPath evaluation should 
fail with an exception. 
We've been using binding exception as the most reasonable exception, 
but because this exact case is not called out in the spec, it seems 
reasonable 
to ask the community about it... 

How are other XForms implementers handling this case?   

To be specific, suppose you have an action sequence that 
performs a delete action followed by a setvalue.  However, 
let the delete destroy a node that either is or is an ancestor of 
the context node for the action sequence. 

What happens when the setvalue runs? 

<trigger ref="/some/node"> 
   <label>Don't press me</label> 
   <action ev:event="DOMActivate"> 
         <delete nodeset="." at="1"/> 
         <setvalue ref="." value=" 'oops' "/> 
   </action> 
</trigger> 

Thanks, 
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/boyer/index.jsp