Fw: when and how readonly MIP prevents data mutations (PR#176)

John M. Boyer, Ph.D.
STSM: Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer


----- Forwarded by John Boyer/CanWest/IBM on 10/18/2007 01:03 AM -----

John Boyer <xforms-issues@mn.aptest.com> 
10/18/2007 12:54 AM

To
John Boyer/CanWest/IBM@IBMCA
cc
xforms-issues@mn.aptest.com
Subject
Re: Fw: when and how readonly MIP prevents data mutations (PR#176)






Hi Vlad,

The working group agrees that the applicability of readonly is 
underspecified.
The working group decided that readonly is an inviolate property of the 
model. 
This means that form controls cannot modify readonly nodes to which they 
are
bound, of course, but it also means that XForms actions and submissions 
have
restrictions as well.  Specifically, neither setvalue nor text replacement
submission can modify a readonly node and neither insert, delete nor 
instance
replacement submission can modify a node whose parent is readonly.

The reason for checking the parent node in the case of insert is clear: 
the node
could not be readonly until after it is inserted.  In the case of delete 
and
instance replacement, the view is that node deletion does not change the 
node. 
However, node insertion or deletion (and hence replacement) does change 
the
*conten* or attribute axis of the parent, which is what readonly is 
intended to
protect.

The editor's draft available from the working group page has been updated 
to
reflect these substantive changes to XForms 1.1.  Please let us know if 
you have
any further concerns regarding the changes made.

Thanks,
John Boyer

> This is a multipart message in MIME format.
> --=_alternative 001AF15688257331_=
> Content-Type: text/plain; charset="US-ASCII"
> 
> ----- Forwarded by John Boyer/CanWest/IBM on 08/07/2007 09:53 PM -----
> 
> Vlad Trakhtenberg/CanWest/IBM@IBMCA 
> Sent by: www-forms-request@w3.org
> 08/04/2007 12:00 PM
> 
> To
> www-forms-editor@w3.org
> cc
> www-forms@w3.org
> Subject
> 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 
> 
> --=_alternative 001AF15688257331_=
> Content-Type: text/html; charset="US-ASCII"
> 
> 
> <br><font size=2 face="sans-serif"><br>
> </font>
> <br><font size=1 color=#800080 face="sans-serif">----- Forwarded by John
> Boyer/CanWest/IBM on 08/07/2007 09:53 PM -----</font>
> <br>
> <table width=100%>
> <tr valign=top>
> <td width=40%><font size=1 face="sans-serif"><b>Vlad
> Trakhtenberg/CanWest/IBM@IBMCA</b>
> </font>
> <br><font size=1 face="sans-serif">Sent by: 
www-forms-request@w3.org</font>
> <p><font size=1 face="sans-serif">08/04/2007 12:00 PM</font>
> <td width=59%>
> <table width=100%>
> <tr valign=top>
> <td>
> <div align=right><font size=1 face="sans-serif">To</font></div>
> <td><font size=1 face="sans-serif">www-forms-editor@w3.org</font>
> <tr valign=top>
> <td>
> <div align=right><font size=1 face="sans-serif">cc</font></div>
> <td><font size=1 face="sans-serif">www-forms@w3.org</font>
> <tr valign=top>
> <td>
> <div align=right><font size=1 face="sans-serif">Subject</font></div>
> <td><font size=1 face="sans-serif">when and how readonly MIP prevents 
data
> mutations</font></table>
> <br>
> <table>
> <tr valign=top>
> <td>
> <td></table>
> <br></table>
> <br>
> <br>
> <br><font size=2 face="sans-serif"><br>
> Dear WG & Editor,</font><font size=3> <br>
> </font><font size=2 face="sans-serif"><br>
> I think the XForms <b>readonly</b> 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 
<b>6.1.2</b>
> says: </font>
> <p><font size=3 face="sans-serif">Description: describes whether the
> <i>value</i>
> (!) is restricted from changing. (*)</font><font size=2
face="sans-serif"><br>
>  Â  Â  Â  Â  ...<br>
> Then it follows:</font><font size=3> </font>
> <p><font size=3 face="sans-serif">When evaluating to true, this model 
item
> property indicates that the XForms Processor should not allow <i>any</i>
> (!) changes to the bound instance data node. (**)</font><font size=3> 
</font>
> <p><font size=3 face="sans-serif"><i>In addition</i> to restricting
<i>value</i>
> 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.(***)</font><font size=3> <br>
> <br>
> </font><font size=2 face="sans-serif"><br>
> 1. Let's assume for a moment that an implementer should interpret (**)
> literally, this would mean that all <b>calculate</b> properties shall by
> default fail to change their respective instance nodes since for all the
> said nodes the <b>readonly</b> property will evaluate to true() by
> default.</font><font size=3>
> </font><font size=2 face="sans-serif"><br>
> 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 <b>insert</b>, <b>delete</b>, <b>setvalue</b>, and <b>reset
</b>actions
> as well as submissions with <b>replace</b>="instance" or
> "text".
> Notably, there is no defined response if an attempt is made to change
'readonly'
> node by these means. <br>
> 3. A side issue with </font><font size=3 
face="sans-serif">(**)</font><font
> size=2 face="sans-serif">
> is that if an application is to use instance document  via exposed
> DOM interfaces </font><font size=3>[getInstanceDocument()] </font><font
size=2
> face="sans-serif">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.</font><font
> size=3>
> <br>
> </font><font size=2 face="sans-serif"><br>
> 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 <b>readonly</b> 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.</font><font size=3>
> <br>
> </font><font size=2 face="sans-serif"><br>
> Best regards,</font><font size=3> </font><font size=2 
face="sans-serif"><br>
> Vlad Trakhtenberg</font><font size=3> </font><font size=2
face="sans-serif"><br>
>  </font><font size=3>Â </font>
> --=_alternative 001AF15688257331_=--
> 
>