RE: xforms:choose within xforms:repeat

Yeah, I rather remember this issue being around for a very
long time.  It seems odd to me that switch in repeat would be
singled out as not working when there is the long standing
belief that setfocus should work when it refers to an 
element in a repeat.

Anyway, I think the ideas we now share are very similar and
would therefore behave much the same.  As far as I can tell,
the only difference is that I propose to uniformly dereference
a repeated element using the indices of its ancestor repeats
whereas you propose that the dereference should behave that way
unless the element containing the ID and the one containing the
IDREF have a common ancestor repeat.

All I've heard in the past is about what happens when the id-based
action and the identified element are in the same repeat row.
But the generalization of that appears to be that for
all repeat ancestors in common, the common repeat row is used and
repeat indices are used for ancestor repeats of the identified
element that are not ancestors of the id-based action.

The use case for this appears to be something along the lines of:
1) An instance data node is changed.
2) The node is referenced in a calculate by a set of nodes that are bound to a UI element in each row of a repeat.
3) The UI elements have xforms-value-changed action handlers
4) The xforms-valued-changed handlers contain id-based actions.

It's a little odd when the action is setfocus, but not unpalatable because it is an edge case.
Other actions like toggle and setindex make more sense as does use of index().

Still, the whole thing looks like a bit of an edge case, leaving a certain
want for a behavior that might reasonably be gleaned from the XForms spec,
which is that an IDREF should be dereferenced based only on properties of the identified 
element, specifically what is its id and what are the indices of its ancestor repeats.

It would be good to see a strong use case for the more complicated analysis of
common ancestors.  I'm especially concerned about what will eventually happen 
when event handlers can target shadow tree nodes.  Do we then unravel the IDREFs
based on location of the event target rather than where the id-based action is 
located?  If we don't, then we wouldn't have behavioral consistency among event
handlers, but if we do the result is patently bizarre and, I would think, relatively
hard to implement.

Best regards,
John Boyer 

-----Original Message-----
From: Mark Birbeck [mailto:mark.birbeck@x-port.net]
Sent: Wednesday, August 17, 2005 3:20 AM
To: John Boyer
Cc: w3c-forms@w3.org; www-forms@w3.org
Subject: RE: xforms:choose within xforms:repeat


Hi John,

> This is very similar in behavior to what I described and is 
> based on some earlier discussions of the working group, which 
> Mark's team implemented.

Well...we actually implemented it years ago, and I then presented the
results of our experience to the WG. And the main reason we went for the
particular solution we did is because it harmonises with the way @id works
in 'shadow trees' in XBL. (Although there isn't a great deal of cross-over
at the moment between XForms and XBL, I feel it is important to make sure
that we don't add things that would make them incompatible.)

Regards,

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 Wednesday, 17 August 2005 13:51:01 UTC