[xsl] Re: [saxon] Pattern matching error in xsl:key

["Michael Kay mike@xxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

I'd like to remind everyone that this list is for questions about the Saxon
product. Discussions of the W3C specifications are best taken elsewhere, for
example the xsl-list at mulberrytech.com. Unfortunately, fascinating though
these things are to some of us, a lengthy off-topic discussion always leads to
a spate of "unsubscribe" requests.

I don't think anyone has been suggesting that Saxon's behavior here isn't 100%
conformant with the W3C specifications. If you want to discuss how the W3C
specs came to be as they are, or whether they could be improved, please open a
thread on xsl-list.

Michael Kay
Saxonica

> On 6 Sep 2020, at 22:40, Chapman Flack <chap@xxxxxxxxxxxxxxxx> wrote:
>
> 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
>
>
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> saxon-help@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/saxon-help