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.
>
>