Re: Fwd: Pattern matching error in xsl:key

On 09/06/20 16:45, Ihe Onwuka wrote:
> The source of the surprise is not that the select parameter is evaluated.
> It's because the value in the attribute is type annotated as xs:string even
> though it is a decimal number.
> 
> So you think you are comparing 4.0 to 4.0 but because of the type value
> assigned to the RHS the comparison is actually 4.0 to '4.0'

Ah. I took your intent to be the opposite, when you wrote:

On 05.09.2020 19:22, Ihe Onwuka wrote:
> Not using schema aware XSLT and the values concerned are version numbers
> and should be treated as strings.

Whether comparing '4.0' to '4.0' or 4.0 to 4.0 is what you actually want,
the code can be written to express your intent.

> Both Dmitre and Martin explained this earlier in the thread.

I saw where Martin correctly explained it's untypedAtomic:

On Sat, Sep 5, 2020 at 11:56 AM Martin Honnen <martin.honnen@...> wrote:
> However, in your untyped XML the attribute value of e.g. @from or @to is
> of type xs:untypedAtomic.

It is not of type xs:string. However, you are allowed to use eq between
a string and an untypedAtomic. You are not allowed to use eq between
a number and an untypedAtomic.

This can be surprising if coming from a language like Perl where any string
that happens to look like a number can be silently treated as being the
number it happens to look like.

In XPath, an untypedAtomic that happens to look like a number still isn't
a number unless you say that's what you mean. (Or use the general comparison
operators, which are looser about that.)

You are allowed to eq an untypedAtomic and a string because that doesn't
involve any kind of silent conversion; it can just directly compare the
lexical form of the untypedAtomic to the characters of the string.

Regards,
-Chap