[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XPath proximity position in predicates

Subject: Re: XPath proximity position in predicates
From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>
Date: Mon, 15 May 2006 12:41:59 +0200
Re:  XPath proximity position in predicates
At 2006-05-15 12:30 +0200, David Landwehr wrote:
It might be that a default of rounding the number expression isn't always the solution an author would want. The reason I took a guess for rounding is that if you write select="element[(((7 div 5) div 3) * 5) * 3]", you get from the constant expression select="element[6.99999999999]" which will never select an element. In that particular case rounding would be what I expected.

Yes, I understood that, and it seems intuitive but from a standards perspective the question would be would you want that to *always* happen, or should it be up to the user to decide what to do with inaccurate results as it might depend on the situation (as I tried to highlight in my example)?


Thanks for following up.

. . . . . . . . . Ken

Best regards,
David


G. Ken Holman wrote:
At 2006-05-15 11:19 +0200, David Landwehr wrote:
Reading XPath 1.0 it states that a predicate evaluating to a number will return true if equal to the proximity position of the current node. I was wondering if there is a reason the evaluated number isn't rounded by the XPath engine? Because XPath is based on IEEE 754 the result of an evaluation might be inaccurate on the last digit which will cause a predicate to return false where it should return true. I'm just asking this out of curiosity and accepts that an author has to call the round function if she uses arithmetic which can give inaccurate results.

As the typical use is merely ordinal position in a node set I've never had to worry about this in a predicate ... but I did have to think about position() and rounding in a standalone <xsl:if> when doing a two-column display in XSL-FO and I wanted to introduce a column break in a standalone block ... I might have wanted to use floor() instead of round() in the following:


 <xsl:if test="position()=round(last() div 2)">
   <block break-before="column"/>
 </xsl:if>

... but I cannot readily extrapolate that into an XPath predicate.

I think you summarized correctly that if the author is doing things that might give inaccurate results they should do it explicitly ... as in my case they might want to make the decision between floor() and ceiling() but in a predicate rather than just round(), so I don't believe it makes sense to just implement round() by default.

I hope this helps.

. . . . . . . . . Ken


--
Registration open for XSLT/XSL-FO training: Wash.,DC 2006-06-12/16
Also for XSLT/XSL-FO training:    Minneapolis, MN 2006-07-31/08-04
Also for XML/XSLT/XSL-FO training:Birmingham,England 2006-05-22/25
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman                 mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/s/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/s/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.