xsl-list
[Top] [All Lists]

RE: [xsl] XPath proximity position in predicates

2006-05-15 05:07:39
I think it would certainly have been more natural if the spec had specified
rounding in this case, as it does for example with the arguments to
substring(). But it doesn't, and it's not a significant problem in practice.
In the first draft of XPath 2.0 rounding slipped in somehow (see
http://www.w3.org/TR/2001/WD-xpath20-20011220/#id-predicates) but we took it
out again to retain compatibility.

Michael Kay
http://www.saxonica.com/

-----Original Message-----
From: David Landwehr [mailto:david(_dot_)landwehr(_at_)solidapp(_dot_)com] 
Sent: 15 May 2006 12:05
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: Re: [xsl] XPath proximity position in predicates

Hi Ken,

Notice that your situation is different from what I have 
since you use the = operator. From a specification stand 
point this would never change as the result of the test is a 
boolean. The only situation where this "rounding" would apply 
would be in the special case where you have a predicate 
expression returning a number. I guess the specification 
would be in its right to say it default should use round 
(e.g. as it does for the arguments to the substring function) 
it would still allow the author to change the behavior by 
wrapping the calculation in a call to floor or ceiling. 
However I'm not trying to get a change into the 
specification, I simply found it interesting that it work in 
this way and thought way not ask the people who know why ;)

Best regards,
David


G. Ken Holman wrote:
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(_at_)CraneSoftwrights(_dot_)com
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



--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: 
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--



--
--------------------------------------------
David Landwehr (david(_dot_)landwehr(_at_)solidapp(_dot_)com) Chief Executive 
Officer, SolidApp
Web: http://www.solidapp.com
Office: +45 48268212
Mobile: +45 24275518
--------------------------------------------


--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: 
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--



--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--