W3C home > Mailing lists > Public > public-forms@w3.org > June 2007

regarding Action 2007-05-23.2: Value changes upon instance replacement

From: Joern Turner <joern.turner@dreamlab.net>
Date: Wed, 06 Jun 2007 13:14:59 +0200
Message-ID: <46669733.7060508@dreamlab.net>
To: public-forms@w3.org

Dear group,

after investigation i found that most of the issue has already been
answered by John Boyer in:
http://lists.w3.org/Archives/Public/public-forms/2007May/0081.html

I fully agree with his John's position. His arguments which i summarize
here shortly for reference:

- MIP events are fired during refresh. Refresh does not happen during
init as controls are *created* (not updated/refreshed) and get to their
state directly without the need for the MIP events. So init and instance
replacement are two different cases which should be kept separate (my
conclusion)

- after a successful instance replacement a refresh (which in
turn will trigger the MIP events) will happen as stated under "11.2 The
xforms-submit Event":

"Once the XML instance data has been successfully replaced, the rebuild,
recalculate, revalidate and refresh operations are performed on the
model, without dispatching events to invoke those four operations. "

In conseguence the problem boils down to the description of the
xforms-refresh Event as John already pointed out.


Proposed new text:

4.3.4 The xforms-refresh Event

(...)
2. A node can be changed by confirmed user input to a form control, by
xforms-recalculate (section 4.3.6), by the setvalue (section 10.1.9)
action or by instance replacement (section 11.18). If an instance data 
node was changed or has been replaced, then the node must be marked for 
dispatching the xforms-value-changed event.

Explanation:
First sentence now mentions the instance replacement as a explicit 
source for value changes. In the second sentence i've deleted 'the value 
of' - i think it's not necessary to talk about the *value* of a node 
here cause a change to the value is of course also a change to the node 
itself.

Though the semantics of xforms-value-changed is not a perfect match 
because of the 'value' in it i do not see another easy solution without 
reworking other parts of the Spec or maybe even inventing a new 
'xforms-instance-replaced' event.

We can even argue that the value of a node has changed even in case it's 
an equally named node with an identical value. The node would not have 
the same identity and so its value as John already pointed out:

"Note that this should occur whether or
not the literal value has changed because the node containing the value
has changed, i.e. it is a different string even if it contains the same
lexical value."

Joern
Received on Wednesday, 6 June 2007 11:12:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:43 UTC