Re: How to respond to 'xforms-out-of-range'

Hi Ronald,

Please see inline.

Thanks,
John Boyer



From:
"Ronald van Kuijk" <rvkuijk@intercommit.nl>
To:
John Boyer/CanWest/IBM@IBMCA, www-forms@w3.org
Date:
09/08/2010 10:22 AM
Subject:
Re: How to respond to 'xforms-out-of-range'



Hi John, 

Thanks for replying and thanks to the WG for putting it on the list for 
todays meeting. It was not that obvious was it?

JB> I thought it was; why do you say it wasn't?

> 
> The empty string is not out of range for select and select1 controls 
(see 
> esp. the notes in Section 8.1.1 for select1 controls).
>

I missed this, thanks for pointing it out, but the empty string was just 
an example. It could  as well be a non-empty one that is in the instance 
from somewhere else.

JB> Yes but if the value is non-empty and doesn't match one of the items, 
then it's out of range.  The language of the note specifically says that, 
so when you say that empty string is just an example, I'm trying to figure 
out what other example you want me to consider that actually is *not* 
covered by the spec.
 
> Yes, we agree that a select or select1 can be in range but invalid.  The 

> in range/out of range eventing is about the UI control's ability to 
> properly show the bound data value, notwithstanding whether the model 
> regards it as valid or invalid.
>

In range but invalid is not the real problem. A kind of html like select 
will show the corresponding label then. The other way around is harder. 
'Properly showing the bound data value' is to me (a non-native English 
speaker) also 'explicit'. Does it mean the control should (must?) in some 
way or another show the value that cannot be shown in the select itself? 
E.g. a dymamic, non specified (xforms) alert that is probably not 
customizable by the form developer? Or e.g. Dynamically adding it to the 
nodeset/items for the select and doing some magic things, or....? It feels 
like this is against the phylosophy of XForms of declaritively defining 
behaviour.

JB> Generally, if it's not in the spec, then there is no expected 
interoperability with respect to how it is handled.  For example, one 
tends to create run-time/UI objects that are associated with each of the 
item elements (or each item generated by an itemset); I definitely would 
not expect more run-time/UI objects to be created to represent spurious 
data values that don't match any of the items in the select/select1. 
Nothing in the spec suggests that this should happen, so why should this 
happen?

JB> In the case of a select1 or select, is that the run-time/UI object(s) 
associated with item(s) whose value(s) is(are) matched to the bound data 
node value are regarded as selected, and the remainder of the item(s) are 
regarded as unselected.  So, your select or select1 may show zero selected 
items because the string is empty or because the string is non-empty but 
none of the items match the non-empty data node content.  The 
xforms-out-of-range event is issued in the latter case so that it can be 
distinguished from the former.

JB> Finally, note that in XHTML+XForms, there is the possibility that the 
CSS pseudo-classes mentioned in Appendix G.1 will be available, where the 
:out-of-range and :in-range pseudo-classes are the ones pertinent to this 
discussion.  But obviously the availability of that mechanism is up to the 
implementation that integrates XForms with a host language such as 
(X)HTML.

Cheers,

Ronald