when and how readonly MIP prevents data mutations

Dear WG & Editor,

I think the XForms readonly model item property is not defined in clear 
enough terms, esp. from the implementer's perspective. This lack of 
clarity persists in the current XForms 1.1 draft. The section 6.1.2 says: 
Description: describes whether the value (!) is restricted from changing. 
(*)
          ...
Then it follows:
When evaluating to true, this model item property indicates that the 
XForms Processor should not allow any (!) changes to the bound instance 
data node. (**)
In addition to restricting value changes, the readonly model item property 
provides a hint to the XForms user interface. Form controls bound to 
instance data with the readonly model item property should indicate that 
entering or changing the value is not allowed.(***)


1. Let's assume for a moment that an implementer should interpret (**) 
literally, this would mean that all calculate properties shall by default 
fail to change their respective instance nodes since for all the said 
nodes the readonly property will evaluate to true() by default.
2.  Again assuming that the readonly node is totally immutable suggests 
that there are omissions or in the sections of the draft describing 
processing of the insert, delete, setvalue, and reset actions as well as 
submissions with replace="instance" or "text". Notably, there is no 
defined response if an attempt is made to change 'readonly' node by these 
means. 
3. A side issue with (**) is that if an application is to use instance 
document  via exposed DOM interfaces [getInstanceDocument()] it is 
expected to use DOM methods to possibly mutate it (that's why the 
rebuild(), etc are for) and since there is no DOM access to MIPs there is 
no way the application can honour the 'no-changes-to-readonly-nodes' rule.

To sum it up, I can clearly see how useful and mostly straight forward 
(with the possible exception of 'readonly' trigger & submit.) is the 
application of the readonly property by Form controls (as in ***) However, 
in my opinion, the use of this property to restrict data mutations by 
other means is either misplaced or underspec'd.

Best regards,
Vlad Trakhtenberg