Re: Unexpected Result from 'eq' Expression Involving a

I see.

My failure was not following the link to XSLT 3.1 from the XPath Operators and
Functions section 7.

It all makes sense now.

Historically I have (incorrectly) used "=" when I should have been using "eq"
and only recently (thanks to Evan Lens' patient tutelage) came to fully
appreciate the difference between "=" and "eq" (but in the context of XQuery
coding practice) so I never ran across this before in my XSLT work. Just goes
to show there's always something new to learn.

Thanks,

Eliot
--
Eliot Kimber
http://contrext.com


o;?On 5/23/18, 10:35 AM, "Michael Kay mike@xxxxxxxxxxxx"
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

    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