Re: Question about errata 2.3 E70a

Hi David -- just to wrap-up the discussion on the point below, you remark:

>>I was hoping that the working group will change the wording for E70a to 
>>something less specific for what can change the nodes value.

You'll note that in the 1.0 Second Edition text, section 7.3.3, the note 
referring to the need for a full recalculation following script-based 
instance changes has been removed.  This should resolve the use case you 
raised in your note below.

Thanks, Charlie Wiecha




David Landwehr <david.landwehr@solidapp.com> 
02/16/2006 10:38 AM

To
Charles F Wiecha/Cambridge/IBM@IBMUS
cc
www-forms-editor@w3.org
Subject
Re: Question about errata 2.3 E70a






Thanks for the answer. Just to be sure I understand your answer, then 
take the following script:

var model = document.getElementById('model');
var instance = model.getInstanceDocument('instance');
instance.documentElement.firstChild.nodeValue = 'some value';

So if someone did this and forgot to do model.rebuild(), 
model.recalculate() and later on changed a value from an input control 
then the wording in E70a says that controls bound to the document 
element's first child must not participate in the calculate and that no 
events must be fired from them. And what your answer say is that the 
working group are working on an API for letting that node participate in 
the value-changed processing?

Depending on the choices by the implementor I must remark that this 
requirement can be extremely inefficient. This is because some 
implementations might chose to listen for DOM mutation events or 
equivalent for marking the changed nodes. Now E70a puts a requirement 
that this marking must know who changed the node and decide if it should 
be mark or not. To do something like this could require the 
implementation to return a proxy DOM from getInstanceDocument() to 
changed the behavior of the marking process. To return a proxy DOM would 
be extremely inefficient.

You might wonder why the XForms controls and actions cannot mark the 
nodes them-self. The reason for this could be that implementations that 
allow for other to extend the XForms markup with additional controls and 
actions would not want people to remember marking a node when they 
change the value.

I was hoping that the working group will change the wording for E70a to 
something less specific for what can change the nodes value.

Best regards,
David

Charles F Wiecha wrote:
>
> David -- as you point out, an instance node may be changed by 
> recalculate or setvalue, both of which will mark the node for 
> participation in subsequent xforms-value-changed event processing. 
>  There is currently no API defined for setting an instance value by 
> script such that the node will then participate in value-changed 
> processing. 
>
> The topic of expanding the model interface definitions to include such 
> support is actively being discussed.  In the meantime, the potential 
> for error in dispatching xforms-value-change events "manually" -- i.e. 
> apart from the normal model lifecycle supported by the underlying 
> implementation -- suggests this not be done.
>
> Any input you may have on requirements for additional APIs to support 
> this type of function would be welcome.
>
> Thanks, Charlie Wiecha 


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