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