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

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: Nick_Van_den_Bleeken@inventivegroup.com

public-forms-request@w3.org 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
> http://www.orbeon.com/
> 
> 



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

Inventive Designers' Email Disclaimer:

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

Received on Thursday, 30 August 2007 15:28:45 UTC