Re: [xsl] Unexpected Result from 'eq' Expression Involving a Node

Subject: Re: [xsl] Unexpected Result from 'eq' Expression Involving a Node
From: "Michael Kay mike@xxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 23 May 2018 15:35:38 -0000
Writing () as "empty sequence",

xs:boolean() returns () if the argument is (). (F+O B'18.1, "If $arg is the
empty sequence, the empty sequence is returned.")

X eq Y (value comparison) returns () if either argument is (). (XPath B'3.7.1,
"If an atomized operand is an empty sequence, the result of the value
comparison is an empty sequence")

string(()) returns "", so when @a is absent, string(@a) eq "zzzzz" will return
true or false, never ().

A = B (general comparison) returns false() if either argument is (). [Since
2.0 - in 1.0 the expression (() = false()) returns true].

A = B casts untyped values to the type of the other operand, A eq B casts them
to xs:string -- this is to achieve transitivity.

No changes here between 2.0, 3.0, and 3.1.

Michael Kay
Saxonica



> On 23 May 2018, at 16:01, Eliot Kimber ekimber@xxxxxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> Using latest Saxon in an XSLT 3 transform I have this instruction:
>
> <xsl:message>+ [DEBUG] xs:boolean(@id eq 'x8AC8E061C912') = "{xs:boolean(@id
eq 'x8AC8E061C912')}"</xsl:message>
>
> I expected the value of the xs:boolean() to be "true" or "false".
>
> However, the value I get is "" (empty sequence).
>
> If I change "eq" to "=" or if I wrap "@id" in string() then I get the
expected true or false result (which also suggests that my understanding of
"eq" is not complete).
>
> I don't see anything in the definition of the 'eq' operator or the
xs:boolean() function that suggests that it would ever return an empty
sequence, so I'm wondering what I'm missing in the spec that allows
xs:boolean() to return an empty sequence in this case (or in any case)?
>
> I guess I was also expecting "eq" to imply casting of the left-hand operand
to an atomic type which it does not appear to do.
>
> The behavior is the same in XSLT 2 (at least using Saxon), so clearly this
is not new with XSLT 3 but I'm still surprised.
>
> Thanks,
>
> Eliot
>
> --
> Eliot Kimber
> http://contrext.com

Current Thread