Re: Deferred updates

>
> I think as a form author it is point 2 that causes some pain.
>
> It means that a form author - even though they are using a declarative
> language - has to understand some possible concurrency issues,
>

Not sure about those: do you have an example?


> and insert <recalculate/> to flush the values. This is a subtlety that I
> think most form authors - particularly those from a development background
> - would not expect (as a sample of one I was caught out by it). The upshot
> is the deferred update requires potential XForm authors to have a very
> detailed / low level understanding of the specification.
>

I am not sure what programmer expectations are the most likely: should
changes propagate immediately or not between individual actions in a
sequence of actions? Hard to tell what programmers would think and that
might depend on the particular background of said programmer. I for one am
used to the fact that actions do not trigger immediately any sort of
dependencies updates but that's because I have done too much XForms ;)

I also think you can see XForms actions are more or less imperative. Right
now, as per the spec, they are strictly imperative, and could as well be
written via for example a JavaScript API. You could imagine actions
themselves being seen as more declarative, ensuring that the parts of the
data model they need are always up to date.

I would personally prefer, all other things being equal, if updates would
by default take place before each action needing its result. That would be
a change in the spec though. Also, I can imagine performance issues when a
large number of data model updates are done in a single pass: possibly in
such cases it might be better if there are some notion of transaction.

Which reminds me of XQuery Update [1], which is based on an immutable view
(snapshot) of the data during a sequence of updates. Then updates are
applied at once. I am not sure where that takes us.

-Erik

[1] https://www.w3.org/TR/xquery-update-10/