User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:188.8.131.52) Gecko/20060619 Firefox/184.108.40.206
Build Identifier: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:220.127.116.11) Gecko/20060619 Firefox/18.104.22.168
In the example file, both an input and a select1 are bound to the same (integer) variable. Even though the select1 only contains numbers, selecting any of them moves the state to invalid (as can be seen by red colour due to some CSS). However, entering the same numbers into the input field works ok (and obviously, entering letters there leads to invalid state).
Happens with all recent xforms extensions.
I was smart enough to test this on Minefield too, same result.
Can you attach testcase?
sor(In reply to comment #1)
> Can you attach testcase?
Sorry, I see.
XForms specs says (http://www.w3.org/TR/xforms/slice8.html#ui-selectOne):
Note that the datatype bound to this form control may include a non-enumerated value space, e.g., xsd:string, or a union of a enumeration and a non-enumerated datatype (called an open enumeration).
But in my case, it doesn't have an "open enumeration" (on purpose).
On a related note (separate bug report?) select1 in xforms even allows selection="open" with "closed enumerations" as my one.
The issue here is that we are counting the carriage returns and whitespaces as part of the values. According to the Schema spec, we shouldn't do that for numerical and string types. cr and lf should be changed to spaces and then the leading and trailing spaces should be dropped. So we shouldn't be marking the controls invalid. HOWEVER, it isn't clear that xforms should modify the values so that they DON'T have the cr's and lf's so your select1 could still show as out-of-range if you just put '10' in the input.
If you want to work around this in your form, you should change:
Created attachment 229275 [details]
should selecting an item from this select1 cause everything to be invalid or not?
(In reply to comment #6)
> Created an attachment (id=229275) 
> testcase 2
> should selecting an item from this select1 cause everything to be invalid or
I guess everything should have one and the same behaviour like select1 since instance node contains invalid data in accordance with type.