W3C home > Mailing lists > Public > xproc-dev@w3.org > September 2011

RE: Options as strings. Blech.

From: Geert Josten <geert.josten@daidalos.nl>
Date: Fri, 2 Sep 2011 11:18:09 +0200
To: "vojtech.toman@emc.com" <vojtech.toman@emc.com>, "xproc-dev@w3.org" <xproc-dev@w3.org>
Message-ID: <B26C615F8546A84C81165A7BC8BE61A020F645CC0B@EXMBXC01.ms-hosting.nl>
Hi Vojtech,

I think Norm meant that all those atomic values are cast to strings before calculation of the EBV, as they are passed in as option values. So 0 is converted to '0', NaN to 'NaN', true() to 'true' and false() to 'false'. And all those strings return true() as EBV, while a direct evaluation to EBV would give different results..

Kind regards,
Geert

-----Oorspronkelijk bericht-----
Van: xproc-dev-request@w3.org [mailto:xproc-dev-request@w3.org] Namens vojtech.toman@emc.com
Verzonden: vrijdag 2 september 2011 11:12
Aan: xproc-dev@w3.org
Onderwerp: RE: Options as strings. Blech.

> If anyone needs to be convinced that forcing all option (and
> parameter) values to be strings was a bad idea, point them at the
> expected results of this test:
> 
>   http://tests.xproc.org/tests/required/ebv-001.xml

I am sorry if I am not seeing something, but where does it follow from that the following test evaluates to true()?

<p:when test="'0'">...</p:when>

Isn't the effective boolean value of the above XPath expression (in XPath 2.0) false()? At least that is what you get when you cast the string '0' to xs:boolean. (In XPath 1.0, '0' indeed evaluates to true().)

I agree with the other weird cases (NaN, true(), false()), though.

--
Vojtech Toman
Consultant Software Engineer
EMC | Information Intelligence Group
vojtech.toman@emc.com
http://developer.emc.com/xmltech
Received on Friday, 2 September 2011 09:18:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 2 September 2011 09:18:56 GMT