Re: Big update to XForms 1.1 spec; Ready for your review

Mark Seaborne wrote:
 >> You may have to try yet another time convincing me ;-)
 >>
 >
 > Oh alright then, as its you :-)

Thanks ;-)

 >> But the readonly MIP is not honored by @calculate! This tells me that
 >> the readonly MIP does not ensure a value doesn't change. And if I can
 >> change it with @calculate, I don't see why I can't change it with
 >> xforms:setvalue.
 >
 > read-only and calculate are both MIPs, and the model reflects the
 > cumulative effect of MIPs to any consuming form. So, from the form
 > author's view point, they know that particular nodes are read-only,
 > whether or not calculate and read-only are used together or alone.
 >
 > From the model author's perspective, the behaviour is defined, so they
 > know what they get if calculate and read-only are combined.

That is a possible rationalization. In this case @calculate and
@readonly are coupled. But the fact remains that @calculate modifies
instance data that is read-only, having the MIP property set to
true. So we cannot simply say "a read-only value never changes", which
was what I was hearing earlier. It does when you use @calculate. If
this is an exception, it opens the door to more.

 >> And consider that xforms:setvalue is not a view only thing, it is very
 >> often used in the model, for example I have a use case in front of me
 >> where I perform certain initializations this way upon xforms-ready.
 >
 > Yes, me too. But I think of setvalue as not really belonging to the
 > model, more to the controller. I don't think the model is just
 > whatever sits inside the model element, rather it is the combination
 > of schema and MIPs. After all, the model can also contain message -
 > which is view.
 >
 > Placing these constructs within the model element is really just a
 > convenience to allow the form author to take advantage of particular
 > events, as you imply.

I reckon that xforms:message and xforms:prompt look funny in the
model. But that could be just seen as a weakness of the spec.

For the rest, it just seems that you have a very restrictive
definition of the XForms model. Nothing wrong with that, although I
don't know if there is much in the spec supporting this point of view,
and I don't particularly agree with it. For me, the XForms model IS
whatever is between <xforms:model> and </xforms:model>. Behavior is a
very important part of models for us, and that includes events,
actions, and submissions.

For me, again, XForms model and controls are part of a same
specification, XForms, whose goal is to help authors build forms /
applications. It is nice if model and controls are separate, but I am
not sure we need to over-emphasize the separation of the two.

Finally, regarding the problem at hand, and regardless of
philosophical perspectives on MVC in XForms, I still see an issue with
xforms:setvalue honoring readonly, namely the requirement for
xforms:setvalue to honor the rebuild and recalculate flags. Nick
proposed, IIRC, that this was not necessary because of a
transactionality of actions, but at this point I don't buy it: if you
say that xforms:setvalue honors readonly, it better do so, in the same
way that if we now say that submission must recalculate (if needed)
and revalidate before going on with its business, as the author is
very likely to have an expectation that the constraint will be honored
in all cases.

Basically, with this, we make the otherwise very simple xforms:setvalue
action more complex. We also add requirements to xforms:insert,
xforms:delete, and instance replacement. So this apparently simple
feature has quite a few consequences for the spec.

And then there is also the fact that this leaves us without a good way
of having a set of read-only controls whose values can be changed by
actions in the model.

-Erik

-- 
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/

Received on Wednesday, 29 August 2007 17:30:17 UTC