Re: Pattern matching error in xsl:key

The original post reported an error message that you said was a Saxon bug.


On Sun, Sep 6, 2020 at 6:16 PM Michael Kay <mike-JkSD5nQpfvpWk0Htik3J/[email protected]> wrote:

> 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