Re: Nested <bind>s

Hi Erik,

> I was not aware there was a real debate. The only possible issue I think
> was related to what an implementation should do when the parent bind
> returns a nodeset with more than one element, and I think (but somebody
> please correct me if I am wrong) that this translates, like in the case
> of xforms:repeat and xforms:itemset, into applying the children bind
> elements for each node of the outer bind. At least, that's how this is
> implemented in Orbeon PresentationServer, and it seems to make perfect
> sense.

I'm afraid I haven't got time to go find the links to the
debates...apologies for that! But I can tell you that there were
actually two issues. The first was what should an ID value in a nested
bind mean, and the second was whether nested binds iterate across the
nodesets, or are simply concatenations of the strings.

On the first issue--the use of ID values--you can easily see the problem here:

  <xf:bind id="nsA" nodeset="a">
    <xf:bind id="nsB" nodeset="b" />
  </xf:bind>

Using "nsA" is easy:

  <xf:repeat bind="nsA">
    ...
  </xf:repeat>

but the tricky issue comes when using "nsB". If we say that the
nodeset for "nsB" is created by iterating the nodes in the containing
nodeset, then you would in effect end up with many nodesets called
"nsB". At one level this obviously can't be allowed, but many people
would like to find some way to have the convenience of doing things
like this:

  <xf:repeat bind="nsA">
    <xf:repeat bind="nsB">
      ...
    </xf:repeat>
  </xf:repeat>

So, rather than close this off, we agreed (somewhere!) that all we
would say is that for now, the nested ID when iterating across a
nodeset is undefined, and is best avoided.

Note that just because the use of ID across a nested nodeset is
undefined, doesn't mean that the whole 'nested bind' thing comes
crashing down; to answer the original question on why you would use
this, the following is perfectly acceptable:

  <xf:bind id="ns-address" nodeset="address">
    <xf:bind id="ns-city" nodeset="city" />
  </xf:bind>

if you know for certain that there is only one "address" node in your
data. In fact, we use this a lot, since constructs like this provide
use with both a convenient shorthand, and a way of 'data hiding'.

Nested binds without IDs are also perfectly safe, because they too are
unambiguous:

  <xf:bind id="ns-address" nodeset="address">
    <xf:bind nodeset="street" readonly="true()" />
  </xf:bind>

And again, to answer the original question, without the ability to do
this kind of thing your bind statements would get incredibly long and
unmanageable, since you would have to keep spelling everything out in
detail:

  <xf:bind id="ns-address" nodeset="address" />
  <xf:bind nodeset="address/street" readonly="true()" />

This example brings us to the second issue that is in the archives
somewhere, which concerned whether bind statements involve nodesets
that iterate, or are simply a concatenatation of all nested
statements. As you can see from the example just given, in many
situations it doesn't make a lot of difference whether you process the
nested statement by simply adding all the strings together. Some
processors have actually taken this approach, and for them nested IDs
are no problem, since in effect they have this:

  <xf:bind id="nsA" nodeset="a" />
  <xf:bind id="nsB" nodeset="a/b" />

Unfortunately, there are some things that you just can't express using
this simple concatenation technique, and some things that would be
processed wrongly, so we resolved the discussion in favour of the
iteration approach.

And as you say rightly say Erik, that approach plays nicer to the way
that xf:itemset and xf:repeat iterate, and for my money feels the most
intuitive.

All the best,

Mark

-- 
Mark Birbeck
CEO
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
http://www.formsPlayer.com/

Received on Monday, 24 July 2006 21:04:00 UTC