Re: Context consuming actions

Hi John,


>
> I think the end of your email shows that you are talking about the 
> *result* of an expression being an empty nodeset.
No I was referring to the evaluation of the @value not of the evaluation 
of the @ref. I guess the difference is that in the case of @ref explicit 
check the result before evaluation the @value.
> I agree that this should result in a "no operation".
Ok
>
> 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.
Ok. The point I was trying to make was that the trigger is still bound 
to the node which was removed from the document. The trigger's ref is 
first (in my implementation) reevaluated in the refresh processing. So 
just because the node is removed from the document does not make any 
changes in my UI before after the refresh.
>
> 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].
Hmm ok.
>
> 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.
I my implementation the context node does not disappear but is simply 
removed from the DOM. The setvalue's ref can in my implementation be 
evaluated by the context from the trigger which hasn't been updated yet.
> 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.
Perfect. I would hate that the setvalue's ref was deferred, but that is 
not what is going on in my implementation. It is the context from the 
trigger which isn't updated. The trigger is a UI control and its binding 
is subject for the deferred update processing, hence it will first be 
updated in the next refresh cycle.
>
> 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.
>
I just thought some of the problem you raised is similar since the 
trigger's ref is first updated in the refresh cycle and hence is still 
bound to the node which were removed when the setvalue action is invoked.
> 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.
>
Ok.
> 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.
>
I have a big problem with termination processing when situations like 
this occurs. The reason is that I would have to check in my 
implementation every evaluation of actions whether the context's node is 
in or out of the instance document. The problem would not be easier in 
XForms 1.1 since the event() function returns object which isn't in any 
document and hence should be checked in some other way.

Now the problem you have raised could appear in my implementation if the 
action had the following appearance:
<trigger ref=".">
  <action>
    <delete>
    <refresh>
    <setvalue>

Now the ref on the trigger will be the empty node-set after the refresh 
and the setvalue will have an empty context. In my implementation I 
return an empty node-set when there is no context node for an 
evaluation. Hence the setvalue's @ref will be evaluated to the empty 
node-set and the invocation will be a NOP.

Best regards,
David

> 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_
>
>


-- 
--------------------------------------------
David Landwehr (david.landwehr@solidapp.com)
Chief Executive Officer, SolidApp
Web: http://www.solidapp.com
Office: +45 48268212
Mobile: +45 24275518
--------------------------------------------

Received on Tuesday, 4 April 2006 09:20:00 UTC