Closed Bug 352884 Opened 18 years ago Closed 18 years ago

XPath expression should use type information to do necessary conversions

Categories

(Core Graveyard :: XForms, defect)

Product:
Core Graveyard
Component:
XForms
Version:
1.8 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: dan, Unassigned)

Details

Attachments

(2 files)

testcase
1.15 KB, application/xhtml+xml
Details
testcase booltostr
818 bytes, application/xhtml+xml
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7

XForms will not do relevant binds to boolean data types.

This SHOULD work but does not currently work in the XForms 0.6 extension:

<xf:bind nodeset="/var/first" type="xs:boolean" />
<xf:bind nodeset="/var/second" relevant="/var/first" />

And this does work:

<xf:bind nodeset="/var/first" type="xs:decimal" />
<xf:bind nodeset="/var/second" relevant="/var/first &gt; 0" />


Reproducible: Always

Actual Results:  
no relevant binding

Expected Results:  
the second form should enable based on the true/false value of the first

<html
   xmlns="http://www.w3.org/1999/xhtml"
   xmlns:xf="http://www.w3.org/2002/xforms"
   xmlns:xs="http://www.w3.org/2001/XMLSchema">
   <title>Testing the relevant attribute of the bind element with boolean values.</title>
   <xf:model>
      <xf:instance>
         <var xmlns="">
            <first>true</first>
            <second/>
         </var>
      </xf:instance>
      <xf:bind nodeset="/var/first" type="xs:boolean" />
      <xf:bind nodeset="/var/second" relevant="/var/first" />
   </xf:model>
   <body>
      <p>The input field should only display if the first is set to yes (true).</p>
      <xf:select1 ref="/var/first" >
         <xf:label>Should I display the second input field? </xf:label>
         <br />
         <xf:item select="yes">
            <xf:label>Yes Please!</xf:label>
            <xf:value>true</xf:value>
         </xf:item>
         <xf:item>
            <xf:label>No Thank You</xf:label>
            <xf:value>false</xf:value>
         </xf:item>
      </xf:select1>
      <br />
      <xf:input ref="/var/second">
         <xf:label>Display this only if the first answer is true: </xf:label>
      </xf:input>
   </body>
</html>
Assignee: nobody → xforms
Component: Extension/Theme Manager → XForms
Product: Firefox → Core
QA Contact: extension.manager → spride
Version: unspecified → 1.8 Branch
Attached file testcase — 

    
    

    
  
I can see what do you want. In general it looks resonable. But remember it is ususual using of xpath and someone your proposed behaviour can confuse too or even broke. The bug either rfe, wontfix or invalid. Wait for what ohter guys will say.
Summary: XForms bind relevant does not work for boolean data types → XPath expression should use type information to do necessary conversions

    
    

    
  
According to the spec:

http://www.w3.org/TR/xforms/slice7.html#fn-boolean-from-string

This also can convert a string to a boolean, giving me what I want:

<xf:bind nodeset="/var/second" relevant="boolean-from-string(/var/first)" />

And it does work according to the spec!

    
    

    
  

      
      
      
      

        Attached file
          
        testcase booltostr
        — 
      

    


  
