XiX: Details about XForms in XQuery


I was asked offline for more details about what I have in mind around XiX.

Take a simple piece of XML, like this: <root><a>3</a><b>4</b><total/></root>.

An XForms Model can be applied, in an out-of-line fashion, to that instance. This is done through a bind element, with XPath to identify the nodes in question, plus other “model item properties” to annotate the instance. The calculate property is a good one: <bind nodeset="total" calculate="../a + ../b"/>. When called upon to refresh the instance, as you would expect, the result contains the node <total>7</total>.

Like lots of algorithms, though, XForms is defined in a thoroughly procedural manner. Functional programming has a stricture against assignment operators, like setting the value “7” into the calculated node above. So the challenge is coming up with an implementation that works within these bounds. For example, perhaps a function that takes an original instance as input, and returns a newly-created updated instance. Simple enough for the example here, but in more complex cases with different and interacting model item properties, regenerating the entire instance frequently has performance penalties.

So, I’m trying to find the right expression of the XForms Model in a functional guise. (As with RDFa). I’m curious about what anyone else has come up with in this area. -m

Related Posts

2 Replies to “XiX: Details about XForms in XQuery”

  1. Calculated properties aren’t usually stored — and this is so not only in functional languages.

    So, it would be best to store in an id of the function that should be used to calculate the value. The function itself can use memoisation (a Saxon example is the “saxon:memo-function” attribute), so that there will be no penalty in evaluating it multiple times.

    Even if the instance is refreshed on and on, this can still be achieved with no memory issues, for example implementing it as tail-recursive processing, where the new instance is passed as a parameter in the tail-recursive call. FP language processors usually detect and optimize tail-recursion, by freeing all resources (temporary variables) that are not passed as part of the recursion, at the point of recursion. In this particular case, the older instance will be naturally freed.


Comments are closed.

© All Right Reserved
Proudly powered by WordPress | Theme: Shree Clean by Canyon Themes.