Re: select1 and whitespace handling

Hi Kurt,

Would you agree that this is on the thread of "Implementers please read: 
poll about select1 and empty values", as opposed to the thread of "select1 
and whitespace handling"?

I think there is  no way to fully implement the first of your suggestions. 
 If you pick an item with an empty value, what would happen to the value 
of the select1's bound node? It either changes to empty string or it is 
left in the prior state.  You're suggesting the latter, I think, but then 
an implementation would not really ever know how to properly respond to a 
select1 control bound to a non-empty value.  It would have to use internal 
state data that would pose retention problems when inside of switches or 
repeats or across save/reload operations.

The prompt idea works, but it is probably more useful to allow selection 
of an item with an empty value as this would allow a form author to create 
forms in which the user can elect to go back to the "I don't want to make 
a choice"  state.  I will have a separate email about this on the other 
thread shortly.

Cheers,
John M. Boyer, Ph.D.
Distinguished Engineer, IBM Forms and Smarter Web Applications
IBM Canada Software Lab, Victoria
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer

Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw






From:
Kurt Cagle <kurt.cagle@gmail.com>
To:
"Leigh L. Klotz, Jr." <Leigh.Klotz@xerox.com>
Cc:
www-forms@w3.org
Date:
12/08/2010 08:35 PM
Subject:
Re: select1 and whitespace handling



A couple of possibilities occurred to me while thinking on the select1 
issue today with regards to the suitability of an empty string as an 
argument for an inline xf:value. One possibility would be to disallow the 
use of a empty value as a “selectable“ item in a <xf:select1>  statement, 
but to still display the label of the given item. This would be useful for 
introducing category labels for specific subsequent items while keeping 
these from being selected directly.
An additional option would be to define a <xf:prompt> element that would 
be a child of the <xf:select1> element. When the value of the bound @ref 
is empty, missing, or doesn‘t otherwise match the given values, then the 
prompt content would be displayed, but any displayed prompt content would 
always be unselectable. Similarly, so long as the select1 is displaying 
the prompt content, the control will be considered invalid if it's bound 
as required. 
<xf:prompt> would occur as a single child of <xf:select1>:

<xf:select1 ref="color">
     <xf:label>Colors:</xf:label>
     <xf:prompt>Select a color:</xf:prompt>
     <xf:itemset nodeset="instance('myList')/colors/color">
            <xf:label ref="colorLabel"/>
            <xf:value ref="colorValue"/>
     </xf:itemset>
</xs:select1>

There would only be one prompt in a select or select1 statement, and the 
position of that prompt in the list would always be an implementation 
specific (i.e., even if the prompt was at the bottom of the select1 
statement, if the implementation defined it as being the first item 
displayed, then it would be first item displayed).

The two methods can also be used together. This would apply to <xf:select> 
and <xf:select> elements. For instance, the following would let users 
choose from one of three possible sets:

<xf:select1 ref="menuItem">
     <xf:label>File menu:</xf:label>
     <xf:prompt>Select an item:</xf:prompt>
     <xf:item>
           <xf:label>Colors</xf:label>
     </xf:item>
     <xf:item>
           <xf:label>Red</xf:label>
           <xf:value>red</xf:value>
     </xf:item>
     <xf:item>
           <xf:label>Green</xf:label>
           <xf:value>green</xf:value>
     </xf:item>
     <xf:item>
           <xf:label>Blue</xf:label>
           <xf:value>blue</xf:value>
     </xf:item>
     <xf:item>
           <xf:label>Letters</xf:label>
           <xf:value/>
     </xf:item>
     <xf:item>
           <xf:label>Alpha</xf:label>
           <xf:value>a</xf:value>
     </xf:item>
     <xf:item>
           <xf:label>Beta</xf:label>
           <xf:value>b</xf:value>
     </xf:item>
     <xf:item>
           <xf:label>Gamma</xf:label>
           <xf:value>c</xf:value>
     </xf:item>
</xs:select1>

This would render as:

File Menu:
[Select an Item]      1
[Colors           ]      2
[Red               ]      3
[Green            ]      4
[Blue              ]      5
[Letters          ]      6
[Alpha            ]      7
[Beta              ]      8
[Gamma         ]      9
Line 1 is the prompt, and will be displayed if the ref has not yet been 
assigned a value. Lines #2 and #6 are internal categories that don't have 
explicit values (of have values set to the empty string). They cannot be 
selected directly. Lines #3,#4,#5, #7, #8, and #9 are selectable entries.
The most obvious use of this would be as a drop-down menu, but it has a 
fairly wide number of potential use cases.
<xf:prompt> would take the same attributes and child nodes that <xf:label> 
would for the <xf:select1> statement, though it is implementation specific 
as to whether subordinate element content would render as presentation 
content (such as HTML) or as a string.
Kurt Cagle
XML Architect
Lockheed / US National Archives ERA Project



On Wed, Dec 8, 2010 at 1:23 PM, Leigh L. Klotz, Jr. <Leigh.Klotz@xerox.com
> wrote:
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 derived by 
restriction from 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.