[Top] [All Lists]

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

2020-09-05 12:55:11
So I have ended up doing an eq comparison and quoting the $source and
$target, which is what I was trying to avoid.

Why do you think any logical reasoning would result in deciding that the
type of $source below must be a string?

 <xsl:param name="source" select="4.0"/>

The value of the "select" attribute is evaluated as an XPath expression,
What is the type of the xpath expression (hint: it is obviously a decimal


Why do you think anyone should conclude that this is a string?

Just curious...


On Sat, Sep 5, 2020 at 10:49 AM Ihe Onwuka 
<ihe(_dot_)onwuka(_at_)gmail(_dot_)com> wrote:

On Sat, Sep 5, 2020 at 11:56 AM Martin Honnen 

Am 05.09.2020 um 17:34 schrieb Ihe Onwuka:

No doubt in excerpting I omitted some relevant info. I'll try and fix
that. The XML content is in a separate document and globally namespaced.

<versionChanges xmlns="http://changes"; >
   <changes from="4.0" to="4.1">

and here is the error message

Warning at char 11 in xsl:key/@match on line 36 column 111 of
   XPTY0004  An error occurred matching pattern

   (atomizeSingleton($source))) and
((data(attribute::attribute(Q{}to))) eq

    My guess would be that it's a type error connected with the fact
    you're comparing numbers to strings, but beyond that,

I am comparing parameters whose values are 4.0 and 4.1 respectively to
attributes whose values are 4.0 and 4.1 respectively. Saxon has made
it's own assumptions about what types they are and come up with that

The types are not made up by Saxon but are defined in the XPath/XSLT
specs. In the XSLT code if you declare

   <xsl:param name="source" select="4.0"/>

the expression 4.0 in the select attribute is of type xs:decimal (in a
version="2.0" or version="3.0" XSLT code).

However, in your untyped XML the attribute value of e.g. @from or @to is
of type xs:untypedAtomic.

The eq operator only works if both operands have a comparable type, in
your case the rules in
https://www.w3.org/TR/xpath-31/#id-value-comparisons (5.d) give
"Otherwise, a type error is raised [err:XPTY0004].".

So using = instead of eq is one way to avoid that, as it in 4.a of
https://www.w3.org/TR/xpath-31/#id-general-comparisons stipulates: "If
at least one of the two atomic values is an instance of a numeric type,
then both atomic values are converted to the type xs:double by applying
the fn:number function".

Correction to my earlier post.
Using = instead of eq changes the behaviour of the program and it ends up
incorrectly omitting some of the output.

I'm not going to investigate why because I shouldn't be using an
existential evaluator anyway.

So I have ended up doing an eq comparison and quoting the $source and
$target, which is what I was trying to avoid.

saxon-help mailing list archived at http://saxon.markmail.org/

Dimitre Novatchev
Truly great madness cannot be achieved without significant intelligence.
To invent, you need a good imagination and a pile of junk
Never fight an inanimate object
To avoid situations in which you might make mistakes may be the
biggest mistake of all
Quality means doing it right when no one is looking.
You've achieved success in your field when you don't know whether what
you're doing is work or play
To achieve the impossible dream, try going to sleep.
Facts do not cease to exist because they are ignored.
Typing monkeys will write all Shakespeare's works in 200yrs.Will they write
all patents, too? :)
Sanity is madness put to good use.
I finally figured out the only reason to be alive is to enjoy it.
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>