MIPs as information, behavior of setvalue/insert/delete/submission/etc for readonly nodes, and the MVC architecture

MVC is a well-known architecture, which we have long claimed was the basis 
for XForms.

I believe that our version of "model" is a little different that classic 
MVC because in classic MVC the data model is passive, providing only the 
data and accessors.  We embellish it with "model item properties" that 
calculate results and annotate the data with information such as relevance 
and validity. 

But it has *always* been clear that (despite _some_ confusion over the 
exact definition of form control) that the "view layer" is defined by the 
core form controls, and the containers, and specifically that XForms 
"actions" are not part of the view layer because they do not provide a 
view.  They have a different kind of binding.  It is a foreign idea that I 
cannot use the term "controller" to describe them; MVC is, in my opinion, 
well-known enough and calling it out as an ill-defined term is rather like 
saying "iteration" and "loop" and "exception" are not properly defined in 
our spec.

You can call them whatever you like, but in the MVC architecture, actions 
live in the controller piece, not the model piece.  The fact that you can 
put XForms actions INTO the model is mere syntax sugar offered by XML 
events.  Suppose, for example, that we excluded XForms actions from the 
content model of XForms model.  One can still hook the events targeted at 
a model, its instances and its submission from the outside by simply using 
more XML events attributes.  Being inside the content of a model element 
is meaningless for deciding whether actions are "part of the model or the 
controller". The key issue is whether the thing performs an imperative 
change or change sequence in response to an event.  That's a controller in 
MVC parlance.  You can have a controller that modifies the model, or it 
can modify the view.  For example, you can write an xforms-ready handler 
*inside* the model and have it toggle a switch in the view layer.  Would 
you say that the toggle is part of the model when clearly it is 
controlling an aspect of the view layer?  Of course not.

The fact that XForms actions are part of the controller  means they are 
not part of the model, but also (as stated above) that they are not part 
of the view layer either, even if the actions appear within view layer 
content.  This is part of why I do not believe that the use of ref in 
setvalue implies, in any way, that setvalue consumes any model item 
properties, and most notably not readonly.

A similar issue arises with setvalue and relevant.  Should a setvalue not 
occur on a non-relevant node?  The spec makes no connection between 
setvalue and these MIPs and it makes no effort to claim that setvalue is a 
form control, so the answer should be yes, setvalue can change a 
non-relevant node.

Even better examples occur in actions like insert/delete DO NOT even have 
a ref.  They have a nodeset, and our spec makes no effort to connect 
insert/delete and the readonly MIP.  Moreover, non-relevant nodes 
certainly are not removed from a nodeset before it is consumed by 
insert/delete (that would break a lot of forms out there).  Again, none of 
these elements are targets of xforms-readonly/xforms-readwrite, nor 
xforms-enabled/disabled because these MIPs just don't apply.

The XForms submission uses ref, yet it can do instance replacement into 
readonly content, and it gets even better at doing so in XForms 1.1.

An XForms calculate can, by definition, modify a readonly node!

And perhaps the most damaging problem for XForms is that it exposes a DOM 
interface (for those who implement a DOM) that provides direct and 
unrestricted access to the underlying data.  If the intention had been to 
have the model enforce properties like readonly, then a much tighter 
interface would have been required here because one can use the DOM 
interface *provided by the XForms processor* to change nodes that are 
readonly *according to the XForms processor.*

This is just an overwhelming body of evidence to prove that it was the 
statement in Chapter 6 that was not as carefully written.  I hate to 
invoke Occam's Razor, but gosh this situation just begs for it.  The 
readonly MIP *should* make it impossible for *an end-user* to directly 
change a data node *using a form control*.  But a "programmatic" change 
coming from the controller layer or the model is so clearly allowed in 
most cases, and there should be no piecemeal exceptions made based on not 
knowing all the other ways a readonly node can be changed during XForms 
processing.

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