Re: Pattern matching error in xsl:key

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-JULfBfA8satPFr4CO1/[email protected]> 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/
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/saxon-help

_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[email protected]
https://lists.sourceforge.net/lists/listinfo/saxon-help