xsl-list
[Top] [All Lists]

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

2020-09-06 17:16:51
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(_at_)anastigmatix(_dot_)net> 
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(_at_)lists(_dot_)sourceforge(_dot_)net
https://lists.sourceforge.net/lists/listinfo/saxon-help 
--~----------------------------------------------------------------
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>