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

Sounds good to me. At least we got a few arguments down and while 
time-consuming that is a good thing.

I really hope to be able to make it to Madrid on Thursday and Friday. 
Let's make sure this makes it to the agenda.

-Erik wrote:
> Erik, and the rest that is following the discussion,
> Isn't it better that we postpone the discussion to the next f2f meeting in 
> Madrid there we can communicate synchronous (whith no deferred update ;) ) 
> And then it will be hopefully easier to a common resolution. What do you 
> think about that?
> Regards,
> Nick Van den Bleeken  -  Research & Development
> Inventive Designers
> Phone: +32 - 3 - 8210170
> Fax: +32 - 3 - 8210171
> Email:
> wrote on 08/30/2007 03:48:28 PM:
>>  > 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.)
>> I will point out that this is the brand new abstract John wrote for
>> 1.1. The word "controller" appears only there in 1.1, and it did not
>> appear at all in 1.0.
>> I think that I reacted to this abstract positively when feedback was
>> asked, but I now realize that the spec needs to define better what the
>> model, view and controller are, if we are to mention them at all. I am
>> not sure there was a debate in the WG about this. When you say that
>> XForms events and actions are part of the controller, to me that's
>> just a guess based on John's abstract, and again, I am not sure there
>> was any debate around this.
>> For me the controller, if there was one, was something rather external
>> to XForms constructs: it was the part of the software that implements
>> the processing model defined in XForms and that glues everything
>> together. I did not see this as concretely as to include XForms events
>> and actions.
>> In a past discussion, I argued that sequences of XForms actions
>> followed an imperative model. IIRC, Mark Birbeck argued back that this
>> was not right, and that you could see even XForms actions as being
>> quite declarative. I did not agree with that, and I may be
>> misrepresenting Mark's opinion, but this hints to me that not
>> everybody agrees that "XForms actions" = "imperative code" =
>> "controller".
>> At any rate, I think we need to precise all this, and I remain
>> unconvinced that event handlers and actions declared in the model
>> should not be considered as "part" of the model.
>>  > 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.
>> I don't think the above correctly reflects the intent of the mechanism
>> of deferred updates.
>> First, IMO the purpose of the system of deferred updates is to allow
>> to realistically implement XForms without suffering exagerated
>> performance issues. If bindings could be instantly evaluated all the
>> time at zero performance cost, I don't think we would need this
>> complex system. This just seems necessary for performance reasons so I
>> am fine with it.
>> Second, you have to look at the impact of the deferred update
>> mechanism wrt MIPs. Before the UI refreshes, we make sure that
>> recalculation and revalidation has occurred. This is crucial for the
>> consistency of the user interface, as the author has the expectation
>> that the UI will be in sync with the model. So whether we perform the
>> updates in a deferred way or not, this has little consequence for the
>> UI: the user will see a control as read-only or with an alert
>> consistently with the state of the model, every time a refresh
>> occurs.
>> When we do refreshes has consequences for UI events dispatching, but
>> that seems unavoidable as we have to pick a moment where UI events are
>> dispatched. In this sense, I would argue that the "transaction" (and
>> this probably not the best term as we don't support commits and
>> rollbacks) contains whatever occurs between two UI refreshes.
>> But enough about refresh. Look at what happens before a submission
>> occur: we make sure that MIP synchronization happens. This is because
>> the author has a natural expectation that the constraints he has set
>> are valid at the time of submission. The whole WG seemed to agree that
>> it was bad that you could actually, in certain circumstances, submit an
>> instance with out of sync relevant MIPs.
>> In my view, this is exactly what should happen for xforms:setvalue,
>> xforms:insert, and xforms:repeat if we say that they must honor the
>> MIP.
>> I know that three members have said that this was clearly a feature of
>> 1.0, but given that the initial spec authors do not seem to have
>> carefully looked at the consequences of it, I raise some doubts about
>> this statement. If the text for xforms:setvalue clearly said in 1.0
>> that it must honor the readonly MIP, I would not be able to argue
>> against this point. But at the moment, to me, this seems more like a
>> half-baked feature rather than a well thought-out one.
>> I guess that the debate continues ;-)
>> -Erik
>> -- 
>> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
> --------------------------------------------------
> Inventive Designers' Email Disclaimer:

Orbeon Forms - Web Forms for the Enterprise Done the Right Way

Received on Thursday, 30 August 2007 16:51:31 UTC