select1 and whitespace handling

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

select1 and whitespace handling

Philipp Wagner-4
Hi,

when trying to fix a bug in Mozilla XForms I came across the following
problem:

How should whitespace before and after a non-whitespace characters be
handled when matching a xf:select1/xf:value to the bound node? Please
have a look at the following testcase, which shows what I mean better
than many words:

https://bug533174.bugzilla.mozilla.org/attachment.cgi?id=495947

I also have some screenshots how Chiba and Orbeon handle this:

Orbeon: https://bug533174.bugzilla.mozilla.org/attachment.cgi?id=495949
Chiba: https://bug533174.bugzilla.mozilla.org/attachment.cgi?id=495948

Seems like there's no consensus on this :)

What's "the right thing" to do?
a) Strip all whitespace before and after non-whitespace characters from
xf:value and the bound node when doing the comparison? OR
b) Compare the two string literally, including whitespace?

I think option a) would be more intuitive for web developers.

What's the proposed implementation?

Philipp


Reply | Threaded
Open this post in threaded view
|

Re: select1 and whitespace handling

Klotz, Leigh
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.

Reply | Threaded
Open this post in threaded view
|

Re: select1 and whitespace handling

Kurt Cagle-2
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. <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|

Re: select1 and whitespace handling

John Boyer

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: [hidden email]  

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 <[hidden email]>
To: "Leigh L. Klotz, Jr." <[hidden email]>
Cc: [hidden email]
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@...> 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.