xsl-list
[Top] [All Lists]

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

2018-05-23 11:06:19
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
 

On 5/23/18, 10:35 AM, "Michael Kay mike(_at_)saxonica(_dot_)com" 
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:

    Writing () as "empty sequence",
    
    xs:boolean() returns () if the argument is (). (F+O §18.1, "If $arg is the 
empty sequence, the empty sequence is returned.")
    
    X eq Y (value comparison) returns () if either argument is (). (XPath 
§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(_at_)contrext(_dot_)com 
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> 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
    > 
    > 
    
    
    
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--

<Prev in Thread] Current Thread [Next in Thread>