W3C home > Mailing lists > Public > www-forms@w3.org > October 2006

Re: Controlling relevance in XForms 1.0 without changing context node and without using @context

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Mon, 9 Oct 2006 00:35:30 +0100
Message-ID: <640dd5060610081635r15d4b43es4c9d1b562c4120d6@mail.gmail.com>
To: www-forms <www-forms@w3.org>

Hi Adrian,

:) You are right that the spec isn't completely clear, but as it
happens, the picture is not too difficult.

I think the best way to look at it is that in general, you can use
*any* expression in a UI binding, and you don't really need to worry
about it.

So, at it's simplest you can do this:

  <xf:input ref="a">

  <xf:input ref="b">

  <xf:output value="a + b">

And 'a + b' will be recalculated for you whenever there is a refresh.
Note that unfortunately, this has nothing to do with the dependency
graph, since all that happens in the refresh phase is that all
controls must update themselves. I know that many processors have
actually created a second dependency graph so as to be able to
optimise this processing, but it's a shame the spec is silent on this.

Anyway, that's not what we're discussing here, but the key point is
that when a refresh happens your calculation is updated.

Now, what if we have instance data like this:

  <data item="1" xmlns="">
    <a />
    <a />

and controls like this:

  <xf:input ref="@item">
    <xf:label>Choose an item to edit:</xf:label>

  <xf:input ref="a[/data/@item]">

This is a dynamic dependency, since if @item is 1, we are binding our
input to the first 'a' node, and if @item is 2 we are binding our
input to the second 'a' node. Now since 'binding' implies a
relationship between the node in the model and the control, such that
events are passed, styling is set, and so on, then we have to do a lot
of work if the node for the second input changes, and in the XForms
spec this is called 'rewiring', and it happens during the refresh

Note that all of this is happening independently of the dependency
engine, so we don't need to worry about dynamic dependencies. But when
we use the calcuation engine in bind statements, things are very

Let's say that we want the 'a' being edited to be invalid if it is less than 10:

  <xf:bind nodeset="a[/data/@item]" constraint=". &lt; 10" />

Now we have to change the node that this expression is bound to--i.e.,
the node referred to in the dependency graph--every time the value in
@item changes. However, in the world of the dependency engine this
cannot happen until there is a rebuild--there is no notion of
'rewiring' automatically. The dependency graph of all the expressions
contains references to nodes, as a kind of 'snapshot', and when the
value of any node changes, the graph is used by the engine to work out
what calculations need to be re-run, and those that can be ignored. So
a bind statement like this is easy for the engine:

  <xf:bind nodeset="a" calculate="/data/@item" />

If @item changes then the expression is re-evaluated, and 'a' is
updated. But that is not the case for our previous example--if @item
changes in the previous example you are referring to a completely
different node, and the entire dependency graph needs to be

So that's what the spec means when it says that the author needs to
take care of this themselves! The author would have to trigger a
rebuild after any modification to @item, if they wanted to ensure that
the node represented by the statement:




On 08/10/06, Adrian Baker <adrian@fastmail.net> wrote:
> Hi Mark,
> I guess I took Leigh's '/your/condition/here' path as just a placeholder
> for any expression! So sure, that path would be fine. Just to be clear
> then, if I had:
>     <xf:group ref=".[invoice/currency='euro']">...</xf:group>
> Then this would be an example of a dynamic dependency, correct?
> Regarding your second point: now that I re-read the spec I see this.
> Perhaps 7.5.1 could be made clearer, because it gave me the impression
> that dynamic dependencies were 'unacceptable' in *all* binding
> expressions. In particular, this sentence seems quite general:
>     "Not every possible XPath expression is acceptable as a binding
> expression."
> Perhaps 'binding expression' could be qualified with 'model binding
> expression'. Or, since 7.5.2 already states this, perhaps this can be
> removed altogether.
> A related question: here (7.5.1) the spec states that not every possible
> XPath is acceptable (ie not paths which create dynamic dependencies),
> whereas just below (7.5.2) it states that dynamic dependencies will
> require manual rebuilding - which implies that they *are* acceptable.
> Which is it - are they prohibited? Or permitted, as long as the form
> author is aware they may have to manually trigger a rebuild? In which
> case the statement that 'not every XPath expression is acceptable' seems
> inconsistent.
> Adrian
> Mark Birbeck wrote:
> > Hi Adrian,
> >
> > It's not a dynamic dependency, since for any given snapshot of the
> > instance data, the result of this expression won't change until nodes
> > are added or deleted, and then there will be a rebuild.
> >
> > Having said that, in this example it doesn't matter, since XForms
> > allows dynamic dependencies in UI expressions. A recalculation of the
> > nodes referenced is performed in the refresh phase, and then a
> > 'rewiring' takes place automatically between the model and the UI.
> >
> > Regards,
> >
> > Mark
> >
> > On 06/10/06, Adrian Baker <adrian@fastmail.net> wrote:
> >
> >>  Isn't this a case of
> >> http://www.w3.org/TR/xforms/slice7.html#expr-dynamic-dependency
> >> ?
> >>
> >>  Leigh Klotz wrote:
> >>  <xf:group ref=".[/your/condition/here]">...</xf:group>
> >>
> >>
> >>
> >>
> >
> >
> >

Mark Birbeck
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
Received on Sunday, 8 October 2006 23:35:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:18 UTC