Re: Rebuild

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

Met vriendelijke groeten,
With kind regards,

Nick Van den Bleeken
Product Evangelist

Reach.

www.scripturaengage.com<http://www.scripturaengage.com> • www.inventivedesigners.com<http://www.inventivedesigners.com>

Connect.

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

Engage.

Facebook<https://www.facebook.com/scripturaengage/>  • Twitter<http://www.twitter.com/scriptura> •  LinkedIn<https://www.linkedin.com/company/13166?trk=tyah&trkInfo=idx%3A1-1-1%2CtarId%3A1424938899339%2Ctas%3Ainventive+designers> •  Google+<https://plus.google.com/+inventivedesigners> • YouTube<https://www.youtube.com/user/InventiveDesigners> •  SlideShare<http://www.slideshare.net/InventiveDesigners/>


Scriptura Engage is an Inventive Designers solution. The following disclaimer<https://www.inventivedesigners.com/about/legal> 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<mailto: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