(In reply to comment #3)
> According to the spec:
> 
> http://www.w3.org/TR/xforms/slice7.html#fn-boolean-from-string
> 
> This also can convert a string to a boolean, giving me what I want:
> 
> <xf:bind nodeset="/var/second" relevant="boolean-from-string(/var/first)" />
> 
> And it does work according to the spec!
> 

Works fine for me. Tested both on trunk and 0.6.

But what do you want and then what is the bug about? Your bug description says something different than your next comment.

    
    

    
  
So if specs defines function to convert from string to boolean and since it looks like it works then is bug invalid, right?

    
    

    
  
(In reply to comment #4)

> But what do you want and then what is the bug about? Your bug description says
> something different than your next comment.
> 

Sorry, I misreaded your comment at the first time. So, I close the bug.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID

    
    

    
  
Yes, this is clearly not a real but, but just my lack of understanding of how XPath evaluates boolean expressions.  Here are the rules as I understand them:

In XForms, instance data is always represented as a string.  I can then be typed as xs:boolean using bind, but it still must follow the rules of XPath evaluation.  Whenever a boolean datatype is evaluated:

If the string is empty, it returns a false.

If the string is not empty (even if it has the value "false" in the text), it STILL returns a true.  Not intuitive but this is what the spec says.

In my classes and in my textbook, I will suggest the following:

1) Use booleans datatypes whenever you really want true/false status and set the values to be "true" and "false"
2) If you are interested in using booleans, use the xf:bind to bind the elements to type="xs:boolean".  But in reality this is really only documentation for future developers and can be ignored in practice without impact on the functionality of the XForms.
3) Whenever you test for booleans, ALWAYS use the boolean-from-string().  This makes your code independant of how the XForms implementatin may work with boolean bindings and makes your code much more portable.

Please let me know if you have any other suggestions for increasing the portability of XForms implementations that might have to run under many different engines.

    
    

    
  
(In reply to comment #7)
>2) If you are interested in using booleans, use the xf:bind to bind the
>elements to type="xs:boolean".  But in reality this is really only
>documentation for future developers and can be ignored in practice without
>impact on the functionality of the XForms.

This part is incorrect.  It can control the appearance of form controls, among other things.  For example, this may make an input show as a checkbox (and I think it does indeed do that in Mozilla XForms).

Also, it controls submission validation.  If the bind says it's a boolean, then it will not submit with something else in there.  One thing to note is that XSD defines boolean as true/false/0/1.

As a side note, XPath 2.0 is XML Schema datatype aware.





    
    

    
  
Leigh is absolutely right.

I also think that you are trying to look to set up some general guidelines that cross boundaries and as such, really can't be generalized.  If you want to carry on the discussion further perhaps the mozilla.dev.tech.xforms newsgroup on news.mozilla.org would be a better place to do it (so that more people will see it and can chime in if they have opinions).

Here is how I look at it:

When a form author specifies a type on a control, either through @xsi:type directly on an instance data node, through schema or using xf:bind's @type, he is doing a couple of things.  He is telling the processor that when it does validation of the value of the node, it must be validated against the schema definition of that type (whether it is a builtin type or a schema-defined type).  A node that is valid or invalid affects the events that are sent to the controls, affects rendering of the control through CSS styling and affects submission (an instance subtree that is requested to be submitted won't submit and will generate a xforms-submit-error if any of the nodes it contains are invalid).  The form author is also, as Leigh noted, providing a clue to the processor on how to render the control that is bound to that node so that it can be most effectively and efficiently manipulated by the form user on that platform (whether it be a browser, a handheld device, or even accessibility-targeted devices).

But the data, as it is, has no special meaning to XForms.  So if you are building an XPath expression for @relevant, for example, and use instance data nodes to do it, you are just getting the value of the node to help build the expression.  The XForms processor will then try to evaluate that expression as defined in the spec.  In the case of @relevant, we evaluate the epression to build an XPath boolean value.  If the expression doesn't lend itself to being expressed accurately as a boolean, then it must be converted to a XPath boolean (for example, using boolean-from-string).

In case you run into trouble, if I'm not getting the behavior I think I should from a control bound to a certain node, I'll often use the more explicit true() or false() in the xf:bind MIP to help me figure out if the problem is with the expression I used on bind's @nodeset or whether the problem is with the expression I'm using in @relevant, @readonly, etc.  To debug the expression I'm using in the MIP's, I'll usually use a xf:output with @value to see what the output from the xpath evaluation will be to make sure it is giving me back what I think it should.  Or use JS to evaluate the xpath expression.  There are probably even better approaches/tools out there or there will be when XForms is more widely used.

    
    

    
  
>...mozilla.dev.tech.xforms newsgroup on news.mozilla.org ...
or www-forms@w3.org if it is a general xforms issue
Product: Core → Core Graveyard

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: