RE: Options as strings. Blech.

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 UTC