Proposed Spec Changes for new model-item-constraint events

As agreed to at the last WG telecon,
 
Add to section 4.3 "Interaction Events", the following events
 
xforms:relevant
xforms:irrelevant
xforms:required
xforms:notrequired
xforms:readonly
xforms:notreadonly
 
Comments are in [] by me (Ray)
 
[Issue: are these the right names? Or should they be something like
xforms:relevantChanged]
[Issue: do we need notification events for minOccurs/maxOccurs? To be
complete, we should, but what should be call them?]
 
These events are dispatched only when there is a change to the
underlying model-item-constraint.
 
All events are similar to xforms:valid
 
Target: form control   [Comment: because form controls are what are
effected by the change]
Bubbles: yes            [Comment: because someone might wish to write a
global event handler]
Cancelable: no         [Comment: not sure why xforms:valid says it is
not cancelable]
Context Info: none 
Default Processing: none, notification event only  
 
[Comment: if CSS WG adopts pseudo-classes for these UI states, and if
the CSS DOM had fields to specify where something was relevent,
required, etc then in the future, the default processing might say
something like "set the pseudo-class field X to true/false" to reflect
the event into the underlying UI state. For now, there is no default
processing and it is assumed that UI control state updated by an
implementation specific mechanism]]
 
[Issue: Should we clarify the xforms:recalculate and xforms:refresh
sections of the spec to say that recalculate updates dirty bits on model
item properties and xforms:refresh picks these up and issues the
appropriate notification events? Or should we say they are issued
directly from the recalculate handler? Or, should we just leave it up to
the implementation the exact sequence in which the events are
generated?]
 
-Ray