Re: Pattern matching error in xsl:key

Ihe Onwuka <[email protected]>
Newsgroups gmane.text.xml.saxon.help,gmane.text.xml.xsl.general.mulberrytech
Message-ID <CALfs7+zEPsqLno8g+K9qRFoEaRuXLvrC6eSQ0FMrVd4cDDs9bw@mail.gmail.com>
On Sat, Sep 5, 2020 at 11:56 AM Martin Honnen <[email protected]> wrote:

> 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.
> > Here.
> >
> > <versionChanges xmlns="http://changes" >
> >    <changes from="4.0" to="4.1">
> >       <rename>
> >          <metadata/>
> >       </rename>
> >    </changes>
> > </versionChanges>
> >
> > and here is the error message
> >
> > Warning at char 11 in xsl:key/@match on line 36 column 111 of
> > myStylesheet.xsl:
> >    XPTY0004  An error occurred matching pattern
> >
> > {element(Q{http://changes}changes)[((data(attribute::attribute(Q{}from)))
> eq
> >    (atomizeSingleton($source))) and ((data(attribute::attribute(Q{}to)))
> eq
> >    (atomizeSingleton($target)))]}:
> >
> >     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
> error.
>
> 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/
[email protected]
https://lists.sourceforge.net/lists/listinfo/saxon-help
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.