Re: Rebuild

On Wed, 15 Feb 2017 08:43:39 +0100, Nick Van den Bleeken  
<Nick.Van.den.Bleeken@inventivegroup.com> wrote:

>
> Erik, Steven,
>
>
> It might indeed be time to ‘improve’ the dependency algorithm.  
> Nevertheless, we should be careful that loosening the requirements of  
> RRR doesn’t further makes it more difficult for form authors >to create  
> forms that work across implementation. The wording in the spec is  
> carefully tweaked by John to ensure interoperability. Loosening the  
> requirements must be done with great care, >otherwise we might for  
> example make the order of specifying the binds have an impact of the  
> result, form authors relying on the events be dispatched might need to  
> change their forms, …
>
> (as a side note, I’m not sure how interoperable those ‘edge’ cases are  
> today).

I like this bit of the specification:

* At the start of a recalculate, there is a, possibly empty, list L of  
instance nodes whose values may have been changed, e.g., by user input or  
by a setvalue action.
* All nodes in L, if any, and nodes that are computationally dependent on  
nodes in L must be recalculated.
* Only a single recalculation of each compute that is computationally  
dependent on elements in L may be performed.
* A compute must be recalculated before any computes that are  
computationally dependent on the instance node associated with it.
* If a compute is computationally dependent on an element in L and part of  
a circular dependency, then an xforms-compute-error event must be  
dispatched to the model element.

and if we could express the whole RRR sequence in these sort of terms, I  
think we would cover it.

By the way, the order of events being fired is already undefined.

Steven

>
>
> Met vriendelijke groeten,
> With kind regards,
>
> Nick Van den Bleeken
> Product Evangelist
>> Reach. 
>> www.scripturaengage.com • www.inventivedesigners.com

>> Connect.  
>> +32 3 425 41 02 • (M) +32 499 51 85 02

>> Engage. 
>> Facebook  • Twitter •  LinkedIn •  Google+ • YouTube •  SlideShare

>
>
> Scriptura Engage is an Inventive Designers solution. The following  
> disclaimer applies to this message.
>
>
>
> From: <ebruchez@gmail.com> on behalf of Erik Bruchez  
> <ebruchez@orbeon.com>
> Date: Wednesday, 15 February 2017 at 05:46
> To: Steven Pemberton <steven.pemberton@cwi.nl>
> Cc: XForms <public-xformsusers@w3.org>
> Subject: Re: Rebuild
> Resent-From: <public-xformsusers@w3.org>
> Resent-Date: Wednesday, 15 February 2017 at 05:47
>
>
> This is particularly on topic for me as I recently re-read the  
> pre-XForms 1.0 paper [1] by John Boyer and Mikko Honkala on the  
> dependency algorithm. Handling (at least some) structural >changes is  
> mentioned in the conclusion as possible further work.
>
>
> First, if an implementation updates the binds based on dependencies  
> smartly but "as if" a full rebuild takes place, then it would be fine.  
> We wouldn't have to say explicitly when or even if a >"rebuild" would  
> have to happen. I would be in favor of saying something like that as a  
> first step, although you could read the spec that way already ("as if"  
> is always fine).
>
>
> Second, a concern is that the range of XPath expressions is large and  
> dependencies can be complex. So I am not sure at this point that you  
> could just say "there are dependencies and they update >magically in all  
> cases and a full rebuild is never needed". We would have to show an  
> existence proof of an algorithm which could support all of XPath 2.0  
> (and newer ideally) first.
>
>
> More specifically, on the question of "just doing a recalculate", this  
> is not possible if a recalculate doesn't include the possibility of  
> updating at least a subset of the dependency graph. However a >combined  
> rebuild/recalculate operation which updates binds or a subset thereof  
> would be able to do so in some cases at least.
>
>
> In our implementation, by the way, we have merged the  
> recalculate/revalidate operations in a single operation without side  
> effects. It just didn't seem useful to split them in two and allow one  
> to >run without the other, and splitting them causes more difficulties  
> for optimization. Maybe this points to a more general "model update"  
> operation.
>
>
> In general, I think that:
>
>
> - we don't have to be as specific as we are about the  
> rebuild/recalculate/revalidate scheme
>
> - but if we are not, we still have to say *something*: what is expected  
> from the process in a minimal implementation
>
> - because we haven't described a perfect model update algorithm (if one  
> exists), implementations could have some latitude in the range of XPath  
> expressions they are able to handle transparently
>
>
> -Erik
>
>
> On Tue, Feb 14, 2017 at 12:06 PM, Steven Pemberton  
> <steven.pemberton@cwi.nl> wrote:
>>
>> The spec is very normative about rebuilds.
>>
>> But in the late 80's I built a system where even structural dependencies
>> were kept, so that an insert or delete caused a recalculate, and there  
>> was no such
>> concept as a rebuild.
>> (details: http://oai.cwi.nl/oai/asset/5342/05342D.pdf)
>>
>> So, how normative is our rebuild? If inserts caused a recalculate  
>> instead of a rebuild, we would surely be OK with that?
>>
>> If so, then we need to be less formal about the need for rebuilds.
>
>
> -Erik
>
>
> [1]  
> https://pdfs.semanticscholar.org/82cb/d193c1ca60c2bb91013fd74dffefca3783b4.pdf