Re: A few thoughts on unifying RRR

While planning the rewrite for Deferred Updates,  I hace come to the  
conclusion that I like the idea for a <update/> action:

* It is easy to explain.
* It is easier to understand.
* The system knows which bits of the update eare needed, so can optimise  
it.

Let's talk about it this afternoon.

Steven


On Wed, 08 Mar 2017 07:04:16 +0100, Erik Bruchez <erik@bruchez.org> wrote:

> All,
>
> During our last call we discussed how we could unify rebuild,  
> recalculate, and revalidate >(RRR). The thinking was that currently the  
> spec is a little too prescriptive.
>
> For example, there is no clear use case for having the ability to run  
> `recalculate` and >`revalidate` independently, yet these operations have  
> their own actions and events. I have >found that whenever you want to  
> recalculate, you almost always want a revalidate. >Similarly, when you  
> want a rebuild, you almost always want a recalculate and a revalidate.  
> >So you end up writing:
>
>    <action>
>      <rebuild/>
>      <recalculate/>
>      <revalidate/>
>    </action>
>
> If we were to pursue this further, I think we should have a single  
> "update model" action. >In fact it could be even called simply `update`:
>
>    <update/>
>
> That action would target a single model. Once it completes, the expected  
> result would be >that:
>- the dependency graph is up to date
> - calculations and MIPs are up to date
> - validations are up to date
>
> The action should be "fast". It can still use the deferred update flags  
> which XForms >specifies (rebuild, recalculate, revalidate flags). It can  
> also use other optimizations as >it sees fit.
>
> In the case of dynamic XPath dependencies, if we cannot mandate that an  
> implementation >detects every possible such dependencies, the `update`  
> action could have a `force` flag:
>
>    <update force="true"/>
>   This would force the processor to rebuild everything.
>
> The concepts of rebuild, recalculate, and revalidate still make sense.  
> It's just that they >are parts of a larger encompassing model update  
> process.
>-Erik