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

Erik wrote on 08/29/2007 07:30:17 PM:

> 
> Mark Seaborne wrote:
>  >> You may have to try yet another time convincing me ;-)
>  >>
>  >
>  > Oh alright then, as its you :-)
> 
> Thanks ;-)
I hope you still appreciate my comments on the read-only issue ;)

> 
>  >> 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.

Quote from our abstract defining what our XForms model realy is : a 
declarative model composed of formulae for data calculations and 
constraints, data type and other property declarations, and data 
submission parameters [1]

It also clearly defines what the XForms view and controller are : 
 - a __view__ layer composed of intent-based user interface controls 
 - an imperative __controller__ for orchestrating data manipulations, 
interactions between the model and view layers, and data submissions. 

As I read this, this clearly states that event handlers/actions are part 
of the controller not the model. (It may even support that the message 
action is part of the view.)


> 
> 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.

Section 10 XForms Actions[2] defines the concepts 'outermost action 
handler', inner action handler' and 'Deferred Updates'. If we no longer 
believe in the defered effect of XForms action on the XForms model 
(transactional effect), we should carefully investigate what the side 
effects are and write text that deals with all the picky details. But this 
discussion should be held in the context of a feature version(I'm not sure 
if we want to change this behavior, since it was already well defined in 
XForms 1.0 first edition), not a change in a spec that is in post-last 
call state.

> 
> 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.

It probably depends on your implementation, but a simple check to see if 
the node you want to manipulate is read-only is nothing compared to the 
changes we made to insert and delete in my opinion.

> 
> 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.
>

As a said before, if we think we need the 'only read-only in the view' 
feature we should add it. I'm definitely in favor of adding this. But I'm 
definitely not happy to sacrifice the read-only MIP for this.
 
> -Erik
> 
> -- 
> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
> http://www.orbeon.com/
> 
> 
[1] 
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#abstract
[2] http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action



--------------------------------------------------

Inventive Designers' Email Disclaimer:

http://www.inventivedesigners.com/email-disclaimer

Received on Thursday, 30 August 2007 07:20:46 UTC