Re: select1 and whitespace handling

Philipp,

We discussed the issue you raised today. Erik Bruchez was absent so we 
had no report from the Orbeon point of view, and a number of other 
members were also absent.

However, in reading the specification, we found no justification for 
whitespace stripping in select1 matching.

There are three whitespace issues you may want to be aware of:

1. attribute value normalization
instance data nodes which are attribute values are whitespace normalized 
by XML.
There may be corner cases in your implementation surrounding this 
attribute values.
If you have implementation concerns or reports in this area, please let 
us knwow.
See http://www.w3.org/TR/REC-xml/#AVNormalize

2. xsd data type normalization
XML Schema data types provide for whitespace normalization before 
validation of types.
So, <value> 123 </value> is valid according to xsd:integer and its 
derivatives.
This does not imply that the text node should be changed by validation, 
only that it is valid as is.
See http://www.w3.org/TR/xmlschema-2/#rf-whiteSpace
which says

    For all atomic datatypes other than string (and types derivedby
    restrictionfrom it) the value of "whiteSpace" is|collapse| and
    cannot be changed by a schema author


See http://www.w3.org/TR/xmlschema-1/#d0e1654 for the definition of 
|collapse, |but the implication is described above.

3. select1/item/value=""
We've separately noted a possible interoperability and conformance issue 
with forms which explicitly provide a select1 item whose value is 
empty.  The XForms 1.1 Recommendation prohibits matching this value, but 
implementations appear to vary in the degree to which this requirement 
is enforced, and at least some implementors report varying from the 
Recommendation in this area on purpose.  We'd appreciate it if you would 
respond to the implementors' poll at 
http://lists.w3.org/Archives/Public/www-forms/2010Dec/0003.html

Leigh.